An old application may still contain business rules your team relies on every day. Replacing it all at once can lose those details. This guide compares gradual changes that improve the system while the rest of the business keeps using it.
Martin Fowler's Strangler Fig metaphor describes this gradual replacement. The pattern reduces a single high-risk cutover, but it does not remove complexity. Teams must understand behavior, manage two implementations temporarily, reconcile data, and prove rollback for every slice.
Related service: Custom Software Development- 01Define business outcomes, constraints, and current service levels.
- 02Characterize existing behavior with logs, tests, and user evidence.
- 03Choose a bounded domain with a feasible seam and rollback.
- 04Introduce routing, an API, or an anti-corruption layer.
- 05Build the replacement and run both paths safely.
- 06Compare outputs, migrate ownership, and expand gradually.
- 07Retire old code, data, access, and infrastructure explicitly.
SECTION 01
Why a clean rewrite is rarely clean
Business-critical systems accumulate implicit rules, integrations, scheduled jobs, reports, data corrections, permissions, and user workarounds. Documentation rarely captures all of them. A rewrite must rediscover this behavior while the original system continues to change, which creates a moving parity target.
A full rewrite can still be reasonable for a small, well-understood system or when the existing platform cannot run safely. For complex systems, incremental displacement limits the blast radius and produces earlier evidence. It also exposes whether the organization can sustain the new architecture before committing every domain.
| Approach | Use when | Primary risk |
|---|---|---|
| Rehost | Infrastructure is the urgent constraint and application behavior can remain. | Old design and operating problems move unchanged. |
| Replatform | Managed runtime or data services provide value with limited code change. | Compatibility and performance assumptions may be wrong. |
| Encapsulate | Stable legacy behavior can be exposed behind an API or adapter. | The dependency remains and needs continued support. |
| Incrementally replace | Capabilities can be separated and released in slices. | Temporary coexistence, routing, and data ownership add complexity. |
| Full rewrite | Scope is small, behavior is known, and a controlled cutover is feasible. | Hidden parity requirements and long feedback delay. |
| Retire | The capability is unused, duplicated, or no longer required. | Unknown consumers or retention duties are overlooked. |
SECTION 02
Stabilize and measure before replacing
Capture production health, change lead time, incident patterns, critical workflows, batch schedules, interfaces, and support knowledge. Add logging and alerts around the candidate area if visibility is weak. Backups are useful only if restoration has been tested against an acceptable recovery objective.
Create characterization tests that record what the system currently does for representative inputs, including strange behavior that users may depend on. These tests are not an endorsement of the old design; they are a controlled way to distinguish intentional change from accidental regression.
SECTION 03
Choose a modernization slice with value and a seam
A good first slice matters to the business, changes often enough to justify work, has a visible boundary, and can be released to a limited cohort. It is not necessarily the easiest screen. Consider a capability such as pricing lookup, document generation, appointment scheduling, or a customer read-only view.
Avoid beginning with the most interconnected ledger or identity core merely because it is technically unpopular. Score candidate domains on business value, incident burden, change frequency, interface clarity, data coupling, testability, and rollback feasibility.
High value
The slice reduces a measured delay, risk, incident source, or blocked capability.
Clear boundary
Inputs, outputs, ownership, and consumers can be named.
Representative
It tests the new delivery and operating model without requiring the whole platform.
Reversible
Traffic can return to the old path and data can be reconciled safely.
SECTION 04
Design the seam and data transition deliberately
A reverse proxy, API facade, event stream, adapter, or anti-corruption layer can direct new work while shielding the new model from legacy details. The seam must define failure, timeout, retry, duplicate, versioning, and authentication behavior. It is production architecture, not temporary glue that can be ignored.
Choose one writer for each data item whenever possible. If both systems must write temporarily, define conflict resolution and reconciliation before launch. Backfill historical data separately from live synchronization, verify counts and business totals, and retain a trace from old identifiers to new ones.
SECTION 05
Release in cohorts and compare real behavior
Use feature flags, role-based routing, account cohorts, or transaction types to limit exposure. Mirror read-only requests or compare generated outputs when privacy and architecture permit. Define success and rollback thresholds before enabling the cohort so pressure during launch does not rewrite the decision.
Monitor errors, latency, business completion, data reconciliation, support tickets, and manual interventions for old and new paths. A technically healthy service can still fail if staff cannot complete exceptions or customers receive a fragmented journey.
- 01
Deploy the new path dark and verify dependencies.
- 02
Enable internal or low-risk accounts.
- 03
Compare technical and business results.
- 04
Correct gaps and expand by a defined rule.
- 05
Freeze old capability changes before retirement.
SECTION 06
Treat retirement as a deliverable
After all users move, identify remaining traffic, batch jobs, credentials, data copies, reports, vendor contracts, monitoring, and support procedures. Archive or migrate data according to retention needs, remove unused access, and update the system inventory and incident runbooks.
Modernization benefits appear only when old operating burden is actually removed. Keeping the legacy system indefinitely “just in case” can preserve security exposure, duplicate cost, and confusing ownership. Define a time-limited rollback period and an approved decommission decision.
SECTION 07
Frequently asked questions
Can legacy software be modernized without rewriting it?
Yes. Teams can rehost, replatform, encapsulate, replace bounded capabilities incrementally, and retire unused functions. The right mix depends on business outcomes, current risk, coupling, and rollback feasibility.
What is the Strangler Fig pattern?
It is a gradual replacement approach in which new capabilities are built around the old system and traffic moves incrementally until the replaced legacy path can be retired.
What should be modernized first?
Choose a capability with meaningful business value, frequent change or incident pain, a clear interface and data boundary, representative technical needs, and a safe limited rollout.
How do we prevent data inconsistency during modernization?
Assign an authoritative writer, define synchronization direction, make retries idempotent, reconcile counts and business totals, preserve identifier mapping, and stop old writes through an explicit cutover.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Strangler FigMartin Fowler
- Secure Software Development Framework (SSDF) Version 1.1National Institute of Standards and Technology
- Application Security Verification StandardOWASP Foundation
- Web Security Testing GuideOWASP Foundation
- SaaS Lens: General design principlesAmazon Web Services
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy