Introduction
"We should rewrite everything from scratch!", the most expensive sentence in tech.
The reality: your legacy systems generate revenue today. Tearing them down to replace them is risky, slow, and costly. The real question is: how do you modernize progressively without breaking everything?
The real cost of rewrites
Netscape: the cautionary tale, In 2000, Netscape decided to rewrite its browser from scratch. The result:
3 years without competitive new features ; Massive market share loss to IE ; Commercial failure
Lesson: While you're rewriting, your competitors are innovating.
The false promises of the rewrite, Behind every decision to rewrite everything lies a seductive promise that, in practice, collides with a very different reality. "It'll take 6 months" turns into "2 years later..."; "it'll be cleaner" leads to new problems just as complex as the old ones; "it'll be faster" comes with new performance bugs that need to be found and fixed; and "it'll be easier to maintain" simply translates into different complexity, not less. A rewrite doesn't remove the accumulated business complexity, it relocates it.
Modernization strategies
Strangling and hiding legacy
Strategy 1: Strangler Fig Pattern, Progressively strangle the old system by replacing it piece by piece, rather than switching everything at once.
Implementation: the transition unfolds in three phases. You start with a legacy system handling 100% of traffic (phase 1, roughly 6 months), then introduce a router that directs part of the traffic to the new system based on feature flags, for example by customer segment, while legacy continues handling the rest (phase 2, roughly 12 months, with the proportion gradually shifting from legacy to new); finally the new system takes over 100% of traffic (phase 3, roughly 18 months) and legacy can be decommissioned. A simple application-level router that checks a feature flag to decide whether to call the new service or legacy is enough to kick off this gradual switch without a big bang.
Strategy 2: API Facade, Hide legacy behind a modern API. Instead of the frontend calling the legacy database and its stored procedures directly, you insert an API facade (REST or GraphQL) that adapts modern calls to the legacy system. This decouples consumers from legacy without touching the core of the existing system, and paves the way for a gradual replacement behind that facade.
Extracting and syncing
Strategy 3: Extract Microservice, Progressively extract capabilities into microservices.
Prioritization: not every capability is equally worth extracting. A matrix crossing business value against coupling level helps prioritize: capabilities with high business value and low coupling (like authentication/identity or notifications) are quick wins to extract first; those with high value but high coupling (core business logic) need refactoring before extraction, and should be handled carefully; the rest can stay in the monolith for now.
Strategy 4: Change Data Capture (CDC), Sync legacy data to the new system without downtime. The principle: the legacy database (say, Oracle) keeps receiving writes, while a CDC tool like Debezium continuously captures those changes, publishes them to a Kafka stream, then transforms and loads them into the new database (say, PostgreSQL), which ends up replicated in near real time, without interrupting the production system.
Migration patterns
Pattern 1: Dual writes, Write to both systems during the transition. The new system becomes the source of truth: you write to it first, then attempt to also write to legacy to maintain backward compatibility. If the legacy write fails, you simply log the incident as non-critical rather than failing the whole operation, the new system remains the reference.
Pattern 2: Read-repair, Repair data on read. You first attempt a read from the new system; if the data isn't there yet, you fetch it from legacy, then migrate it on the fly to the new system before returning it. Every read that touches not-yet-migrated data thus becomes an opportunity to migrate it, without a dedicated mass-migration operation.
Managing technical debt
Prioritization, an Eisenhower matrix applied to technical debt helps decide what needs handling right away and what can wait. Urgent and important, to handle first: security vulnerabilities and production bugs. Urgent but not important, to delegate or schedule: minor version upgrades, non-critical refactors. Important but not urgent, to plan: architecture refactors, performance issues. Neither important nor urgent, to backlog or drop: perfect code formatting, over-engineering.
To make these trade-offs more objective, it helps to continuously track a few indicators on a dashboard shared with the team: code cyclomatic complexity (to spot functions to refactor first), test coverage, and dependency freshness (outdated or unmaintained libraries). Reviewed regularly, these signals keep technical debt from becoming invisible between sprints.
Data migration
Strategy: Parallel run, the migration unfolds in four phases spread over several weeks. Phase 1, Setup (week 1): the new system is deployed read-only, CDC replicates legacy to the new system, and validation scripts run continuously. Phase 2, Validation (weeks 2-3): results between the two systems are compared continuously, discrepancies are fixed, and confidence in the new system is progressively built. Phase 3, Switch (week 4): writes are enabled on the new system, legacy is kept read-only as a safety net, and everything is closely monitored. Phase 4, Cleanup (week 5 onward): legacy writes are decommissioned, legacy data is archived, and the team can celebrate the switch.
Common mistakes
Wanting to migrate everything at once, in a weekend
"We're migrating everything at once next weekend!" is one of the riskiest sentences in a modernization project: the risk is enormous, rollback is difficult, and stress is maximal for the whole team. The progressive strategies described above exist precisely to avoid this scenario.
Ignoring data mapping
Solution: map meticulously BEFORE migrating. A legacy field like customer.addr1, customer.addr2, or customer.city_zip has no obvious match in the new data model (address.street? address.unit? should city_zip be split?). Without this mapping work done upfront, every ambiguity gets discovered in production, at the worst possible time.
No rollback plan
"If it doesn't work, we'll roll back" isn't enough: you still need to know how. A clear rollback plan, tested before the switch, is just as essential as the migration plan itself.
Conclusion
Legacy modernization isn't glamorous, but it's critical. The organizations that succeed are the ones that:
Are patient: Progressive migration > Big Bang ; Measure: Clear progress metrics ; Automate: Tests, deployments, validation ; Communicate: Transparency with stakeholders ; Learn: Post-mortems, iteration
Your legacy is an asset, not a burden. Treat it with respect while evolving it toward the future.
STAY POSTED
Get our next analyses and field notes straight to your inbox.
