A Swiss financial product passes its audits, clears its payments, and misses its third roadmap commitment in a row. The board sees a stable platform. The engineering team sees a single codebase that has absorbed ten years of regulatory features, partner integrations, and one-off exceptions, where a change to statements can stall a change to onboarding because both share tables, jobs, and the same production window. The scenario is representative of a pattern that repeats across regulated Swiss software. It is not a single client account, and no individual company is described here.
What usually gets blamed is code quality. That is rarely the actual cause. The system was right for a smaller licence, a smaller customer base, and a smaller team. Those assumptions expired, and nobody renegotiated the architecture when they did. A monolith becomes a business problem when its founding assumptions stop being true, not when its code gets old.
Why this is harder than the problems next to it
Two adjacent problems get solved every week and make this one look easier than it is. A lift-and-shift migration moves a system to new infrastructure without changing its boundaries; the work is large but the shape of the system stays put. A performance bottleneck has a locus: one query, one queue, one service that can be measured, tuned, or scaled.
A roadmap-blocking monolith has neither property. The constraint is not where the system runs or how fast it runs. The constraint is that too much of the business has to change in one place. That makes it an organisational and sequencing problem wearing a technical costume, which is why buying faster hardware or better tooling does not move it. CI, observability, and environments may all need attention in such an estate. They are still not the constraint.
Where it actually costs
Estimates turn into diplomacy. Two weeks means six, not because the work is conceptually hard, but because the work keeps discovering a third system that still expects yesterday's shape of the data. Teams learn to pad, product learns to distrust the padding, and planning becomes a negotiation about credibility rather than scope. The cost is not the delay itself. It is that the organisation loses the ability to make commitments it can keep.
Senior time drains into coordination. The engineers who understand the estate best end up sequencing releases, arbitrating shared-table conflicts, and reviewing changes for blast radius instead of building. This is the most expensive labour in the company doing traffic control. It also concentrates knowledge in fewer heads, which raises the cost of every future option, including the rewrite.
The data model takes hostages. Fields that were temporary five years ago have quietly become load-bearing. Reporting reads from tables that onboarding writes to for unrelated reasons. Every extraction now has to decide which of these accidental couplings to honour and which to break, and there is no version of that decision without risk. Some of those couplings will only reveal themselves in production, whichever path is chosen.
The three honest answers
For a working product with a blocked roadmap, there are three defensible responses. The framework is: leave, strangle, or rewrite. Each has a legitimate use and a specific cost when chosen wrongly.
Leave it alone. Right when the roadmap pressure is temporary or the product is in managed decline: a system being sunset in two years, or a pain that traces to one team's backlog rather than the architecture. The example is the stable back-office estate that everyone complains about and nobody is actually blocked by. Chosen wrongly, this answer converts a sequencing problem into a crisis: the same extraction work gets done later, under outage pressure, with fewer options and less goodwill.
Strangle it. Right when the product still generates revenue, the roadmap is genuinely blocked, and the business cannot tolerate a delivery freeze. New behaviour is built beside the monolith, traffic moves in stages, and the old path remains the fallback until it is a provider of records only. The example is a customer-facing flow that is commercially visible, technically bounded, and talks to the core through a messy but identifiable set of reads and writes. Chosen wrongly, when the domain model itself is obsolete rather than entangled, strangling produces a constellation of services that faithfully reproduce the wrong assumptions, now with network calls between them.
Rewrite it. Right when the honest need is a different product: the licence, market, or domain model has changed so much that the old system's assumptions are not worth carrying. The example is a company whose regulatory category changed and whose core entities no longer describe the business. Chosen wrongly, a rewrite freezes the roadmap for a year, imports the old unspoken assumptions into a new stack, and asks a regulated business to run two production truths at once. Most estates that get rewrites needed extractions.
Two rules make the strangle option work in practice. First, pain is a bad sequencing rule: the first extraction must be one the business can survive if the new path is slower than the old one for a while, which usually rules out the ledger and the oldest jobs in the estate. Second, the real work is the contract, not the service: what the new component must know, what it must never know, and which internal types it is forbidden to import. If the only way to ship a feature is to reach through the wall, the wall is in the wrong place. And a strangler fig that requires a global delivery freeze is just a rewrite with extra steps.
Checklist before the first extraction
- Map the seams that already exist in conversation, before touching code: onboarding, core, partner interfaces, reporting.
- Test every candidate boundary with a survival question: if this capability stopped, could the product still take a payment and remain compliant for a day.
- Choose the first extraction for survivability and commercial visibility, not for pain.
- Write the contract before the service, including the fields the new component must never see.
- Ban imports of the monolith's internal types into anything new, and enforce it in review.
- Move traffic in stages: an internal path, a share of real users, the default, then record-only fallback.
- Keep the existing release train running for everything still inside the monolith, on its own cadence.
None of this requires exotic tooling. It requires treating the first boundary as a business decision with an owner, not a refactoring task.
The same reasoning applies one level up, before any extraction is on the table: whether a capability belongs in your platform at all is covered in When to build vs. when to buy your core platform. If a working product has started to ration its own roadmap and the right first boundary is not obvious, that is the kind of narrow question Spofibo takes on: get in touch.