"Modernize" is not one action. It covers at least seven different choices, and applying the same one to every application is a common and costly error. This article defines each option plainly, shows how to choose per application, and gives an example in words.
The seven options in plain terms
Retain
Leave it as it is, perhaps with better monitoring. If a system is stable, supported and rarely changed, retaining it is a legitimate decision and often the lowest-risk one.
Retire
Switch it off. Estates often contain applications that few people use. Retiring them removes cost and shrinks every other plan.
Rehost
Move the system to new infrastructure, such as a cloud virtual machine, with little or no code change. It is quick to start and carries existing problems along with it.
Replatform
Move and make limited changes, for instance to a managed database or a newer runtime, without changing the architecture. It captures some operational benefits for modest effort.
Replace
Swap a custom application for a commercial package or a hosted service. This suits commodity functions. The work shifts to data migration, configuration and integration.
Refactor
Change the structure of the code, for example splitting a monolith into services, while keeping behavior the same. It needs tests that describe current behavior, or you cannot tell whether behavior stayed the same.
Rebuild
Write it again, usually when the business process is changing anyway or the existing rules cannot be recovered. It is the most expensive option and the most exposed to missed behavior.
Choosing per application, not per estate
None of these options is better in general. Each is right for some applications and wrong for others, and the same application can move through several of them over the years, for example rehosted this year and refactored later once the pressure is off. Treat the list as a menu for each application and not as a ladder every system must climb.
Look at each application against a few questions. How much does the business depend on it? Is the platform still supported? How tightly is it coupled to other systems? Does anyone understand the code? Is there a date, such as a contract end, that forces a move?
Decide retire and retain first, because they shrink the scope of everything else. Then decide how the remaining applications group: some can move together, some must move in a particular order because of shared data.
Be honest about skills as well. A refactor of a COBOL application needs people who can read COBOL, and a replacement needs people who can configure the new package. The best option on paper is the wrong one if nobody on the team can carry it out.
A worked example in words: an order management estate
Imagine five applications in an order management estate.
- An order entry application, written in Java on a supported stack, stable and well liked: retain, and put an API in front if other systems need it.
- A reporting database on an aging version of its engine with the license due for renewal: replatform to a managed service, after checking the queries still return the same results.
- A pricing engine in COBOL with rules nobody has written down: refactor behind an API, starting with characterization tests that record its current outputs.
- A reporting tool whose last user left two years ago: retire.
- A timesheet application that is custom only by history: replace with a hosted service and migrate the data.
Notice also that the order matters. Retiring the unused tool and settling the retain decision cost almost nothing and clarify the scope. The pricing engine needs the most care and comes last, once tests describe how it behaves. Five applications, five different answers. A single plan labelled "move everything to the cloud" would have rehosted all of them, kept the problems and spent budget on the one that should have been switched off.
Mistakes to avoid
- Choosing one option for the whole estate. Each application has its own value, condition and coupling.
- Rehosting and expecting cloud-native benefits. A moved system behaves the same unless its design changes.
- Refactoring without tests. Without recorded behavior you cannot show that nothing changed.
- Treating data migration as an afterthought. Data volume, quality and cutover often decide the schedule.
- Skipping the retire question. The cheapest application to migrate is the one you no longer run.
For help with the choice, see legacy application modernization, cloud migration and the cloud readiness assessment.
A note on limits: tools, cloud services and practices change, and results depend on the system. The options above are a vocabulary for discussion, not a formula that picks the answer for you.