Monolith to microservices: the migration nobody talks about

TL;DR: The industry has swung to "don't migrate — monoliths are fine." Our CTO's answers point the other way: done incrementally — two endpoints at a time, monolith running throughout — the move to microservices is the least dangerous refactor in the catalog, extraction stabilizes the platform, and the decision is financial, not technical. The one real risk: the half-gutted monolith that never dies.

"This is a business decision, not a technical one."

Not what I expected our CTO to say about breaking up monoliths. I went into the conversation with the fashionable 2026 questions — aren't most migrations failures? isn't the modular monolith the grown-up answer? — and Jan, who has spent years inside these systems on both sides of the split, gave me none of the fashionable answers. What follows is the migration playbook that's too boring for conference talks. Which is exactly why it works.

What monolithic architecture is — and why starting there wasn't a mistake

Definitions first, because the search term deserves them. A monolithic architecture (a monolith) is an application built and deployed as one unit: user interface, business logic, and data access in a single codebase, typically over a single database. Its counterpart, microservices architecture, splits the application into independently deployable services that communicate over the network.

If your scaleup runs on a monolith, that was almost certainly the right call at the time. One codebase, one deploy, no network boundaries to debug — it's the fastest way to find product-market fit, and the industry's most-quoted defender of the pattern is right about the trap on the other side. As David Heinemeier Hansson put it in The Majestic Monolith: "The patterns that make sense for organizations orders of magnitude larger than yours, are often the exact opposite ones that'll make sense for you."

That essay is from 2016, and in the decade since, the pendulum has swung its way. The 2026 consensus mood is migration-skeptical: horror stories of distributed monoliths, sermons about modular monoliths, "you are not Netflix" as a closing argument. Much of that skepticism is earned — by a specific kind of migration. The eighteen-month big-bang program with a target architecture diagram of thirty services. That version deserves its reputation.

It's just not the version worth talking about.

"A business decision, not a technical one"

Jan's first answer reframed the whole question. Whether to split a monolith, he argues, is a question of finances. The only situation where he'd advise a founder against it: your existing monolith works well, it isn't causing you problems, and you need to invest the cash elsewhere. That's it. That's the entire counter-indication — and notice it contains no architecture. It's an opportunity-cost statement.

This lands differently than the usual framing, so let it land. The conference debate treats the split as a technical identity question — are we a microservices team or a monolith team? Jan treats it like any other capital allocation: the split costs money, it returns stability and optionality, and the return competes with everything else you could fund. Some quarters it wins. Some quarters the new market wins. Neither answer says anything about your engineering maturity.

And on the returns side, he holds a view you won't hear at the skeptics' table: every time you extract a small component from a big monolith, the platform as a whole gets more stable. Not "can get" — gets. Each extraction shrinks the blast radius of the remaining monolith, gives one workload its own failure domain, and leaves the core simpler than it was. The stabilization is the point, not a side effect.

The least dangerous refactor in the catalog

Here's the claim that would start an argument at most architecture meetups, quoted nearly verbatim: compared to other refactors, refactoring toward microservices carries the least danger.

The reasoning is mechanical, not ideological. You take two endpoints. You separate them into a service. Everything else keeps running on the monolith, untouched, in production, exactly as yesterday. Then you take the next piece. And gradually — months, sometimes years — you whittle the monolith toward zero.

Compare that to the refactors people undertake with far less fear. A big in-place restructuring of a monolith's core touches everything at once; the failure modes are entangled and the rollback story is ugly. A framework migration rewires the whole application's nervous system. The incremental service split, done properly, is the only major refactor where the unit of risk stays as small as you want it — two endpoints — and where production never stops being production. Martin Fowler gave the pattern its name years ago (the strangler fig); we've used the same logic to move a live platform between frameworks without downtime. The migration nobody talks about is exactly this: boring, gradual, reversible at every step.

Why does nobody talk about it? Because there's no keynote in it. "We moved two endpoints and everything kept working" doesn't trend. The eighteen-month transformation program has a slide deck, a budget line, and a conference talk; the whittle has a long series of small pull requests and a platform that gets quietly more stable every quarter.

The one risk nobody prices in: the monolith that never dies

Jan named exactly one real risk in the incremental path, and it's not technical failure. It's that you never finish. The gutted monolith — three-quarters emptied, still hosting the awkward last workloads nobody wants to touch — can live forever, and every year it lives, you pay two operational overheads instead of one.

This is worth pricing honestly, because it's where the finance frame bites back. An incremental migration that stalls at 70% delivers most of the stability benefits and still leaves you running two worlds indefinitely. So treat the tail like a project of its own: the last extractions are the hardest and least rewarding, they will not happen by momentum, and if you're not willing to budget for them eventually, decide upfront that a permanently hybrid architecture is acceptable. Sometimes it genuinely is — the emptied monolith hosting the boring remainder is still simpler than the monolith you started with. Just make it a decision, not an accident.

The PHP exception that changes the math

One of Jan's points I haven't seen in any of the ranking guides, and it matters to a huge share of real systems: your language decides whether you even have the modular-monolith option.

The skeptics' favorite alternative — keep one deployable, enforce module boundaries inside it — is real in Java, .NET, or Go, where the language and tooling can enforce internal boundaries you can run directly in code. PHP has no equivalent. There is no in-process mechanism that gives a PHP monolith genuinely enforced module isolation; the boundaries live in convention and code review, and convention erodes under deadline pressure. For PHP systems, the only boundary that actually holds is a service boundary.

