Extracting a new service from a legacy system without stopping the business
30 June 2026 · 9 min read · SmartCG
When the product can no longer be developed safely as a whole, the answer is often not a full rewrite but carefully extracting one critical service.
A full rewrite is rarely the best first step
When a legacy system starts choking the product, the business naturally wants to "do it properly from scratch". In a live operational environment that usually means too much risk at once: keeping the current system running, agreeing on a new architecture, migrating data and retraining the team simultaneously. A more controlled first step is to take one critical service out and prove the new approach on it.
How to choose what to extract first
- The module constantly slows down changes and touches too many neighbouring parts of the system.
- A business-critical scenario passes through it: orders, billing, documents, access, the customer cabinet.
- Its boundaries are clear enough to separate responsibility and data.
Where these projects usually break
Not in the service code but at the boundaries. Teams underestimate how data will be synchronised, who becomes the system of record, which operations must stay synchronous and which can move to an asynchronous mode. If those questions are not answered in advance, the new service works in isolation and the business sees no improvement.
What has to be designed before the start
- Responsibility boundaries: what the new service owns and what stays in the old system for now.
- The data model: where truth lives, how changes propagate and how conflicts between systems are avoided.
- The integration route: API, events, queues or a temporary adapter.
- The rollback plan for the first weeks in production.
Why this approach is better for the business
It delivers value in stages. Instead of a long project of hope, the company gets a controlled change where the result is visible on a critical scenario and nothing else is put on pause. That matters especially when the product is already live and a failed migration is more expensive than a slow one.
What counts as a good outcome
Not a new service as a technical artefact, but a new growth point: faster changes, clearer ownership, less dependence on the old system and a base for the next modernisation stage without abrupt, risky moves.
Services involved
Read next
Moving from a legacy monolith to services without downtime
A practical account of splitting a legacy monolith for a logistics company without a single maintenance window.
ArchitectureWhat is cheaper: fixing the old system or building a new one alongside
The question is almost never 'rewrite everything or nothing'. Usually the business needs to know what is cheaper right now: stabilise, extract the critical part, or start something new alongside.
ArchitectureWhen legacy slows the business down, not just the team
How to tell that the problem is no longer awkward code, but a system that is slowing down money, deadlines and control.
Need to move one service out without downtime?
We define boundaries, the data model and the integration route first, then migrate the service in stages with a rollback path.