In this article
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:
| Path | When it fits | What it keeps | What it risks | Who must be involved |
|---|---|---|---|---|
| Move as is (Rehost) | The system is stable and does its job; the problem is the servers or the data centre | Everything: code, rules and ways of working | You carry old problems with you to a new place | IT and whoever owns security and data |
| Convert the code (Replatform or Refactor) | The rules are sound but the language or platform is out of support or its licences have become a burden | The rules and the system's behaviour, on a modern language or platform | Hidden conversion errors that only show up in rare cases | Developers, plus process owners to test the results |
| Rebuild around the rules (Rebuild) | The rules are specific to your company and set you apart, and the old system can no longer hold what you need | The confirmed rules and the data; the code is written fresh | The longest path and the one that needs the most management decisions | Management, process owners and the development team together |
| Replace with a ready product (Replace) | Your work in this area looks like everyone else's, such as HR or general accounting | The data only | Your staff change how they work to fit the product, and you lose the rules it does not support | Management and the staff who will use it every day |
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:
| System | Rules specific or shared? | Problem in the place or the system? | Provisional path |
|---|---|---|---|
| Example: pricing system | Specific | The system | Convert or rebuild |
| Example: leave management | Shared | The system | Replace with a ready product |
| Example: old archive | Not used | Does not matter | Retire after archiving the data |
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.
Sources
- Amazon: the seven migration strategies in the guide for large migrations — retire, retain, rehost, repurchase, re-architect and when each fits.
- Microsoft: select your cloud migration strategies — the eight strategies and the two-year condition for rehosting.
- AWS Transform: official page — what the service modernizes and the up to 5x speed claim.
- AWS Transform: pricing — $0.035 per agent minute.
- AWS Transform: supported Regions — Regions and cross-Region data processing.
- Saudi Press Agency: AWS Region in Saudi Arabia in December.
- SDAIA: personal data protection.
Frequently asked questions
Is it better to rewrite my legacy system or replace it?
It depends on your business rules. If they are specific to your company and set you apart, rebuilding or converting fits better; if your work in that area looks like everyone else's, a ready product may be enough once the data is moved.
Does moving my system to the cloud as it is fix its problems?
No. Moving as is only changes where the system runs, and Microsoft recommends it only if you are confident the system will stay as it is for at least two years.
Do AI tools like AWS Transform choose the right path for me?
No. They speed up code conversion when conversion is the decision; choosing the path is a management decision once you know what each option keeps and loses.
How much does modernizing a legacy system cost and how long does it take?
No honest number exists without studying the system. The deciding factors are its size and connections, how clear its rules are, data quality, how much changes for staff and whether anyone still understands it.
Follow Origami in Google
Pin Origami as a preferred source and our articles will surface first for you in Google Search and Top Stories.








