How to Modernize Legacy Systems Without Stopping Business

Your core system is 15 years old. It works, but it's held together by duct tape and the knowledge of one person who's retiring next year.

You want to replace it. But you can't stop business for 6 months while you rewrite everything.

This is the real constraint that most software modernization projects ignore. You can't turn off the old system while you build the new one. Too much business depends on it.

The solution: the strangler fig pattern. You gradually strangle the old system by building the new one around it, piece by piece, until eventually the old system dies from disuse.

The Strangler Fig Pattern

A strangler fig is a tree that grows around an old tree, slowly replacing it. Eventually the old tree dies inside, having been completely replaced, but growth was continuous—the fig didn't have to kill the host tree suddenly.

Software modernization works the same way.

Classic (failed) approach:

1. Decide to replace the system (year 0)
2. Plan replacement (6 months)
3. Build replacement (12 months)
4. Test replacement (3 months)
5. Migrate data (2 months)
6. Cut over and pray (1 month)
7. System is now new (18 months later)

Problems:

• 18 months is a long time. You might be out of business, acquired, or irrelevant by then.
• If the cutover fails, you have no fallback.
• You can't learn from real usage in production until month 18.

Strangler fig approach:

1. Identify a small piece of the system to replace (feature, workflow, data type)
2. Build new version alongside the old
3. Route new requests to new version
4. Keep old version as fallback
5. When new version is stable, remove old version for that piece
6. Repeat for next piece

Problems solved:

• You're live with pieces as you go. Feedback comes in weeks, not years.
• If a piece fails, you revert to the old version quickly.
• Each piece is a small, contained risk.
• You learn what works before committing to the whole new system.

Related Context

The strangler approach is a form of digital transformation. Learn more about why transformation requires focus on people, how to measure whether it's working, and how to keep momentum going.

How It Works in Practice

Let's say your system is a monolithic order management application built in 2009.

Orders come in → get processed → stored in database → shipped → customers get invoiced.

Year 1: Strangler Phase 1

Identify the easiest piece: order routing (taking an order and assigning it to a warehouse).

Current state: handled by a subroutine in the monolith. Works, but slow and hard to change.

New state: build a microservice that handles order routing, deployed separately.

How:

1. Build the new order routing service alongside the monolith
2. Deploy an API gateway (acts as a middleman)
3. Route routing requests through the gateway
4. Gateway passes new routing requests to new service, old requests to monolith
5. Log all traffic so you can compare results

Testing:

• New service runs in production but doesn't actually make decisions yet
• You compare: what would the new service decide vs. what did the old system decide?
• If they match 98%+ of the time, you're ready

Cutover:

• Make the new service the primary for new orders
• Keep the old system as fallback
• For 2 weeks, 100% of orders also run through the old system (read-only)
• If anything goes wrong, users don't notice—old system catches it
• After 2 weeks of stability, remove the old routing code from the monolith

Result: Order routing is now in a new service. Monolith is 10% smaller.

Effort: 3-4 months for a small piece.

Year 1-2: Strangler Phase 2

Pick the next piece: order fulfillment (turning an order into shipment).

Repeat the process:

1. Build new fulfillment service
2. Route requests through gateway
3. Compare old vs. new side-by-side
4. Cutover when confident
5. Remove old code from monolith

Result: 20% of the monolith is now new services.

Year 2-3: Strangler Phases 3-5

Continue with: invoice generation, customer notifications, reporting, etc.

Each phase:

• Identify a piece (1-3 months of work)
• Build alongside the old system
• Validate with shadow traffic
• Cutover
• Remove old code

Year 3: The Monolith Is Gone

After 10-15 small strangling phases, the original monolith no longer does anything. It's still there (turned off as a backup), but all traffic is going to the new services.

Total time: 3-4 years (vs. 18 months of classic approach).

But:

• You were live the whole time. No big bang cutover risk.
• You learned what worked before committing everything.
• You could change direction if the market changed.
• When a piece went wrong, the impact was small.

The Key Practices

1. Use a gateway

The gateway is a middleman that decides: does this request go to the old system or the new one?

This is how you control the transition. You can flip traffic with a configuration change, no code changes.

Options: Kong, API Gateway, a custom service. Doesn't matter much.

2. Log and compare

For each piece you're strangling, capture: what did the old system do? What did the new system do?

Compare automatically. If they differ in suspicious ways, alert.

