Legacy Migration: Five Patterns That (Sometimes) Save the Day
- Oshri Cohen
- Jun 18
- 5 min read
If you’ve ever stood in front of a 20-year-old legacy system, a mainframe, a monolith, or just a glorious “ball of mud” and been told, “Make it modern,” you know the feeling. It’s part terror, part hope, and a whole lot of “where do we even start?”
The truth: There’s no silver bullet for legacy modernization. There are only patterns, playbooks, and enough “war stories” to fill a few seasons of late-night tech therapy. Each approach has tradeoffs, pitfalls, and the siren song of an easy way out.
Let’s break down the five most talked-about migration patterns, what makes them work, where they backfire, and why teams (understandably) keep reaching for them. Plus: resources to dig deeper and where Red Corner’s Fractional CTOs can keep your journey on track.
1. Strangler Fig: The Gentle Transition
The Strangler Fig pattern is named after a tree that grows by gradually wrapping around its host, eventually replacing it altogether. In tech, it means building new features and services around the legacy system, slowly intercepting traffic and functionality, until the old system can finally be “retired.”
When to use it:
You need a gradual, low-risk migration.
You can still integrate with or intercept the legacy system’s workflows.
When NOT to use it:
You’re locked out of the legacy codebase.
Any change to the old system is risky, expensive, or politically impossible.
Why it’s so tempting:
The promise of business-as-usual. No “big switch-over” drama. You get to chip away at the old system, celebrate incremental wins, and theoretically avoid massive downtime. Teams love it because you’re not betting the company on a single go-live day.
Related reading:
2. Big Bang Rewrite: The Fresh Start Fantasy
Sometimes, the legacy system is so impenetrable or the migration window so tight that teams consider the nuclear option: rebuild everything, then flip the switch. The Big Bang Rewrite is all about creating a brand-new system and retiring the old one overnight.
When to use it:
The legacy system can’t be modified or is about to disappear (e.g., a hard deadline for mainframe decommissioning).
You need a clean break to shed decades of accumulated tech debt.
There’s a clear, well-understood “spec” (sometimes, the old system itself).
When NOT to use it:
The legacy app is a moving target (lots of changes).
Business rules and integrations aren’t crystal clear.
You don’t have an ironclad buy-in or resources for the marathon ahead.
Why it’s so alluring:
The fantasy of a blank slate, no more weird dependencies or ugly hacks. You get to “do it right this time.” In reality, it’s high risk and often delays delivery, but the appeal of skipping all the incremental pain is hard to resist.
Related reading:
3. Modular Monolith: Organize Before You Modernize
Not every system needs microservices; sometimes you need a codebase that’s not a rat’s nest. The Modular Monolith approach involves reorganizing the existing app into well-defined modules, each responsible for a single domain or function. Only once those boundaries are clear do you even consider breaking them out into separate services.
When to use it:
Your main pain point is spaghetti code, not scale or deployment independence.
You want maintainability and clear ownership, not operational complexity.
When NOT to use it:
Your business requires true decoupling for scale, resilience, or independent team velocity.
Different teams need to move independently and deploy on their own schedules.
Why it’s tempting:
You get much of the clarity and order of microservices, but without the overhead of distributed systems. “Let’s just organize first,” feels safer, and often delivers quick wins for developer happiness and onboarding.
Related reading:
4. Domain-Driven Design: Business-First Architecture
Domain-Driven Design (DDD) is about organizing your codebase around real business concepts, known as “domains,” rather than just technical layers. DDD encourages deep collaboration with business stakeholders, clear boundaries (referred to as “bounded contexts”), and mapping the software to actual workflows.
When to use it:
Your business domains are well-understood and relatively stable.
You want your software to reflect how your business operates, not just the latest tech best practices.
When NOT to use it:
Business domains are fuzzy, constantly shifting, or there’s no appetite for business/tech collaboration.
You need a quick fix, not a strategic realignment.
Why it’s so alluring:
DDD promises lasting clarity, “business/tech alignment,” and an end to the age-old “requirements lost in translation” problem. For many CTOs, it’s the dream: order from chaos. The catch? It only works when the business is genuinely engaged and willing to define what matters most.
Related reading:
5. Golden Master Testing: Trust, But Verify
Golden Master Testing involves running both the legacy and new systems in parallel, comparing outputs to ensure the new system faithfully reproduces the old where it counts. This is especially useful when documentation is lacking and “the old system’s behaviour” is the business spec.
When to use it:
You need to guarantee that complex, undocumented behaviours are preserved during migration.
You can duplicate production traffic or data through both systems for comparison.
When NOT to use it:
It’s impossible to duplicate real usage or compare outputs due to external dependencies or unpredictable side effects.
There’s too much variability in how results are generated or presented.
Why it’s tempting:
Golden Master takes the guesswork out of migration. “If the outputs match, we’re safe!” It gives stakeholders confidence, don’t forget the sneaky edge cases that only show up once a decade.
Related reading:
How a Fractional CTO Makes This Actually Work
Why do so many migration projects stall or fail? It’s rarely a technical reason. It’s about vision, alignment, and ruthless prioritization. A Fractional CTO—like the ones at Red Corner doesn’t just bring patterns and best practices. They bring real-world roadmaps, identify anti-patterns before they occur, and align business and technical teams so that migration progresses with purpose.
Fractional CTOs:
Map out the journey, balancing risk and reward for your specific context.
Keep “we’ll figure it out” from becoming “nobody knows what’s happening.”
Stop the march toward distributed monoliths, scope creep, and endless “analysis paralysis.”
Help you decide what to kill, what to keep, and what to completely reimagine.
Bottom line: There’s no universal answer—but with the right pattern, some hard-won wisdom, and real technical leadership in your corner, your migration doesn’t have to become another war story.
Want to learn more or swap legacy migration tales? Drop a comment or reach out to Red Corner.
More to explore:
Comments