The system that outlived its architecture
Modernize the application without stopping the business
We modernize applications that still earn their keep but have become expensive to change: strangling the monolith a piece at a time, replacing the data layer underneath, and shipping continuously while it happens. No eighteen-month rewrite, and no freeze on the features the business is waiting for.
- Who it is for
- Engineering leaders whose release cadence is falling and cannot stop shipping
- Bench
- 115+ engineers, averaging 15 years each
The rewrite that runs alongside the old system, catches up in eighteen months and switches over cleanly has been attempted many times. What usually happens is that the business keeps needing changes, both systems get them, and the new one never quite arrives.
How it works
- A seam found first, so the first piece can move without touching the rest
- New work built on the new path, so the change pays for itself from the first month
- The old system kept running and released from throughout, never frozen
- Data layer replaced underneath rather than in a single cutover weekend
- Tests written around the behaviour before it moves, because that is the only safety net that survives a refactor
- Each step reversible, so a bad call costs a week rather than a quarter
The strangler fig, and when it's the wrong pattern
A strangler fig puts a facade in front of the old system and routes each request either to the legacy code or to the new service that replaced that piece. It's how most modernization ships without a feature freeze. At first nearly everything goes to the old system. Piece by piece the routing shifts, until the legacy application handles nothing and can be switched off, and finally the facade itself is removed.
Microsoft's architecture guidance is unusually direct about when not to use it. If requests to the back end can't be intercepted, it doesn't work. If you can't change the legacy source code, you can't switch off the parts that have moved, and if the system is small enough to replace whole, or has to go quickly, the facade is overhead.
The same page warns that the facade can become a bottleneck or a single point of failure, and that the new and old systems will need an anti-corruption layer between them while both are live, so the new code doesn't inherit the old one's conventions.
Checked on 11 October 2026 against Microsoft Learn: Strangler Fig pattern.
How the work runs
01
Find the hotspots
The module that changes most often and costs most to change. Version control answers the first half in one command (below), and the people who ship it answer the second.
02
Pin the behaviour with tests
Tests written around what the code does today, before any of it moves, because they're the only safety net that survives a refactor.
03
Put a facade at the seam
A gateway, a load balancer rule or an API layer that can route that one capability to new code, with the old path still there behind it.
04
New work goes on the new path
Features the business is waiting for are built on the new side, so the change starts paying in its first month and the old system keeps releasing.
05
Move the data last, in stages
Domain tables are copied to their own database and kept in step with change data capture while both systems run. Rollback stays possible until the legacy tables are removed, so that removal is a deliberate final step for each domain.
06
Retire the old path
Once no traffic reaches the legacy code for a capability, that code is deleted. When the last capability has moved, the facade goes too.
Modernize in place or rewrite: the deciding questions
- Can requests to this capability be intercepted at one point?
- Do you have the legacy source code, and can you still build and deploy it?
- Which modules changed most in the last year, and which of those are the most expensive to change?
- Which tables does more than one domain write to?
- Is the system small enough to rebuild in a few months?
- What does the business need shipped in the next two quarters, whatever happens to the architecture?
git log --since="12 months ago" --name-only --pretty=format: \
| grep -v '^$' | sort | uniq -c | sort -rn | head -20Clients we have done this for
Automotive / Fintech
iLending
An auto refinance platform modernised in place. Lead and loan officer assignment, rate sheet processing and stipulation documents were automated, and CRM integration and API performance improved.
Automotive / Fintech
Location Services
A data layer replaced underneath a running business, moved off Synapse and SQL Server onto Databricks in reversible waves.
FAQ
Application modernization: common questions
Can you modernize an application without a feature freeze?
Yes, and it is the only version we would propose. A freeze puts the business on hold to suit the engineering plan, and it is why so many of these projects get cancelled halfway. New work goes on the new path while the old system keeps shipping, so the change earns from the first month rather than the eighteenth.
What about the database?
Usually the hardest part and rarely the part that gets planned properly. We replace it underneath in stages rather than in one weekend, which means a period of running both and a deliberate decision about which is authoritative for what. That period is uncomfortable and it is much safer than the alternative.
How do you decide what to modernize first?
The piece that is changed most often and costs the most to change, which is not always the piece that annoys the engineers most. That ordering means the benefit shows up early enough to keep the work funded.
Is a rewrite ever the right answer?
Sometimes, when the system is small enough to rebuild in a few months or when the domain has changed so much that the old model is actively wrong. It is rarer than it feels from inside the codebase, and we will say so if we think it applies.
The rest of cloud
Cloud migration
Infrastructure and platform leaders with a deadline and a partial inventory
Cloud transformation
CTOs and platform leaders holding a cloud bill that outgrew the business case
Azure consulting
Engineering and infrastructure leaders on Microsoft's cloud, or moving onto it
AWS consulting
Engineering leaders running production on AWS, or moving a workload there