Should You Strangle Your Monolith or Rewrite It From Scratch?

You’ve decided to modernize. Now comes the crucial decision: do you gradually replace your monolith using the strangler fig pattern, where you build new services alongside the legacy system, or do you bite the bullet and rewrite the whole thing?

Everyone has opinions. Your architect wants to strangle because it’s lower risk. Your engineering lead wants to rewrite because the legacy system is a nightmare. Your CFO wants the fastest timeline because they hate seeing modernization drag on.

They’re all making reasonable arguments based on incomplete information. Here’s how to actually think about this decision.

The Strangler Fig Pattern — When It Works

The strangler fig metaphor comes from nature: a fig vine grows around a host tree, gradually replacing it until the host tree dies and the fig stands alone. Applied to software, you build new services that intercept and replace functionality from the legacy monolith, one piece at a time.

The appeal is obvious: you’re never in a state where the entire system is down. You’re running both systems, so if something goes wrong with the new service, you route traffic back to the old one. You reduce deployment risk dramatically.

This works exceptionally well when:

Your monolith is modular enough to extract clean service boundaries. You can identify a service—payment processing, user authentication, inventory management—that can be extracted without taking half the monolith with it. You build the new service, route traffic to it, and the old code stays intact as a fallback. One ecommerce company we worked with successfully strangled a payment processing service out of their Python monolith in 4 months because payment was functionally isolated. Low risk, clear boundaries, measurable progress.

You have clear user-facing features you can release independently. You’re not trying to extract the foundations of your system. You’re building new features alongside the legacy system, and new features naturally live in new services. A SaaS company built a new analytics engine as a separate service while their legacy monolith handled core application logic. No strangling required—just new capabilities living alongside old ones.

You have time and your market isn’t moving aggressively. The strangler pattern assumes you can run two systems in parallel for 2-4 years. If your market is accelerating and you need to fundamentally change how you operate, you might not have that much time. But if you’re growing steadily and can afford to move deliberately, strangling is less risky.

Your operational burden is manageable. Running both systems means double the operational complexity. You have two databases, two deployment pipelines, two monitoring strategies, and two sets of potential failures. If your ops team is already stretched, strangling makes their job harder for 2+ years.

The strangler fig pattern gives you: lower deployment risk, the ability to run old and new systems in parallel, clear rollback options, and time to learn. It also gives you complexity, longer timelines, and the challenge of keeping two systems in sync.

The Complete Rewrite — When It Actually Makes Sense

A complete rewrite sounds reckless. Build the entire system from scratch, flip the switch on a Friday, and pray it works. That’s not what we’re actually discussing.

A complete rewrite, done properly, means: design your new system, build it against production data and production workloads in parallel with your legacy system, validate it thoroughly, then switch. You’re still running both systems during the transition. The difference is you’re not trying to keep them in sync for years.

This approach makes sense when:

Your monolith is so entangled that extracting services is harder than rebuilding. You have service boundaries that existed on the drawing board but don’t exist in the code. Everything calls everything else. A function that started as “retrieve user” now does authentication, authorization, profile enrichment, audit logging, and five other things. Extracting a clean payment service would require refactoring half the monolith anyway. If that’s your situation, you’re not really strangling—you’re refactoring while maintaining the old system. Just rewrite instead.

You need to change architectural foundations. Your monolith is synchronous, but you need an asynchronous event-driven system. It’s single-tenant, but you need multi-tenancy. It’s on-premises, but you need cloud-native. These architectural changes are structural. The strangler pattern doesn’t help because you’re not just replacing services—you’re fundamentally changing how the system works. Rewriting lets you build the foundation correctly from day one.

You want to change technology stacks intentionally. Your monolith is a tangle of Java, Python, and Perl because it accumulated code over 15 years. You want to standardize on TypeScript and a modern architecture. Strangling means you’re building services in TypeScript while supporting the legacy Perl code. That’s more operational burden. Rewriting lets you make a clean break and build everything in your target stack.

