Every growing engineering team eventually hits the wall: the monolith that shipped the company to its first ten million in revenue is now the thing slowing every deploy, coupling every team, and turning a one-line change into a full-system regression risk. The instinct is to rewrite it as microservices. The graveyard of failed rewrites should give you pause. The big-bang rewrite — freeze features, rebuild for a year, cut over — fails so reliably it has its own folklore. There is a better way, and it doesn't require stopping the business to do it.
Why the big-bang rewrite fails
It fails for the same reasons every time. The business won't actually freeze for a year, so you end up maintaining two systems while feature requests pile up against the old one. The new system has to reach full parity before it delivers any value, so you carry all the risk and cost with zero return until the very end. And the old system's behavior is only fully documented in its code — every quirk you don't replicate is a production incident on cutover day. Rewrites concentrate all the risk into one terrifying moment. Incremental migration spreads it out so each step is small and reversible.
The strangler pattern: migrate in place
Named after the strangler fig that grows around a tree and gradually replaces it, this is the proven approach. You put a routing layer in front of the monolith, then extract one capability at a time into a new service. Route that capability's traffic to the new service, leave everything else hitting the monolith, and repeat. The monolith shrinks gradually as functionality moves out, until what remains is small enough to retire or keep. At every point you have a working, shippable system — and you can stop, pause for a quarter of feature work, and resume without penalty.
Choosing what to extract first
- Start at a natural seam — a bounded context with clear inputs and outputs, not a tangle wired into everything.
- Pick something with real pain or value: a component that needs to scale independently, changes often, or is owned by a team that wants autonomy.
- Avoid the shared core database tables on day one — the data is the hardest part, so begin with capabilities that own their data cleanly.
- Prefer a slice you can fully route and roll back, so the first extraction proves the pattern with low blast radius.
Data is the hard part, not the code
Splitting code is straightforward; splitting a database that everything reads and writes is where migrations stall. Plan for it explicitly. Identify which data each new service truly owns, and resist the urge to let services reach into each other's tables — that just rebuilds the monolith over the network, with worse latency. Use techniques like change data capture, dual writes during transition, and a deliberate plan for the queries that used to be a simple JOIN and now cross a service boundary. If you only plan one thing carefully in the whole migration, plan the data.
Don't over-correct into a distributed monolith
The opposite failure mode is just as expensive: shattering the system into dozens of tiny services that are so chatty and interdependent you've built a distributed monolith — all the operational pain of microservices with none of the independence. Microservices are an organizational tool as much as a technical one; the right boundaries usually mirror your team boundaries. Extract services because a capability genuinely needs to deploy, scale, or be owned independently — not because microservices are the fashion. Sometimes the right answer is a well-modularized monolith, and that's a legitimate destination.
How Infiniti Tech Partners runs migrations
We map the seams, sequence the extractions by risk and value, stand up the routing and observability so every step is safe and reversible, and handle the data split that stalls most migrations — all while your team keeps shipping features. No freeze, no big-bang cutover, no distributed monolith. If your architecture is slowing the business down and a rewrite feels too risky to attempt, start a conversation.
More reading
Fractional Engineering Teams: A CTO's Guide for 2026
When growth-stage CTOs in the US and UK choose a fractional engineering team over hiring, what they actually gain — and what tradeoffs to negotiate up front.
SecuritySOC 2 in 90 Days: The Engineering-Led Playbook
How a senior engineering team can take a growth-stage SaaS company from zero SOC 2 controls to a Type I attestation in 90 days — without buying a compliance platform.