Every engineering leader inherits one eventually: the system that makes all the money and terrifies everyone who touches it. Mine was a telecom expense management platform serving 100+ Fortune 500 clients — companies auditing millions in telecom spend through software that had accumulated fifteen years of business logic, much of it written by people long gone, all of it load-bearing.

The standard temptations presented themselves on schedule. Rewrite it from scratch. Freeze it and build "v2" alongside. Both are the same mistake wearing different clothes: they assume you understand the old system well enough to replace it, and you don't. Nobody does. The monolith is the spec. Over nine years at Comview and then Calero MDSL, we took the slower road — incremental decomposition into Azure-hosted microservices — and the platform served clients every single day of it.

Extract along seams the business already recognizes

The first services we pulled out weren't the ones with the worst code. They were the ones with the cleanest business boundaries: vendor integrations. An API that talks to AT&T or Verizon or ServiceNow has a natural contract, an obvious owner, and a blast radius you can reason about. Each extraction taught the team the machinery — deployment pipelines, service contracts, monitoring — on a component where failure meant a degraded integration, not a corrupted invoice.

Only after the pattern was boring did we go after the scary interior: billing logic, rating engines, the code where fifteen years of edge cases lived. By then "extract a service" was routine, and routine is what you want when you're operating on the heart.

The monolith is the spec. You don't replace it — you interrogate it, one seam at a time.

The database is the real monolith

Splitting application code is the visible work. The hard coupling was in SQL Server, where every module joined against every other module's tables. Some of that we untangled with views and contracts, some with selective offload to Azure SQL, and a lot of it with plain performance engineering — because a query that's fast enough removes the pressure to redesign around it. I'd tell any team starting this journey: your service boundaries are fiction until the data respects them.

Modernize the front end on its own clock

We moved the UI to React in parallel, screen by screen, embedded inside the legacy application until enough screens existed to flip whole workflows. Users got improvements quarterly instead of a promised someday. That mattered more than aesthetics: visible progress bought patience from clients and executives for the invisible progress underneath — internationalization, global billing compliance, the unglamorous machinery of a platform sold on trust.

What nine years teaches you

Big-bang rewrites fail for a reason that has nothing to do with technology: they defer all risk to a single moment, and the organization loses its nerve before the moment arrives. Incremental decomposition inverts that — risk is spent in small, recoverable amounts, and every month the system is slightly better than the month before. It's less heroic. Nobody gives conference talks about the rewrite that didn't happen. But the clients never noticed a thing, and that was the entire point.