Should I Rewrite, Migrate or Replace My Legacy System?

You have 4 ways to modernize a legacy system: move it as it is to the cloud, convert its code to a modern platform, rebuild it around the business rules you extracted, or replace it with a ready-made product and keep only its data. 4 questions decide: are your rules specific to your company? Is the problem where the system runs or the system itself? Who still understands its code? How much change can your staff absorb? Amazon groups these paths into 7 strategies and Microsoft into 8, both decided system by system.

In part 4 you extracted your system's business rules and had the process owners confirm them. Those rules are what make the comparison below possible: without them you cannot tell what each path would cost you in lost behaviour.

The four paths in plain words

There are many technical names, but they boil down to 4 decisions any manager can follow. This table compares them; the names in brackets are what you will hear from vendors:

Source code is the program text the system was written in. If you do not have it, or nobody left understands it, the conversion path gets harder; Amazon's strategy guide lists an application that nobody knows how to maintain, or whose source code is unavailable, among the cases that push towards redesign.

Where AI conversion tools fit

Tools such as AWS Transform work mainly on the second path: they read old code and convert it to a modern platform, for example moving old .NET Framework applications to a modern version that runs on Linux. Amazon says the tool modernizes Windows, mainframe and VMware applications up to 5 times faster; that is Amazon's claim about its service, not a guaranteed result. According to its pricing page, the service charges $0.035 per agent minute and does not charge for user idle time.

But the tool does not choose the path for you. It speeds up conversion when conversion is the right decision, and helps little if the better answer is to replace the system with a ready product. Note too that the Regions page lists no Region in the Middle East and warns that your data may be processed in another Region, while Amazon has announced its cloud Region in the Kingdom for December 2026, according to the Saudi Press Agency. If your code carries customer data, check where it will be processed before you start.

What drives cost and duration

We will not give you a number, because any number given without knowing your system is a guess. These are the factors that push cost and duration up or down on every path:

• Size and entanglement: the number of screens, reports and other systems connected to it, as your inventory in part 3 showed.
• Clarity of the rules: every confirmed rule saves time, and every unknown rule means a late, expensive discovery.
• Data quality: duplicated or incomplete data needs cleaning before any move, whatever the path.
• How much changes for staff: moving as is changes nothing for the user; replacing changes almost everything and needs training.
• Who still understands the system: one employee who knows its history saves weeks of guesswork.

On the order of steps, two official sources give advice. Amazon's guide describes re-architecting as the most complex and costly strategy, and for large migrations recommends moving first and modernizing once the move is complete. Microsoft's Cloud Adoption Framework says moving as is suits a workload only if you are confident it will stay in its current state for at least two years; otherwise it is better to modernize straight away and avoid doing the work twice. We covered the move itself in our practical guide to moving to the cloud.

Two options everyone forgets: keep and retire

Not every legacy system needs modernizing now. Both the Amazon and the Microsoft lists start with two options that do not cost a full project:

• Retire: some systems are no longer really used. Amazon gives the example of applications with no inbound connection in the last 90 days, or whose processor and memory use is below 5 percent. Retiring these after archiving their data reduces maintenance and security risk.
• Retain: a stable system that does its job with no near-term reason to change, or one tied to a factory machine with no equivalent. The decision here is to keep it, watch it and come back to it later.

If you lean towards replacing it with a ready-made ERP, first compare off-the-shelf and custom using the criteria in how to choose an ERP, and start from your list of confirmed rules: every rule the product does not support becomes either a costly customisation or manual work.

The Origami view

We do not start with the technology but with the rules: which business rules in this system set your company apart, and which are shared with everyone else? What sets you apart deserves to be built or converted with care; what is shared may be served well by a ready product with good integration to your other systems. That is why the decision is often a mix: one system replaced, another converted, a third kept as it is.

We use AI tools where they genuinely save time, in reading, converting and testing code, but the choice of path stays with management once it can see what each option keeps and what it loses. If you want to see how we work, take a look at our services.

This week's exercise: one decision per system

Go back to your systems inventory and add two columns for each system: are its rules specific to your company or shared? And where is the problem: the place it runs or the system itself? Then write down the provisional path:

These are illustrative examples; your table will differ. What matters is that every system has a written reason for its path, reviewed by the process owners before you ask for quotes.

Coming next

You have chosen a path for each system. The riskiest day of the project is still ahead: cutover day. In part 6 we explain how to test code that AI wrote or converted by comparing the outputs of both systems on the same real transactions, how to run them side by side for a set period, and when you need a rollback plan.