Architecture

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

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.