A blueprint for moving a fifteen-year-old monolith to cloud-native incrementally, using the strangler-fig pattern so the system keeps running while it is being replaced.
This is a blueprint, not a client case study. The situation described is a composite of the conditions we design for, not a named engagement. Targets below are measures we would baseline and report against — not results already achieved.
A fifteen-year-old .NET application runs order management for a distribution business. It handles every order the company takes. It runs on Windows Server 2016 in a datacentre with a lease that ends in eighteen months, and the last framework upgrade was abandoned halfway.
There are no automated tests. Deployment is a documented forty-minute manual procedure executed on Saturday evenings. Two developers understand it; one is eighteen months from retirement.
A rewrite was scoped two years ago at a number that did not get approved, and the estimate assumed requirements nobody had written down. Meanwhile the business needs three new integrations and a customer portal that the current architecture cannot reasonably support.
Every order flows through it. There is no maintenance window long enough for a cutover, and no fallback if one fails.
Any change carries unknown regression risk. Characterisation tests have to be built before meaningful refactoring can start.
Eighteen months is not negotiable. The plan must reach a runnable cloud state well before it, with margin.
The three integrations and the portal are commercially committed. Modernisation has to deliver them, not compete with them.
Both are needed for the work and one is leaving. Knowledge capture is a deliverable with a deadline, not a nice-to-have.
The shape of the solution, before any of the detail below.
Strangler-fig migration, one bounded context at a time
These are the calls that determine whether the engagement works — most of them made before any build starts.
Before refactoring, we build tests that capture what the system currently does — including the behaviour that is arguably wrong but that downstream systems depend on. These are not correctness tests; they are a regression net. Without them, every subsequent step is a gamble.
Containerise and move to managed infrastructure early, with the application essentially unchanged. This retires the datacentre deadline as a risk and gives the team a modern deployment pipeline to work with. Refactoring on top of a working CI/CD pipeline is a fundamentally different exercise from refactoring into a Saturday-night manual deployment.
New capability is built as separate services behind a routing facade, starting with the three committed integrations — which are new code anyway, so they carry no regression risk. Existing functionality is extracted afterwards, one bounded context at a time, with traffic shifted gradually and the old path kept warm until the new one has proved itself.
The schema moves in expand-contract steps: add new structures, dual-write, backfill, migrate reads, then remove the old. At no point do two systems own the same data independently, because reconciling divergent order data is a failure mode with no clean recovery.
The departing developer pairs on extraction work in the areas only they understand, with sessions recorded and architecture decisions written down as they go. Knowledge transfer scheduled as meetings at the end of a project does not survive contact with a notice period.
The customer portal is built against the extracted services rather than the monolith. It becomes the proof that the new architecture supports the business change the old one could not.
Durations are indicative for an engagement of this shape. Yours would be sized during assessment.
Map the system as it actually is, then build the characterisation test suite and pipeline that make change safe.
Activities
Move to the cloud with minimal functional change, retiring the datacentre deadline and establishing automated deployment.
Activities
Stand up the routing facade and build the three committed integrations as new services, delivering business value while establishing the target architecture.
Activities
Extract existing functionality context by context, with expand-contract schema evolution and gradual traffic shifting.
Activities
Deliver the customer portal on the new architecture and hand over to the internal team or into managed services.
Activities
Every one of these is baselined before work starts, so the comparison at the end is defensible rather than flattering.
| Measure | Target | How it's measured |
|---|---|---|
| Deployment frequency and duration | From Saturday-night manual to on-demand automatedDeployments per month and elapsed deployment time, baselined against the current forty-minute manual procedure. | Deployments per month and elapsed deployment time, baselined against the current forty-minute manual procedure. |
| Characterisation coverage on critical flows | Agreed floor before refactoring beginsCoverage measured specifically on business-critical order paths, not as a whole-codebase percentage. | Coverage measured specifically on business-critical order paths, not as a whole-codebase percentage. |
| Datacentre exit readiness | Cloud-running with margin before lease endProduction workload fully migrated and validated, tracked against the lease deadline as a programme milestone. | Production workload fully migrated and validated, tracked against the lease deadline as a programme milestone. |
| Change failure rate | Baselined at first automated releaseReleases requiring rollback or hotfix, tracked per release from the point the pipeline exists. | Releases requiring rollback or hotfix, tracked per release from the point the pipeline exists. |
| Bus factor | Above two on every extracted contextNumber of engineers who can independently work on each context, reviewed at each extraction milestone. | Number of engineers who can independently work on each context, reviewed at each extraction milestone. |
Named up front. A risk register written after something goes wrong is just a post-mortem.
Dependency mapping and characterisation tests surface coupling before extraction starts. Contexts are sequenced so the best-understood ones go first and build team confidence.
Knowledge capture is front-loaded into the first eight weeks and recorded, rather than scheduled as handover sessions near their exit date.
Expand-contract steps are executed one at a time with reconciliation checks between each, and never with two systems independently owning the same records.
The committed integrations and portal are built on the new architecture as part of the programme, so modernisation delivers business value rather than competing with it.
It never does. Tell us where yours differs and we'll tell you honestly whether we're the right people for it.
Or email us directly at reachus@segakiv.com