When to Migrate vs Rewrite From Scratch a Decision Framework

The decision between migrating an existing system and rewriting it from scratch comes down to four questions: how much business value depends on the existing system continuing to work during the transition, how well-understood are the existing system's behaviors, how different is the target architecture from the current one, and how much engineering capacity do you have to commit. Migration almost always wins for systems with high business value or unclear behaviors; rewrite wins for systems that are small, well-understood, and being moved to a fundamentally different architecture. Most teams in 2026 default to "rewrite" because AI tools make rewriting feel cheap, then discover that the cost of redoing the implicit knowledge embedded in the old system is much higher than they expected.

This piece walks through the four questions, the patterns that lower risk for each path, the warning signs that you picked the wrong one, and the famous Joel Spolsky essay that remains the best single guide to this decision.

Why This Decision Is Underrated

The rewrite vs migrate decision is often made too quickly, often by reflex rather than analysis. AI tools make rewriting feel attractive because the new system can be built faster than ever. What this framing misses is that the implicit knowledge embedded in the existing system (the bug fixes, the customer-specific edge cases, the workarounds for downstream services) was built up over years and is not in the documentation. Rewriting throws all of that away and forces you to rediscover it the hard way.

Migration preserves the implicit knowledge because the existing code keeps running while you transition. Rewrite assumes the implicit knowledge can be reconstructed from observation, which is true for some systems and dangerously wrong for others. The decision is about which assumption is true for your specific system.

The pattern to copy is the way Joel Spolsky framed this decision in 2000 in his "Things You Should Never Do, Part I" essay. His thesis was that rewriting working software from scratch is "the single worst strategic mistake that any software company can make." The thesis still holds in 2026, with the modification that AI tools change the cost calculus slightly (rewrites are somewhat cheaper) but do not change the fundamental risk (you lose accumulated knowledge).

The Four Questions That Decide

Each question maps to a specific risk dimension. Answer all four honestly before deciding.

Question 1, business value during transition. Is the existing system generating revenue, serving customers, or providing critical infrastructure right now? If yes, migration is almost always right because rewrite means parallel work for months while the old system needs maintenance.

Question 2, behavior understanding. Do you fully understand what the existing system does in every edge case, or are there behaviors that "just work" for reasons nobody remembers? If the latter, migration preserves the unknown behaviors; rewrite forces you to rediscover them, often during outages.

Question 3, architecture difference. Is the target architecture fundamentally different from the current one (monolith to microservices, server-rendered to JAMstack, relational to event-sourced)? Big differences favor rewrite because migration would require building so much adapter code that you might as well rewrite.

Question 4, engineering capacity. Do you have the engineering capacity to maintain the old system while building the new one? Rewrites require parallel work for the duration of the rebuild. Without enough capacity, the old system rots while the new one is being built.

The Patterns That Lower Risk for Migration

If you choose migration, three patterns reduce the risk and time significantly.

Strangler fig pattern. Build the new system around the edges of the old one, intercepting traffic and routing increasing percentages to the new code over time. Old code keeps running until it has no traffic; then you delete it. Lowest-risk pattern by far.

Database first or last, never together. Either migrate the database first (and have the app talk to the new database from the old code) or last (and have the new code keep talking to the old database). Migrating both at once is the most common cause of failed migrations.

Feature flag everything. Wrap every changed code path in a feature flag during migration. Lets you roll back individual changes without rolling back the whole migration. Adds maybe 5 percent to development time and prevents a substantial percentage of migration disasters.

The Patterns That Lower Risk for Rewrite

If you do choose rewrite, three patterns make the rewrite less likely to fail.

Parallel development with feature parity. Build the new system to match the old one's behavior exactly before adding any new features. Resist the temptation to "fix everything we hated" in the rewrite; that path leads to scope explosion.

Data export/import bridge. Build tools that keep data synced between old and new systems during the rewrite period. Lets you do a clean cutover when the new system is ready instead of a panicked one-shot migration.

User migration in cohorts. Move 10 percent of users to the new system, see what breaks, fix it, move 50 percent, see what breaks, fix it, then 100 percent. Catches issues at low impact before they affect everyone.

The other mistake is committing to one path and refusing to switch when the data shows it is wrong. If you started a rewrite and after 3 months you have a 30 percent done version of the new system and the team is exhausted, that is a strong signal to switch to migration of the old system. Sunk cost is real but should not drive decisions.

A useful checkpoint is to review the migration or rewrite project at the 30 percent mark (by elapsed time) and honestly assess: are we still on track, is morale holding, are we discovering more complexity than expected. If three of those answers are concerning, consider switching paths even if it feels like giving up. The data on rewrite abandonment is consistent: most failed rewrites had warning signs at the 30 percent mark that were ignored.

What This Means For You

The migrate vs rewrite decision is one of the highest-leverage technical decisions any team makes, and it is consistently made too quickly. The four-question framework above takes 30 minutes to apply and prevents months of wasted work.

• If you're a founder: Default to migration unless you have explicit, defensible reasons to rewrite. The data on rewrite abandonment rates is sobering.
• If you're changing careers: Reading old systems is an undervalued skill. Engineers who can preserve implicit knowledge during transitions are paid premiums.
• If you're a student: Read Joel Spolsky's "Things You Should Never Do" essay. It is 25 years old and still the best short guide to this decision.