How to choose an application modernization strategy when your company is small

The right modernization strategy depends on what is wrong with your app, and for most small companies the answer is smaller and cheaper than a rebuild.

Six options, not one

Microsoft's modernization guidance names six paths for an app: rehost, replatform, refactor, rebuild, retire and retain.^[1] Rehosting moves the app to newer hosting without changing its code. Replatforming moves it to a new runtime with minimal code changes. Refactoring changes the code without changing what the app does. Rebuilding starts over. Retiring shuts the app down, and retaining leaves it as it is.^[1]

Most guides to these options are written for companies with dozens of apps and a department to manage them. You probably have one app that your business depends on. The question is which option fits it, and the symptom you see is the best place to start.

Start from the symptom

Each symptom below points to one option to ask about first.

Some of these rows need a look at the code before anyone can say which applies. A hosting bill is easy to read. Whether the core logic works, or whether the trouble is the structure around it, takes an experienced engineer reading the code. That review is the most useful thing a consultation can give you.

Why rebuilding comes last

Rebuilding feels cleanest, and a struggling team often proposes it. Software writer Joel Spolsky called a full rewrite "the single worst strategic mistake that any software company can make."^[2] His reasons hold up for a small company. Old code holds years of bug fixes, and a rewrite throws that knowledge away. A team that starts over can go years without shipping anything new, because the old version is all it has to sell.^[2] A company with a handful of people can rarely pay for a new system while keeping the old one alive.

He also points out that architecture problems can be fixed one at a time, by moving code, refactoring and changing interfaces, without discarding the code.^[2] IBM likewise calls rewriting legacy code often a last resort, because it is a new project in itself.^[4]

Rebuilding is sometimes right. Microsoft says starting over fits when the cost of replatforming or refactoring outweighs the benefits.^[1] That is a judgment about your code, and it is worth having it made by someone who will not profit from the bigger job.

A middle path: replace one piece at a time

Martin Fowler describes a gradual approach called the strangler fig. The team builds new features beside the old code base, then moves pieces of behavior across over time.^[3] It does not make the work easy, but investment and returns arrive gradually and visibly.^[3] Fowler gives reduced risk as the main reason to prefer it over a cut-over rewrite: it delivers value steadily, and frequent releases let you watch progress.^[5]

For a founder who has to keep selling during the work, that matters. The price is a temporary layer that lets the old and new code run together. The team removes it when the move is done.^[4]

Who does the work matters as much as the option

Refactoring takes longer than rehosting or replatforming and calls for skilled developers, IBM says, especially when the code is old.^[6] If your app is stuck because the current developers lack those skills, any strategy will stall in their hands. A sound plan names who will do the work. It also ends with a stable system that lower-cost developers can maintain, on hosting that does not eat your margin.

What to bring to a consultation

When you request a consultation, bring the facts a plan depends on:

• What the app does and where it breaks.
• How many engineers work on it now, and how experienced they are.
• How many outside firms or contractors have worked on it, and for how long each.
• How much you have spent on development since it started, and your monthly hosting bill.
• What the business cannot lose while the work happens.

The money figures do not need to be exact. Rounded numbers or your best estimate are enough. They help explain the state the app is in: what it has cost, how long it has taken, and whether the spending has bought a stable product.

Ask for a recommended option from the six above, a cost range and a timeline. With those three answers in hand, you can decide whether to fix, move or rebuild, and whether to keep paying the people you have now.