Assess the application, protect its behavior with automated tests, add a routing layer, build the first new piece alongside the old system, move its data and traffic, confirm, and repeat until the old system can be retired. Each step should be small, tested and reversible.
Why not a big-bang rewrite
A rewrite has to reproduce everything the old application does, including behavior nobody wrote down, and prove it all on switch-over day. Martin Fowler's strangler fig application (page dated August 2024) describes the alternative as a gradual approach to legacy modernization: build new functionality alongside the legacy code and move behavior over until the old system can be retired, the way a strangler fig grows around a tree.
Step 1: Assess the application
Map before you move:
- What it does, feature by feature, including reports and scheduled jobs.
- Who uses which parts, and how often.
- What data it holds, and which other systems read or write it.
- What is hardest to change and what breaks most.
Step 2: Choose the target for each part
Not every part needs rebuilding. Some can be retired, some replaced by a bought product, some moved with small changes. AWS's public list of seven strategies (retire, retain, rehost, relocate, repurchase, replatform, refactor) is a useful checklist for each part as well as each system.
Step 3: Protect current behavior with tests
Before changing anything, write automated tests that record what the application does today for its most important tasks. These become the regression suite; ISTQB defines regression testing as testing after modification to make sure nothing else broke. Run them in continuous integration on every change.
Step 4: Add a routing layer
Put a layer in front of the application, such as a proxy, gateway or façade, that receives every request and sends it to the old system. Later, the same layer sends selected features to the new code. Users see one application throughout.
Step 5: Build and switch the first piece
Start small, and learn the method on the first piece:
- Pick a piece that matters, fairly separate and not the riskiest.
- Build it in the new stack, with its own tests.
- Migrate or sync its data, and reconcile counts with the old system.
- Route a small share of traffic to it, watch errors, then route all of it.
- Keep the way back: the router can send traffic to the old code if needed.
Step 6: Repeat, then retire
Take the next piece, and the next, until the old system handles nothing. Then archive its data as required, switch it off, and remove the routing rules. Track progress with the DORA metrics (last updated January 2026): change lead time and change fail rate should improve as more runs on the new code.
Data: the hardest part
Data often outlives every application that touches it. Decide early whether the old and new parts share a database for a while, or sync between two. Test migrations on copies of real data, reconcile record counts and totals after every move, and keep personal data handled as your privacy policy says.
Conclusion
To modernize a legacy application without a big-bang rewrite: assess what it does, choose a target for each part, protect behavior with automated tests, add a routing layer, build and switch one piece at a time with data reconciled and a way back, and retire the old system when it handles nothing. Small, tested, reversible steps keep the business running throughout.
PromotEdge International is an international strategy, technology, marketing and design company, and our delivery team is in India. Our modernization team moves old applications piece by piece, tested at each step. We are not a partner of any cloud provider.
Facts we rely on: see our company facts for what we state about ourselves and where each fact comes from.