01Decision table
Which R fits which situation?
Terms vary between vendors. Here, refactor means restructuring code while keeping behavior, not the broader re-architecture some cloud frameworks also call refactor.
| Option | What changes | Pick it when | Main risk |
|---|---|---|---|
| Rehost (lift and shift) | Where it runs; code untouched | The constraint is the data center, hardware or contract, and the code is fine | You carry every old problem to the new home, and may pay more to run it |
| Replatform | Runtime, server or hosting, with small code edits | The constraint is a license, an unsupported server or a missing container path | Hidden vendor dependencies surface late |
| Refactor | Code structure and framework, behavior kept | The code is worth keeping but is hard to change, test or upgrade | Needs a test safety net first, or you cannot prove behavior held |
| Rewrite | Everything; new code from requirements | The code cannot be understood or tested, or the business process has changed | Long delivery gap, lost edge-case behavior, and two systems to run |
02Decision rules
Five rules, applied in order
Run each application through the rules top to bottom and stop at the first one that applies. The order matters, because cheaper options come first.
- 01
Is the application still needed?
If no one uses it or its function moved, retire it. If it is needed but not worth touching, leave it and record why.
- 02
Is the constraint the location?
If the code is sound and the problem is the data center, rehost. Accept that this fixes the address, not the application.
- 03
Is the constraint a license or a platform?
A proprietary application server or runtime with a cost or support problem points to replatform. Move to a standard server or container and edit just what must change.
- 04
Is the code the constraint, and can it be tested?
If changes are slow and risky but the logic is right, refactor. Write characterization tests first, then change code in small steps.
- 05
Can the code not be tested or understood, or has the process changed?
Then, not before, consider a rewrite, and scope it as a replacement of one capability at a time rather than a single switch.
03The common argument
Why is refactor usually safer than rewrite?
A rewrite discards years of behavior that no one wrote down: rounding rules, error paths, odd customer cases. The new system has to rediscover them, usually in production. A refactor keeps that behavior in place and proves it with tests as the code changes.
A rewrite is right when the old code cannot be made testable at reasonable cost, or when the business rules themselves are changing. Even then, replacing one capability at a time keeps the old system as the reference. See legacy code refactoring for the technique.
04Lift and shift
Lift and shift vs refactor: when is the cheap one fine?
Lift and shift is fine when the deadline is a hosting exit and the application has a long, quiet life ahead. It is a poor choice when the application needs to change often, because every future change still pays the old cost.
A frequent path is rehost first to meet the date, then replatform or refactor in phases. Do not skip the second step by accident: record it as planned work.
05The 7 Rs
How do the 7 Rs of migration map to these four?
The 7 Rs are a portfolio-level vocabulary published by AWS in its migration guidance. Ace8 is not affiliated with AWS. The four options above sit inside it.
| R | Meaning | Covered by |
|---|---|---|
| Retire | Switch off | Rule 1 |
| Retain | Leave as is for now | Rule 1 |
| Rehost | Move unchanged | Rule 2 |
| Relocate | Move at hypervisor or container-platform level | Rule 2 variant |
| Repurchase | Replace with a product or SaaS | Outside code work; decide in the assessment |
| Replatform | Move with limited changes | Rule 3 |
| Refactor / re-architect | Change the code or architecture | Rules 4 and 5 |
06In practice
Expect a mix across the estate
Estates rarely get one answer. A typical result is a few retired, a few retained, a large group replatformed off a licensed server, and a smaller group refactored because the business depends on them. The rules above run per application, which is why the portfolio view comes first. See application portfolio rationalization.
Sample assessment results showing the rules applied to a real codebase are pending. We are running this test; results will be published here.
07How Ace8 helps
Apply the rules to your applications
Ace8 is the AI-assisted application modernization practice of AceMQ.
The modernization assessment applies these rules to each application and returns the chosen R, the reason, and a phased plan with a price. For the options in service form, see legacy application modernization.