That's not a niche caveat. PHP runs the server side of roughly three-quarters of websites whose server language is known — including the enormous population of Laravel and Symfony platforms that scaleups are built on. If that's your stack, the "just do a modular monolith" advice from the Java world doesn't transfer. Your realistic choices are a disciplined monolith or real services, and the middle path the conference talks promise you quietly doesn't exist.

What a well-bounded service looks like

Let me be precise about a case I'd otherwise be tempted to oversell. Previo, the most widely used hotel system in the Czech Republic, runs a channel manager we built — Symfony, RabbitMQ, event-driven — that syncs 100,000+ reservation updates a day across 10+ booking platforms and hasn't lost a reservation in seven years of production.

Honest labeling: this was not carved out of their monolith. It replaced a failing third-party service. But it shows exactly what the destination of any good split looks like — and why some workloads deserve their own service on day one. The channel-manager workload is everything a core hotel-management system is not: massively concurrent, spike-prone, integration-heavy, and failure-sensitive in its own specific way (a lost message is a double-booked room). Giving that workload its own event-driven service, with a message queue absorbing the spikes, means it scales on its own profile and fails in its own compartment. The rest of Previo's platform never needed the same treatment — which is the boundary lesson in one sentence: services follow workloads, not fashion. The architecture is boring on purpose, and boring is what zero lost reservations looks like.

Would you really start with microservices on day one?

The answer of Jan's that surprised me most: given the choice, he'd go microservices from the start — even on a small project with a small team — because gutting a monolith later can cost far more than the early overhead. Ten years of industry consensus says the opposite: monolith first, split when it hurts.

I'll give you his position straight rather than sanding it down, because the reasoning is consistent with everything above: if the incremental split is cheap and safe, starting split is cheaper still — you skip the whittling entirely. The overhead objection has also genuinely shrunk: the tooling, the deployment platforms, and AI-accelerated delivery have all lowered the cost of running a few services compared to 2016, when DHH's essay was written.

Where does that leave a founder? Back at Jan's own first frame, which quietly resolves the disagreement: it's a business decision. Day-one microservices is a bet that your product will live long enough for the monolith-gutting bill to arrive. For a validated product with committed funding, that bet looks better than the industry's reflexive monolith-first advice admits. For an unvalidated idea, the 30-day MVP logic still wins — the cheapest architecture is the one that gets you learning fastest, and you can hold Jan's playbook in reserve knowing the split, when it comes, is the least dangerous refactor in the catalog.

How to decide — with evidence instead of fashion

Strip out the ideology and the decision inputs are measurable. What does each candidate workload cost you today in incidents, coupling, and blocked roadmap? What would its extraction cost in senior weeks? What else competes for that cash this year? And — the question that catches the monolith-that-never-dies risk — what's the realistic end state you're willing to fund: zero, or a deliberately hybrid platform?

For the first two questions, the danger-of-change mapping in a €5,000 audit answers them component by component — which parts of your monolith are risky to touch, what each candidate seam would cost to cut, in manhours. From there it's the capital-allocation conversation Jan says it always was.

FAQ

What is monolithic architecture?

An application built and deployed as a single unit — UI, business logic, and data access in one codebase, usually over one database. It's the fastest architecture for early-stage products and remains the right choice while the system works well and capital is better invested elsewhere.

Is migrating from a monolith to microservices risky?

The big-bang version is. The incremental version — separate two endpoints into a service, leave everything else running on the monolith, repeat — carries less danger than most in-place refactors, because the unit of risk stays tiny and production never stops. The main risk isn't breakage; it's stalling and running a half-gutted monolith indefinitely.

When should you not migrate to microservices?

When the monolith works well, causes no real problems, and the money is needed elsewhere. The decision is financial, not technical: extraction returns stability and optionality, and that return has to beat everything else you could fund with the same cash.

What is a modular monolith, and is it a real alternative?

One deployable with enforced internal module boundaries. It's a genuine option in Java, .NET, or Go, where tooling can enforce isolation in-process. In PHP there is no mechanism that enforces it directly in code — boundaries hold only by convention — so for the huge population of Laravel and Symfony platforms, the practical choice is a disciplined monolith or real service boundaries.

Which component should be extracted from a monolith first?

The workload that's most unlike the rest: different scaling profile, spike-prone, integration-heavy, or carrying its own failure sensitivity. Our client Previo's channel manager is the shape to aim for — an event-driven service handling 100,000+ daily updates next to a core platform that never needed splitting. Services follow workloads, not fashion.

How long does a monolith-to-microservices migration take?

The honest answer: as long as you keep funding it, because the increments are independent. Two endpoints can be running as a service within weeks; whittling a large monolith toward zero takes years — and the final extractions are the hardest and least rewarding, so decide early whether zero is really the goal or a deliberately hybrid end state is acceptable.

Should a startup begin with microservices instead of a monolith?

Our CTO's view — against the fashion — is yes when you can afford it, because gutting a monolith later costs more than early service overhead, and that overhead has shrunk with modern tooling and AI-accelerated delivery. For unvalidated ideas, speed-to-learning still wins; the split can wait, and done incrementally it will be the least dangerous refactor you undertake.

The boring migration wins

The monolith-to-microservices debate stays loud because both camps argue about the dramatic version. The version that works is quiet: a financial decision, made on measured danger-of-change, executed two endpoints at a time on a platform that never stops running — with an honest plan for either finishing the whittle or living deliberately with what remains.

If your monolith is at that fork — hurting enough to ask, valuable enough to be careful — book a 30-minute call. We'll tell you which seams your system actually has, what each cut would cost, and whether this year's cash should fund the split at all.