Rebuilding sounds straightforward when an existing application is difficult to change. Its replacement still needs to handle historical agreements, data and everyday exceptions. The real comparison therefore concerns the entire transition, not simply the effort of producing a fresh codebase.
This guide compares alternatives using consistent assumptions. All project examples are fictional. There is no universal winner: retention, a targeted improvement, gradual replacement or further investigation may be the best first step. The choice should address the problem the organisation actually needs to solve.
Describe the constraint in the current software
Start with a concrete constraint: a new customer group does not fit the permission model, releases are difficult to verify or a change requires extensive manual coordination. Record what works well too. A replacement plan considering only problems can overlook existing value such as dependable reporting or a well-understood operating process.
Ask users for an example of the desired change. Which outcome is currently impossible or unnecessarily difficult? This sharpens the comparison. Wanting another programming language may describe a means, but rarely constitutes a complete business objective. Investigate how that technical choice is supposed to affect maintenance, change and continuity.
Compare four real options
Retention means continuing with the existing application under explicit limitations and maintenance arrangements. Targeted improvement changes a bounded bottleneck. Gradual replacement moves selected responsibilities into a new solution while others remain. Complete rebuilding produces a new application but still needs a transition and retirement plan.
Use the same questions for every option: which goals are met, which limitations remain, what investigation is missing and who operates the result? A comparison is unfair if rebuilding includes every desired feature while retention means doing nothing. Retention can include documentation, a supported environment and better tests. Make each alternative’s scope explicit.
| Option | Value to investigate | Transition question |
|---|---|---|
| Retain with targeted arrangements | Preserve useful behaviour while clarifying specific operating dependencies. | Which limitation remains deliberately and who assesses that decision? |
| Improve one bottleneck | Remove demonstrated friction without recreating every existing feature. | How will the affected business journey be protected during change? |
| Replace gradually | Separate one responsibility while retaining other components temporarily. | Who may change records while old and new coexist? |
| Rebuild completely | Develop a new solution for an explicitly chosen future need. | How will users, records and unfinished work actually move? |
Budget the transition as work in its own right
The comparison should include data transfer, testing, staff preparation, temporary parallel work and retirement of old services. An inexpensive new application can still require an expensive transition if records are poorly understood or employees must operate two processes for a long period. Distinguish one-off costs from those continuing afterwards.
Use ranges or scenarios when information is missing. A precise total without investigated assumptions suggests more certainty than the project has. Ask which experiment could reduce uncertainty: migrate one record group, define one integration boundary or demonstrate a new user journey. That provides a stronger decision basis than merely expanding the feature list.
Investigate a workable gradual boundary
Gradual replacement requires a clear allocation of responsibilities. A new enquiry flow might coexist with an existing administration if identity, direction and failure handling are agreed. Without that boundary, temporary complexity can remain for years.
AWS describes the strangler fig pattern for incremental replacement. It is a design option, not an instruction to divide every application into microservices. Choose a boundary suited to users and operations. Ask which old responsibility can genuinely disappear after a phase and which additional connection is temporary. A phase that only adds components without retiring anything needs deliberate assessment.
Decide who owns data during transition
If two applications can change the same information, decide which value is authoritative and how conflicts are resolved. Otherwise a successful demonstration may later produce contradictory statuses or lost changes. Explain how late-arriving messages are recognised when responsibility moves to the new system.
A translation boundary can help when old and new models use different meanings. Microsoft describes the anti-corruption-layer pattern for this purpose. Concrete agreements on fields, exceptions and ownership remain necessary. Request a normal change and a failed-processing example. An architecture diagram alone does not demonstrate that both systems understand the same business event.
Example: renewing a booking platform
Illustrative example: an organisation wants to renew a booking platform because availability changes are difficult. Existing invoicing remains useful and staff understand its correction process. A complete rewrite would replace both responsibilities together. An alternative renews availability first while retaining financial processing temporarily.
The team investigates a booking with modification and cancellation. It compares not only new screens but also data movement and the manual review needed during transition. If separation requires excessive temporary integration, complete replacement may still be appropriate. The example shows an experiment that supports a choice; it does not prove gradual replacement is always cheaper.
Define when a phase is complete
A working new screen is not always the endpoint. A phase should close only after demonstrating the agreed journey, data checks, failure handling and operational ownership. State which old functions are disabled and which exceptions intentionally still use the old system.
Include a stop decision. Which observation prevents the next phase from starting? Examples include unexplained differences, missing operational knowledge or an excessive manual backlog. Do not assess readiness using the planned date alone. A phase with visible limitations may be manageable, provided users and owners understand the additional controls that remain necessary.
Buy knowledge first when a major uncertainty remains
Sometimes choosing between improvement and rebuilding is not yet responsible. A bounded investigation may then be valuable: a trial migration, a release and recovery check or a demonstration of a new role against existing records. Agree which conclusion the investigation should support.
Preserve the assumptions behind the eventual decision. If data proves more complicated or a vendor restricts access, the comparison can be revisited. This is a way to adapt execution to new evidence rather than proof the initial decision failed. Request a proposal with decision points and transferable outcomes, not just an attractive picture of the desired application.
Turn the explanation into a project decision
Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.
Open the preparation tool ↗Questions about this topic
Is gradual replacement always cheaper?
No. Temporary integrations and dual operation can require substantial work. Compare the whole transition model and first test whether a workable responsibility boundary exists.
When is retention sensible?
When the application still supports the relevant need adequately and its limitations are manageable. Retention still needs explicit maintenance, access and recovery arrangements.
Must every existing feature return?
Not automatically. Users and process owners should decide which functions remain, change or disappear. Record the consequences for data and operating agreements explicitly.
Continue with a related question
Migrating a running legacy system: ownership, cutover and fallback
Plan transition between old and new software while the business continues: write ownership, coexistence, operational cutover and recovery.
Existing software & auditsPrioritising technical debt: which improvement actually helps the business?
Make technical debt actionable through consequences, evidence, uncertainty, dependencies and small improvements that can be reassessed.
Existing software & auditsTaking over an existing codebase: establish what must keep working
Prepare a software takeover through business journeys, account ownership, reproducible builds, data responsibility and a bounded first change.
Custom software & portalsStandard software or a custom application: compare the work that needs doing
Decide when an existing product fits and when custom software is useful, using a common trial process, exceptions, maintenance and a comparable cost model.
Sources and technical background
- AWS Prescriptive Guidance: Strangler fig pattern ↗
A pattern for incremental replacement; applicability and temporary complexity need investigation for each system.
- Microsoft Azure Architecture: Anti-Corruption Layer ↗
A translation boundary can separate different system models; the example here is original project guidance.