.NET Engineering
ASP.NET Core services and enterprise APIs, including the unglamorous work of getting a fifteen-year-old system to talk to something built this year.
SOLUTION · MODERNIZATION
Legacy Modernization
The old system replaced in slices, while it keeps running.
TARGET PROFILE
Who this architecture is engineered for.
Built specifically for operational teams experiencing structural friction at scale.
The profile
For a business whose core system still works, still makes money, and costs more every year to keep alive — where a rewrite has been proposed twice and cancelled twice, and where the strongest argument against doing anything is that nobody is certain what would break.
The core bottleneck
The rewrite is proposed because the current system is expensive to change, and it is cancelled because the estimate covers eighteen months during which nothing improves and the old system must still be maintained. Both positions are correct, which is why the argument recurs. The way out is to stop treating replacement as one project. A boundary in front of the existing system lets traffic move component by component, so value arrives continuously and each step can be reversed on its own. It is slower on paper and considerably faster in practice, because the alternative is a plan whose only checkpoint is the end — and the risk in a full rewrite is not that any individual part is hard, but that all the unknowns arrive at once.
SYSTEM MODULES
What we build and integrate.
Every component is engineered for multi-tenant security, auditability, and zero-downtime maintenance.
An assessment naming what to replace, what to leave alone, and what to delete outright
A routing boundary in front of the existing system, so traffic can move gradually
Characterization tests describing current behaviour before anything changes it
Replacement components delivered one at a time, each live and reversible
Data synchronisation while both implementations are running
Comparison of old and new outputs against real traffic before the switch
A decommissioning plan, executed only after traffic is genuinely zero
ARCHITECTURE
System composition & topology.
How the core modules, data boundaries, and integrations connect in production.
Node 01
Routing boundary
The layer that decides, per request, whether the old or new implementation handles it. Every subsequent step depends on this existing first — it is what makes rollback a configuration change.
Connects to
- legacy
- replacement
- comparison
Node 02
Existing system
Kept running and largely untouched. Change to the system being replaced adds risk to both sides of the migration at once, so it is frozen except where necessary.
Connects to
- legacydata
Node 03
Replacement components
New services taking over one capability at a time, in the order determined by cost and risk rather than by which is most interesting to build.
Connects to
- newdata
- comparison
Node 04
Existing data store
The current database, which usually holds behaviour as well as data — stored procedures, triggers, and constraints that the application depends on without documenting.
Connects to
- sync
Node 05
Data synchronisation
Keeping both stores consistent while both are live, with a defined direction of authority per entity so a conflict has an answer rather than a discussion.
Connects to
- newdata
Node 06
Target data store
The modelled schema the replacement uses, migrated in batches with verification rather than in one transfer nobody can check.
Connects to
- comparison
Node 07
Parity checking
Running real requests through both implementations and comparing results before traffic moves. This is what turns confidence into evidence.
Connects to
- gateway
TECHNOLOGY DEPTH
Technologies powering Legacy Modernization.
Standardized architecture frameworks and data components integrated in this solution.
Frontend
- TypeScript
Backend
- .NET
- Node.js
Data
- Microsoft SQL Server
- PostgreSQL
Cloud
- Docker
- Azure
- Kubernetes
QUESTIONS & ANSWERS
Questions regarding legacy modernization.
Direct answers to common technical and engagement questions.
The estimate is usually lower and the outcome usually is not, because a rewrite defers every unknown to the end and requires the old system to be maintained throughout. Incremental replacement costs more in coordination and less in risk, and it delivers value from the first component rather than from the last. Where a system is genuinely small, a rewrite can be right — we will say so.
By writing tests that describe what the system currently does, including the parts that look like mistakes. Some of those quirks are load-bearing for someone downstream. Once behaviour is captured in tests, each one becomes an explicit decision to keep or change, rather than something discovered after a customer notices.
Yes, and new features should be built in the new components — which is part of what makes the migration self-funding rather than a pure cost. What we avoid is significant change inside the system being replaced, because that means both implementations are moving at the same time.
You have a working system with some components replaced and a boundary in front of the rest, which is a legitimate place to stop. That is a genuine property of this approach rather than a consolation: every step is independently valuable, so a pause is a pause and not a write-off.
It depends on how the existing system is coupled, which the assessment measures. What is more useful to know in advance is the shape: the first replaced component typically goes live early, and the schedule after that is a series of increments you can reprioritise, rather than a single date everything depends on.
Have something ambitious to build?
Tell us what you're working on. We'll tell you honestly whether we're the right team for it.