Core service
Modernise without stopping the system
A full rewrite is the most expensive and riskiest path. With incremental migration, the old system keeps running while the new one comes online piece by piece.
- Duration
- 3 to 12 months
- Model
- Staged programme
- Output
- A working, measured system
Signs you need modernisation
An old system is not a problem in itself. The problem is that the cost of change rises a little more every quarter.
- The framework or runtime version no longer receives security patches.
- A change in one module breaks things in unrelated places.
- Fewer and fewer people understand the system, and the knowledge is written down nowhere.
- New features are added by working around the existing code.
- Test coverage is so low that every release needs manual checking.
- Hosting or licence costs grow out of proportion to the value the system produces.
Why we do not rewrite from scratch
Rewrite projects almost always underestimate the business rules an old system has accumulated over the years. Until the new system is ready, the old one still has to be developed, and two systems need maintaining at once.
Incremental migration uses the Strangler Fig pattern: new capabilities are built on the new side first, and old ones are moved across one by one through traffic routing. Every step can be rolled back, and every step is verified in production.
The business does not stop. Delivery keeps its pace while the system’s risk falls a little further at each stage.
Scope
Included
- Defining migration boundaries (DDD context map)
- Migration sequence and a rollback plan for every step
- Routing layer and anti-corruption layer
- Data migration and dual-write strategy
- Migration from .NET Framework to modern .NET
- Automated testing and delivery pipeline
- Measurement and reporting at the end of each stage
Not included
- Redesigning product features
- Redesigning the user interface
- New feature work unrelated to the migration
- Hardware and data centre moves
How the programme runs
- Stage 1Map. The system is split into business contexts, dependencies are traced and the first piece to move is chosen. The choice weighs business value against risk.
- Stage 2Scaffolding. The routing layer, observability and automated delivery are put in place. Safe migration is not possible without them.
- Stage 3First slice. The first context moves to the new side and runs alongside the old system in production. Results from both sides are compared.
- Stage 4 onwardsRepeat. The remaining contexts move at the same rhythm. Each slice is approved separately, and the programme can be stopped at any point.
What you receive at every stage
The programme is split into stages, and each stage delivers value on its own. Even if the programme stops early, completed stages keep running.
Who this service is not for
- Organisations planning to shut the system down within a few months. A system about to be retired is not worth modernising.
- Projects that must finish the migration in one go on a fixed date. Incremental migration needs flexibility.
- Organisations that cannot provide access to, or knowledge of, the existing system.
Frequently asked questions
Does the system keep running during modernisation?
Yes. That is the core principle of incremental migration: traffic moves to the new side step by step, and every step can be rolled back.
How long does it take?
It depends on the size of the system and the number of contexts. A typical programme runs three to twelve months; the first slice usually reaches production within the first two months.
Do we have to start with an assessment?
It is not mandatory, but we recommend it. A migration plan made without knowing the current system’s boundaries and risks is guesswork. An Architecture Assessment answers that question in two to three weeks.
Is our team involved in the migration?
Yes, and it should be. At the end, your team will run the system. The work happens alongside your team, and knowledge transfer is part of the programme.
What happens if the programme is stopped halfway?
Completed stages keep running. Each stage is finished work on its own; we do not leave a half-done migration behind.
Who owns the source code?
You do. The code, infrastructure definitions and documents are your property from day one.
Let’s map your system together
In a thirty-minute call you describe the system, and we tell you where the migration should begin.