How to Migrate a Legacy System Without Breaking Production

This is a submission for the Google Cloud NEXT Writing Challenge

How do you change an entire production system… without a single minute of downtime? 🤔

There’s a common mistake many teams fall into:

“Let’s throw away the old system and rewrite everything from scratch.”

That’s the classic Big Bang Rewrite.

And the usual result?

🔥 Delays

🔥 Bugs

🔥 Production issues

🔥 And in the end… crawling back to the old system 😅

💡 The smarter approach: Strangler Fig Pattern

The idea is simple:

Instead of killing the old system all at once…

you slowly “strangle” it until it disappears completely 👀

🧠 How does it work?

1- Keep the legacy system running as usual

2- Start building new parts feature by feature

3- Put a proxy / routing layer in front of the system

4- Route some requests to the new system

5- Keep the rest going to the old one

6- Repeat until the legacy system is fully gone

🎯 Practical example:

/products → still handled by Legacy Laravel

/checkout → handled by Next.js (the new system)

The proxy is what decides where each request goes.

👍 Why is this smarter?

Lower risk

You can deploy while still developing

Rollback is easier

The team keeps moving without stopping the business

⚠️ But here’s the catch:

If you don’t have discipline,

you may end up with:

❌ A broken old system

❌ And a new system that still isn’t ready

= a double disaster 😅

🧨 The most important rule:

Every migrated part must be:

✔️ Isolated

✔️ Clear

✔️ Owned by someone

And most importantly:

👉 Kill the old system fast. Don’t let it live forever.

🧭 Final takeaway:

Strangler Fig Pattern = migrating a legacy system gradually using a routing layer until the old system is fully replaced.

If you’re working with a monolith and thinking about moving to microservices — or even just rewriting your frontend — this is often the smartest strategic move you can make.