Skip to Content

Migrating Legacy Monoliths with Feature Flags: A Survival Guide

February 14, 2026

You’ve finally acquired enough political capital to attempt the impossible: rewriting the 10-year-old Ruby on Rails monolith into a service-oriented architecture. The board has approved the budget. Engineering is motivated.

Six months later, the project is stalled.

Why? Because rewriting a monolith is like changing the engine of an airplane while it’s flying.

The “Big Bang” Migration Fallacy

The traditional approach to a system rewrite looks like this:

  1. Build the new system (“V2”) in parallel.
  2. Institute a feature freeze on the old system (“V1”).
  3. Wait months while V2 achieves parity.
  4. Flip the DNS switch on a quiet Sunday morning.
  5. Pray.

This “Big Bang” cutover is inherently dangerous. Unseen edge cases, unanticipated load profiles, and subtle data inconsistencies are guaranteed to appear the moment real production traffic hits V2. And when the database state diverges, rolling back to V1 becomes mathematically impossible.

The Strangler Fig Pattern: Powered by Flags

A safer, proven approach is the Strangler Fig Pattern. Instead of rewriting the entire system, you extract one specific function at a time (like the checkout service, or the user profile system) and route traffic to the new microservice.

But how do you route that traffic safely? Feature Flags.

With a platform like GoGreen Flags, a migration looks like this:

  1. Build the new V2 Checkout microservice.
  2. In the V1 Monolith, wrap the code that calls the checkout system in a feature flag: migration-checkout-v2.
  3. If False, the monolith uses its own legacy checkout code.
  4. If True, the monolith acts as a proxy, forwarding the checkout request to the new V2 service.

Phased Rollout and Shadow Traffic

Because this logic is governed by a dynamic flag, you aren’t forced into a Sunday morning cutover. You can control the migration with extreme precision.

  • Targeting: Turn on migration-checkout-v2 only for the QA team.
  • Canary Release: Turn it on for 1% of production users. Watch the error rates.
  • Ramping: Gradually increase the rollout to 10%, 50%, and 100% over the course of a week.

If the edge cases surface at 5% rollout, you simply toggle the switch back to 0%. The blast radius is contained. No emergency meetings. No permanent data corruption.

Feature flags transform the terrifying “Big Bang” migration into a boring, routine engineering exercise. By decoupling the deployment of the new service from the release of its functionality, your teams can modernize your architecture progressively, safely, and predictably.