Your timeline is constrained. Strangling a large monolith takes 18-36 months. If your market window is 12 months—you need new capabilities or you lose market share—strangling is too slow. A complete rewrite with parallel validation takes 12-16 months. That’s a meaningful difference when timing matters.

Your team is fresh and ready for it. A rewrite is emotionally and intellectually demanding. Your team needs to maintain the legacy system while designing the new one, which means they’re splitting context. If your team is burned out from maintaining legacy code, they probably aren’t in the right mindset to design a new system well. But if you have senior architects who are energized by the challenge and willing to take the risk, a rewrite might actually lower total risk because you get better design.

The rewrite approach gives you: clarity, speed, the ability to make architectural changes, and a definitive endpoint. It also gives you deployment risk (the switch is bigger), compressed timeline pressure, and the challenge of validating a complete system before going live.

The Real Decision Framework

Here’s how to actually decide:

Map your monolith’s actual structure. Don’t go by the architecture diagram. Run dependency analysis. Understand which services are truly separated and which are tangled. If you find that 70% of your monolith is cleanly separable, strangling is viable. If it’s 30%, you’re fooling yourself about the strangler pattern benefits.

Assess your market timing. How much time do you have? If you have 24+ months, strangling is reasonable. If you have 12 months, rewriting is faster. If you have less than 12 months, you might need to do neither—instead focus on targeted refactoring of critical paths.

Evaluate your team’s bandwidth. Strangling requires sustained engineering effort over 2-3 years. Can your senior architects sustain that while also keeping the legacy system alive? Or would they be more effective with a bounded 14-month rewrite effort? Be honest about team capacity.

Calculate the operational burden. How complex is running two systems? If they share databases, you’re really running one database and two application layers. If they need to sync state, you’re building synchronization logic. If they’re completely separate, you’re doubling operational complexity. What’s the real cost?

Consider your risk tolerance. Strangling is lower-risk but longer. Rewriting is higher-risk but faster. If a deployment failure would devastate your business, strangling is safer. If you can tolerate a brief window of elevated risk in exchange for moving faster, rewriting is better.

Model the total cost. Include engineering, infrastructure, operations, and opportunity cost. Usually the difference is smaller than you’d expect: strangling might cost $2.8M over 32 months, while rewriting costs $2.5M over 16 months. The per-month burn is higher for rewriting, but the total is sometimes similar.

The Pattern We’re Seeing Work

Most successful modernizations we see aren’t pure strangling or pure rewriting. They’re hybrid:

Extract your critical path first. Identify the highest-value services that slow you down most—API layer, authentication, core business logic. Strangle those first because they’re worth the effort. (4-6 months)

Build your new infrastructure and patterns in parallel. Don’t wait for strangling to finish. Start building the new system’s foundation while you’re extracting services. (running in parallel, 4-8 months)

Rewrite non-critical services. Everything else—internal tools, batch processing, legacy reporting—rewrite cleanly without the strangler overhead. (4-6 months)

Flip over when you’re ready. You’ve built enough new services that the old monolith is mostly hollow. You’ve validated your new system under production load. You switch, retire the legacy code, and move on.

This hybrid approach takes 14-18 months, reduces risk by validating against production load, and avoids the coordination overhead of full strangling.

The Real Question You Should Ask

Don’t ask “should we strangle or rewrite?” Ask: “what’s the fastest way to move our engineering team from maintaining legacy code to building new capabilities?”

Strangling gets you there in 32 months but with complexity. Rewriting gets you there in 16 months but with risk. A hybrid approach gets you there in 18 months with manageable risk.

The answer depends on your specific situation, your team’s capabilities, and your market’s timeline. But the decision shouldn’t be made based on fear or preference—it should be made based on the actual structure of your system, the realistic timeline for your business, and an honest assessment of what your team can execute.

Everything else is just guessing.