The Real Cost of a Legacy Monolith Migration 

One of our logistics engagements involved a client running a legacy .NET monolith that handled daily distribution operations, including routing, inventory, and dispatch, for a regional operator. The system worked, in the sense that orders still shipped every day. It also hadn't been meaningfully re-architected in years, response times were degrading as load grew, and every new feature took longer to ship than the last one because the codebase had no clean boundaries left to extend. The client's instinct, like most clients in this position, was to ask for a rewrite. We didn't do that, and the reasons why are the actual cost story of a monolith migration.

Why We Didn't Rewrite

A full rewrite means running two systems in parallel for the length of the project, maintaining feature parity with the old system while building the new one, and cutting over all at once at the end. The same big-bang failure mode that shows up in delivery timelines shows up in migrations too, just with higher stakes, because the thing being replaced is already running your business. If the cutover reveals a gap in the new system, there's no old system left to fall back to gracefully. For a logistics operator running daily distribution, an unplanned outage isn't an inconvenience: it's trucks not leaving the depot.

The Strangler-Fig Pattern

Instead, we used the strangler-fig pattern: new capabilities get built as independent services alongside the monolith, an API gateway routes traffic to either the old system or the new services depending on which one currently owns that piece of functionality, and the monolith's footprint shrinks incrementally as more of it gets replaced, until eventually there's little or nothing left of the original system to retire. The name comes from the way a strangler fig grows around a host tree until the tree is no longer structurally necessary. The migration equivalent is that the business never stops running on a working system, because at every point in the project, either the old code or the new code is handling a given piece of functionality: always one of the two, never neither.

Where the Infrastructure Cost Actually Went

We moved the new services onto Azure Kubernetes Service, behind an API gateway that handled routing and became the natural place to add rate limiting and auth without touching either the monolith or the new services directly. The real infrastructure cost wasn't compute; it was the discipline of defining clean service boundaries around a codebase that had none, and building the gateway routing logic carefully enough that a request never silently hit both systems or neither. We also added real-time IoT tracking dashboards as part of the new services layer, which is exactly the kind of feature that would have been expensive to bolt onto the old monolith and was comparatively cheap to build fresh once it had a proper service boundary of its own.

What It Actually Delivered

The measurable outcomes were minimal downtime during cutover, since there was never one single cutover, just a long series of small, reversible ones; faster API response times on the migrated functionality; and lower infrastructure overhead once the monolith's footprint shrank enough to reduce its own hosting costs. None of those outcomes required betting the business on a single go-live date. That's the actual cost argument for strangler-fig over a rewrite: it's not necessarily cheaper in total engineering hours, it's that the risk is distributed across many small, recoverable steps instead of concentrated in one irreversible one.

When a Rewrite Is Still the Right Call

None of this means monoliths should always be strangled rather than replaced. If a system is small enough that a rewrite fits inside a few sprints, or so fundamentally broken that no part of it is worth preserving, a clean rewrite can be the faster path. The judgment call is proportional to what's at stake if the migration goes wrong mid-flight. For a system running daily operations for a live business, the strangler-fig pattern's incremental risk profile is usually worth the additional architectural discipline it demands.