This gives you confidence before you fully transition.

3. Keep the old system running for fallback

For 2-4 weeks after transitioning to a new piece, keep the old code active (read-only).

If the new system has issues, you have instant fallback.

Cost: maintain two versions briefly.

Benefit: near-zero risk on the transition.

4. Make pieces small and independent

Don't try to strangle "the whole checkout process" at once. Strangle "order validation," then "payment processing," then "inventory allocation."

Small pieces mean small risk, faster feedback, faster learning.

5. Measure each transition

Before/after metrics for each piece:

• Did performance improve?
• Did error rate improve?
• Did processing time improve?
• Are users seeing the improvement?

This tells you if your new system is actually better, not just "different."

6. Keep your team small and focused

Don't have half your team building new services and half maintaining the monolith. Instead, have your best people build new services (3-4 people), other people maintain the monolith while you're transitioning.

Once a piece is transitioned, the people who built it move to the next piece.

Realistic Timeline and Cost

A mid-size system ($10M replacement cost, 100K lines of code):

• Years 1-2: Strangle 30-40% of system

  • Cost: $500K-$750K
  • Risk: low (each piece is 2-3 months, small scope)
  • Benefit: learning what works, retiring some of the oldest code

• Years 2-3: Strangle 40-60% of system

  • Cost: $750K-$1M
  • Risk: moderate (interconnections with non-transitioned pieces)
  • Benefit: significant improvements visible to users

• Years 3-4: Strangle final 40% of system

  • Cost: $750K-$1M
  • Risk: moderate (final pieces are often the hardest)
  • Benefit: system is now new

• Total cost: $2M-$2.75M spread over 4 years

• Classic approach: $10M in 18 months (plus massive risk)

Real Example: Insurance Company

A midsize insurance company had a claims processing system from 1995. Monolith, COBOL, one expert who was retiring.

They committed to strangler approach:

Year 1:

• Strangled claims intake (order routing equivalent)
• New system handles 20% of incoming claims
• Cost: $150K
• Risk: low (new claims could revert to old system)

Year 2:

• Strangled claims validation and payment authorization
• New system now handles 40% of claims pipeline
• Cost: $350K
• Benefit: claims processing time dropped from 8 days to 4 days on new pipeline

Year 3:

• Strangled claims adjustment and appeals
• New system handles 75% of claims
• Cost: $400K
• Benefit: accuracy improved, customer satisfaction up

Year 4:

• Strangled reporting and compliance
• Final systems being built (settlement, legacy claims)
• Cost: $350K
• Benefit: 100% of new claims on new system

Total over 4 years: $1.25M

If they'd tried to replace everything at once: estimate was $8-12M over 18 months, plus:

• Massive risk if cutover failed (would have to revert to 30-year-old system with no fallback)
• 18 months of uncertainty
• Business couldn't change direction
• One expert retiring would have killed the project

With strangler approach:

• Phased risk, each piece was small
• Continuous feedback from production
• Business saw improvement incrementally
• Built new expertise gradually (didn't depend on the one expert)

When Not to Use Strangler

Strangler works well for most systems. It doesn't work when:

The system is very small (< 20K lines of code, < 3 months to replace)

• Just replace it all at once. Strangling overhead isn't worth it.

The system has no separate concerns

• Everything is interconnected. You can't strangle one piece without breaking others.
• Classic rewrite is cleaner.

The system is about to be abandoned

• You're replacing it with a vendor solution that handles everything
• Buy and cut over. No need to strangle.

You have the luxury of downtime

• Rare for production systems, but if you can shut down for a week and replace everything, go for it.

For most real production systems serving customers, strangler is the only approach that makes sense.

The Path Forward

If you have a legacy system:

1. Audit it. What's the smallest, most isolated piece you could replace? Start there.

2. Build the infrastructure. Set up your gateway. Set up testing/comparison infrastructure. Plan your cutover procedure.

3. Pick piece one. Something 2-3 months of development, isolated from the rest.

4. Build, validate, transition, learn.

5. Pick piece two. Building on what you learned.

Repeat until the old system is gone.

Yes, it's slower than a big rewrite. But you stay in business the whole time. You learn what works. You minimize risk.

That's worth the extra time.

Start Your Strangler Journey

If you have a legacy system that's holding your business back, the strangler approach can let you modernize without stopping. Let's talk about your specific situation and whether strangling makes sense, or if a different modernization strategy would work better for you.