Splitting a monolith without a rewrite

The impulse to "break up the monolith" often turns into a rewrite project. Rewrite projects are expensive, take twice as long as planned, and ship less than promised. A more disciplined approach is available and rarely taken.

Written January 2026 from a set of platform decomposition projects.

What the rewrite path assumes

• The existing code is unsalvageable.
• Extracting incrementally is slower than starting over.
• The team has enough context to build the right thing on the second try.

None of these are usually true.

What works instead

• Extract at the seam. Identify a bounded piece of functionality with clear inputs and outputs. Extract it into a separate service, with the monolith calling it via a well-defined contract. Nothing else changes.
• Ship the extraction first, then evolve. The first extraction is a copy of what the monolith did. Evolution comes later, after the seam is stable.
• Keep the old code path available. For a while, both the extracted service and the monolith code exist. Traffic gradually moves.
• Retire the old path only when the new one is proven. "Proven" means real traffic, real load, real edge cases. Not "seems to work".

The order of extraction

• Extract the noisiest parts first. What generates the most incidents? What has the highest churn? Those are the pieces where the operational benefit of separation is greatest.
• Don't extract stable, quiet code. It's stable and quiet; leave it in the monolith.

The success criterion

The success of a decomposition isn't measured in service count. It's measured in the team's ability to make changes independently, deploy safely, and diagnose failures without the whole system as context. If service count went up and those metrics didn't improve, you didn't split the monolith; you added new problems on top of the old one.

Rewrites feel decisive. Extraction feels slow. Extraction ships.