Case study
Two domains out of six, then the programme stopped.
A German subscription e-commerce company of about 60 staff, with checkout inside a .NET monolith that shipped once a month. A team growing from two engineers to four extracted checkout by strangler fig over 10 months and took deploys to three a week. The remaining four domains were never started: the client paused the programme for a funding round.
The situation
Everything shipped together. Checkout, catalogue, subscriptions, billing, the admin tools, and the storefront were one .NET deployment on a monthly release train, so a change to the checkout flow waited up to four weeks for the next window, and a failure anywhere in the release rolled the whole thing back — checkout included.
The client had already written the plan: six domains, extracted in order, checkout first because it was the one costing them releases. They asked us to run it with two engineers and to say early if the order was wrong. It was not wrong, and we said so.
What we did
Strangler fig, which means the monolith stays in front until it does not. A routing layer sent checkout requests to a new TypeScript service and everything else to the .NET application, path by path, so traffic moved in slices rather than at a cut-over. Each slice ran on the new path with the old one still able to take it back.
Checkout and its React front end came out first; a second domain followed. Infrastructure went into Terraform on AWS as we went, so the second extraction reused what the first had built and took less time than it. The team started at two engineers and went to four once the routing layer was carrying live checkout traffic. Four is past the three-engineer line we now hold staff augmentation to, and this is the engagement that drew it: the shape should have moved to a dedicated team with a named lead when it grew, and it did not.
What changed
Deploy frequency went from one release a month to three a week, measured on the client's own pipeline. The two extracted domains deploy independently of the .NET monolith and of each other, so a checkout change no longer waits on the release train and no longer takes the rest of the platform with it when it fails.
That applies to two domains. The other four still ship on the monthly train, unchanged.
How it ended
The client paused the programme to run a funding round, and has not restarted it. Two of six planned domains were extracted in 10 months. Four were not.
The routing layer is still in place, so the platform sits half-migrated: two services outside the .NET monolith, four domains inside it, and a routing layer that has to be maintained for both. That is a more expensive shape to run than either the monolith on its own or the finished extraction, and it is where the engagement stopped.
The extracted services are TypeScript on AWS against PostgreSQL, provisioned with Terraform, and the storefront pieces that moved with checkout are React. Five of the ten technologies we staff against. The .NET monolith is the client's and still holds the four domains that were not extracted.
Deploys, and how far the programme got
Checkout waiting on a monthly release train?
Two to four engineers, strangler fig, 10 months to the second domain. Ask about the half-migrated shape a paused extraction leaves behind before you plan one.