Choose the modernisation strategy that addresses the system’s actual constraint. Refactor when code-level problems are the issue; replatform when the main goal is operational improvement with minimal code changes; and rearchitect or rewrite when the existing design itself blocks needed change. For a large system that must keep serving users during replacement, an incremental strangler migration may reduce cutover risk—but only if requests can be routed and the old and new components can coexist safely.
What is the difference between rewriting, refactoring and replatforming?
These terms describe different changes, not interchangeable levels of the same upgrade. Start by naming the outcome the organisation needs, then choose the least disruptive approach that can deliver it. The Microsoft Cloud Adoption Framework describes refactoring in terms of changing application code to improve maintainability, performance or cloud alignment; a platform move and an architectural redesign address different constraints.
As an Amazon Associate I earn from qualifying purchases.
| Approach | When it fits | What to plan for |
|---|---|---|
| Refactor in place | The application can be modified, and code-level debt, maintainability, performance or cloud alignment is the problem. | Set measurable goals, test changes and control regressions. Refactoring code alone may not remove an architectural limit. |
| Replatform | The priority is reducing operational overhead or improving reliability through a platform move with minimal code changes. | Check that the target platform suits users and integrations. Replatforming does not by itself redesign the application. |
| Rearchitect or rewrite | The current design constrains scalability, agility or innovation, or replacing the system is straightforward enough to justify it. | Preserve and verify required business behaviour. Replacing a large, complex system in one cutover can create substantial risk and disruption. |
| Incremental strangler migration | The system is large or complex, can remain in service during migration, and requests or calls can be intercepted and routed. | Plan routing, data ownership and synchronisation, dependencies, proxy reliability, domain boundaries and eventual removal or retention of temporary components. |
A rewrite is not simply a larger refactor: it replaces existing implementation, while rearchitecting changes the system’s structure. These can overlap in practice. A team might refactor part of a system, replatform another part and replace a capability that cannot meet its requirements in the current architecture.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →How should you decide which strategy fits?
Compare each option against the business constraint and the transition the organisation can support. There is no universal cost, duration or complexity threshold that makes a rewrite or refactor the right choice.
#1 Best Overall
- Desired outcome: Is the need better maintainability, performance, cloud alignment, reliability, lower operational overhead, scalability, agility or something else users actually need?
- System shape: How large and interdependent is the application? Are its domain boundaries clear enough to separate capabilities safely?
- Change and routing access: Can the team change the source code? Can it intercept requests or calls and direct selected work to new components?
- Data and interactions: Which components read or update shared data? What consistency is required, and where do old and new components call one another?
- Transition constraints: Must the old application remain available during migration, or does it need to be shut down quickly? Is temporary coexistence affordable?
- Delivery capability: Does the team have the expertise to build, operate and support the proposed architecture as well as the legacy system during transition?
Use these questions to distinguish a code problem from a platform problem or a design problem. A phased approach is not automatically safer overall: it exchanges a single major cutover for a period of added architecture, infrastructure and operational work.
When does an incremental strangler migration make sense?
A strangler-style migration puts a façade or proxy in front of the legacy application. The routing layer sends some functionality to new components and continues sending unmigrated functionality to the old application. The new system takes over in bounded stages while users can continue using capabilities that have not moved. AWS describes this pattern as a gradual replacement of features, with users progressively using migrated functionality: AWS Prescriptive Guidance on the strangler fig pattern.
It is most useful when the system is complex enough that a single replacement is risky, the original can stay available during transition, and calls can be intercepted. It is a poor fit for a small system that is simple to replace, an application whose requests cannot be routed, or a project that must decommission the original quickly.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesPrerequisites to check
- Access to the code and interfaces that must change.
- A practical way to intercept and route the relevant requests or calls.
- Clear boundaries for the first capability to migrate.
- A defined plan for data access, ownership, synchronisation and validation.
- Capacity to run, monitor and support both paths and the routing layer during coexistence.
Costs and risks during coexistence
- Routing availability and latency: The façade or proxy sits in the request path, so poor reliability can interrupt service and added hops can affect performance.
- Cross-system dependencies: Old and new components may need to call each other. An anti-corruption layer can translate between interfaces, but it adds another component that needs an explicit removal or retention plan.
- Shared data and consistency: If both systems access or change the same data, synchronisation can create duplication or eventual consistency. Treat it as a deliberate transition design and validate data before cutover.
- Premature service boundaries: Splitting a system before understanding its domains can create expensive, poorly chosen boundaries. AWS recommends understanding domains before selecting service cuts in its guidance on identifying domain boundaries.
- Temporary operating cost: Coexistence requires transitional infrastructure and support. Weigh that cost against the risk reduction it provides; the cited guidance does not establish a universal break-even point.
How to plan modernisation without recreating the old system’s problems
- Understand users and processes. Examine what users need now and how work actually happens. Involve affected stakeholders and the people who will support the resulting system; do not copy old assumptions onto new technology by default.
- State the outcome. Make the target concrete—for example, a maintainability, reliability or scalability need—and use it to evaluate the strategy rather than starting with a preferred technology.
- Map dependencies and data. Document integrations, data flows, shared access, source-code access and routing options. Identify likely domain boundaries before deciding what to separate.
- Prototype under realistic conditions. Test the proposed technology and verify that APIs provide the operations and information each component needs. GOV.UK’s technology guidance emphasises choosing technology in light of user needs and testing it appropriately.
- Choose a controlled migration path. For a staged move, introduce a wrapper or routing façade, migrate one bounded capability at a time and keep the legacy path available while validating the new one. Where appropriate, use a dark launch or parallel comparison to check behaviour before directing normal use to the new path.
- Set cutover and exit conditions. Define data validation, consistency checks, monitoring, rollback and decommission criteria before switching traffic. Retire the transition layer when it has served its purpose, unless it is intentionally kept as an adapter for legacy clients.
What does the evidence say about rewrites versus gradual migration?
A 2019 qualitative study recorded 14 systems and in-depth interviews with 16 professionals from 10 companies. The study identified maintainability and scalability as primary migration drivers; in many of its cases, companies preferred rewrites when legacy complexity and the lack of a suitable way to decompose the system made splitting the code difficult. Those sample descriptors and case findings are not outcome statistics, and they do not show that rewrites generally outperform refactoring or incremental migration. See the authors’ 2019 arXiv preprint record.
Rank #3
The practical lesson is to evaluate the system in front of you: a phased migration depends on workable boundaries and routing, while a rewrite can be reasonable when those conditions are absent and the replacement can preserve the required behaviour. The cited official guidance offers planning considerations and migration patterns, not universal savings or delivery-time promises.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
