From Monolith to Microservices: A Decision Framework for CTOs
Migration is a business decision before it's a technical one. Here's how to make it deliberately — and how to recognise when "modular monolith" is the better answer.
The most expensive architecture decision is the one made by default
Every few years, "migrate to microservices" becomes the default answer to a slow engineering organisation. The logic feels airtight: deployments are slow, the codebase is tangled, onboarding takes months, and a bug in one module can take down the whole system.
Microservices promise to fix all of it — independent deployment, fault isolation, team autonomy, targeted scaling.
The promise is real. So is the failure rate. Industry practitioners consistently report that close to half of monolith-to-microservices migrations fail to deliver their intended outcomes, and the "big bang" rewrite — tearing down the monolith and rebuilding it as services in one effort — fails the overwhelming majority of the time. The most common failure mode isn't staying on the monolith. It's building something worse: a distributed monolith, where you've taken on all the operational complexity of a distributed system while keeping all the coupling of the original.
This article isn't an argument for or against microservices. It's a framework for deciding deliberately — because the decision made by default, on the strength of the hype, is the one that tends to go wrong.
First, separate the symptoms from the cause
When a CTO says "we need microservices," they're usually describing symptoms, not diagnosing a cause. The symptoms are real:
- A small change requires a full-application deploy
- Releases are slow and risky, so they're batched, which makes them slower and riskier
- One team's work blocks another's
- Scaling means scaling everything, even the parts under no load
- New engineers take months to become productive
Here's the uncomfortable question: are these caused by the monolith being a monolith, or by the monolith being a badly structured monolith? Because most of these symptoms come from poor modularity, unclear ownership boundaries, and missing test coverage — none of which microservices fix automatically. In fact, microservices make all of them harder if the boundaries weren't clear to begin with.
The first step in any migration decision is to ask: if we drew clean module boundaries inside the current monolith, how many of our problems would disappear? If the answer is "most of them," you may not need microservices at all. You may need a modular monolith — and that's a legitimate, increasingly respected destination, not a consolation prize.
A decision framework: five questions before you migrate
Before committing to a migration, work through these five questions honestly. Each one is a gate. If you can't answer it clearly, that's a signal to slow down.
1. What business outcome are we actually buying?
Microservices are a means, not an end. The migration has to be tied to a business outcome you can name and measure: faster time-to-market for a specific product line, independent scaling of a high-load component, team autonomy that unblocks parallel roadmaps, or reduced blast radius for a system where downtime has real cost.
If the honest answer is "the architecture feels outdated" or "everyone's doing microservices," stop. That's not a business case; it's an aesthetic preference, and it won't survive the first hard quarter of migration work.
2. Are our domain boundaries actually clear?
Microservices encode your domain boundaries into network boundaries. If you don't know where one domain ends and another begins, you'll draw service boundaries in the wrong place — and then every feature will require changes across multiple services, coordinated deployments, and distributed transactions. That's the distributed monolith: maximum complexity, minimum benefit.
If your boundaries aren't clear, the prerequisite work is domain modelling, not service extraction. Get the boundaries right inside the monolith first. Services come after.
3. Can our organisation actually operate distributed systems?
A microservices architecture isn't just a code pattern; it's an operational commitment. Each service needs deployment automation, observability, on-call ownership, security policy, and a team that understands distributed-systems failure modes. The hidden cost of microservices in 2025 isn't the code — it's the platform engineering, the observability tooling, the FinOps discipline, and the headcount to run it all.
If you don't have a platform team or a path to building one, microservices will turn your engineers into part-time infrastructure operators. Be honest about whether your organisation is ready to run what it's about to build.
4. Do we have the test coverage to migrate safely?
You cannot safely decompose a system you can't verify. If your monolith has thin test coverage, every extraction is a gamble. Before migrating, you need characterization tests (capturing what the system actually does today), contract tests (defining the boundaries you're about to formalise), and ideally a parallel-run capability (running old and new side by side and comparing outputs).
This is unglamorous work, and it's the work most migrations skip — which is exactly why they fail.
5. Can the business absorb a multi-quarter effort without a freeze?
A migration that requires freezing the product roadmap is almost always the wrong plan. The business rarely survives a six-month feature freeze, and the migration rarely finishes on schedule. If your only viable plan requires stopping product work, you don't have a migration plan — you have a rewrite, and rewrites fail.
The right migration runs alongside product work, in slices, each delivering value. If you can't see how to do that, the plan needs rework before any code is written.
The three honest destinations
After working through the framework, most organisations land in one of three places. All three are legitimate.
Destination A: Modular monolith. You don't migrate. You invest in clean module boundaries, clear ownership, and strong test coverage inside the existing application. You get most of the maintainability benefit without the operational cost. For a large share of mid-size product companies, this is the right answer — and the most under-recommended one, because it doesn't sell consulting hours or sound impressive in an all-hands.
Destination B: Incremental decomposition. You migrate, but gradually, using the strangler fig pattern: wrap the monolith, route new functionality through the wrapper, and extract services one bounded domain at a time, highest-value or highest-pain first. The monolith shrinks over quarters, not weeks. The business never freezes. This is the destination for organisations that genuinely need service-level independence and have the operational maturity to run it.
Destination C: Selective extraction. You keep the monolith as the core and extract only the few components that genuinely need independent scaling or deployment — a high-traffic payment service, a compute-heavy ML inference pipeline, a component with a wildly different change frequency. Everything else stays put. This pragmatic middle path is often the highest-ROI option, and it's frequently overlooked in favour of all-or-nothing thinking.
Notice what's not on this list: the big-bang rewrite. There's a reason for that.
Recent blog posts
Compare software project kickoffs in Europe and the USA: speed vs risk reduction, discovery depth, and what to standardize for stronger delivery.
