# How to Plan a Technical Migration Without Shutting Down Your Product
Technical migration planning is one of the highest-stakes engineering activities a startup goes through. Do it wrong and you get weeks of downtime, lost data, or a broken product that erodes user trust. Do it right and you move your entire technical foundation to a better place while users never notice anything happened.
A marketplace startup I worked with needed to migrate from a legacy monolith to a more scalable architecture. They had 40,000 active users and could not afford any meaningful downtime. Their previous CTO's plan was to build the new system in secret for four months, then run a weekend migration that would switch everything over at once. The plan felt clean on a whiteboard.
It was a disaster waiting to happen.
I pushed back, and we redesigned the migration around the strangler fig pattern - a phased approach named after a vine that gradually replaces a tree while keeping the tree standing. By the time we were done, we had moved the entire business logic over in eight phases across six months, with zero downtime and no single risky cutover moment.
That is what platform migration for startups should look like.
Why Big-Bang Migrations Almost Always Fail
The appeal of a single cutover weekend is obvious. You build the new thing, you do one big switch, the old thing is gone, the new thing is running. Clean. Simple.
The problem is that software systems are always more complex than they appear before you try to migrate them.
The data has edge cases you did not account for. That one customer who has been on the platform since 2019 has records in formats that no longer exist. The migration script handles 99.7% of records perfectly and corrupts the other 0.3%. You discover this at 2am Sunday with 400 angry users.
The systems you thought were independent are not. Your new payment processor integration works great in staging. In production, it interacts with a legacy coupon system in a way that was never documented, causing transactions to fail silently.
The rollback is not actually possible. You started the migration at midnight. By 6am, some users have already created new accounts in the new system and others have made transactions in the old system. You cannot cleanly roll back because you now have split state.
These are not hypothetical failure modes. They are the actual failure modes of big-bang migrations, repeated across the industry for decades. The pattern fails reliably enough that the engineering literature has given it a name: the "big bang rewrite" problem.
The Strangler Fig Pattern Explained
The strangler fig is a tree native to tropical forests. Its seeds germinate in the canopy of a host tree, and the vine gradually grows downward, surrounding and eventually replacing the host while the host continues to stand and support it. By the time the host tree dies, the strangler fig has built its own complete structure.
This is exactly how the best technical migrations work.
You build the new system incrementally, routing specific functionality to it piece by piece, while the old system continues to handle everything else. The old system continues to serve real users throughout. The new system handles an increasing percentage of the load. When the new system handles 100% of the load, the old system is decommissioned.
The key requirement for this approach is a routing layer - something that sits in front of both systems and decides which one handles each request. This is often a load balancer, an API gateway, or a small piece of middleware that you add specifically to enable the phased migration.
A Practical Phased Migration Plan
Here is the framework I use for planning technical migrations that do not require taking the product offline:
Phase 1: Audit and prepare. Map every system, every data flow, every integration point in the current architecture. The map will be incomplete, and you will discover gaps during the migration - that is fine. But starting with the most complete picture possible reduces surprises.
Identify the migration order. Not all systems are equal. Some have complex dependencies on everything else. Some are relatively isolated. Start with the isolated systems and work toward the complex, interconnected ones. This lets you build confidence and process before tackling the hardest parts.
Phase 2: Build the routing layer. Before touching a single piece of business logic, build the routing infrastructure that will let you send some traffic to the new system and some to the old system. This is unglamorous work but it is the foundation of the entire approach.
Phase 3: Migrate and run in parallel. For each component you migrate, run both the old and new implementations in parallel for a period before switching fully to the new one. This is called shadow mode or dual-write, depending on the specific pattern. The old system handles the live traffic. The new system handles the same traffic simultaneously. You compare results.
When the new system matches the old system on the same inputs, you have high confidence it is correct. At that point you route live traffic to the new system while keeping the old one available for rollback.
Phase 4: Cut over gradually. Even after validation, do not cut 100% of traffic over at once. Cut over 5%, then 10%, then 25%, then 50%, then 100%. Watch metrics at each step. If something looks wrong, roll back the routing change immediately - a rollback that takes 30 seconds is vastly better than one that takes hours.
Phase 5: Decommission. Once the new system has handled 100% of traffic reliably for a meaningful period - I usually recommend two to four weeks depending on the system's criticality - decommission the old system. Keep the routing infrastructure in place briefly in case you need to restore the old system for an unforeseen issue.
Data Migration Specifically
Database and data migrations are the highest-risk part of any technical migration. Data is harder to recover than code if something goes wrong.
The key principles for safe data migration:
Never migrate destructively. Before any data migration step, you should have a complete backup of the original data that you have tested the restore procedure for. The backup exists, the restore works, you have verified it.
Migrate in batches with validation. Do not migrate all data at once. Migrate in batches - say, 10,000 records at a time - and validate that each batch migrated correctly before proceeding. Build the validation into your migration script, not as an afterthought.
Plan for the delta. While you are running the migration, new data is being created in the old system. Your migration plan needs to account for how the delta - the data created during the migration period - gets moved to the new system. This is often the most complex part of data migration planning.
Keep both systems synchronized during transition. During the period when both systems are running, any write to one system should be replicated to the other. This ensures you can roll back to the old system at any point without data loss.
The Timeline Reality Check
One of the biggest mistakes in migration planning is optimism about timelines.
The audit phase takes twice as long as expected because the system is more complex than anyone remembered.
The routing layer has unexpected complications because legacy systems do not always have clean interfaces.
Shadow mode validation uncovers discrepancies that require debugging sessions no one planned for.
The delta migration turns out to require a real-time sync solution that adds two weeks to the project.
My general rule for startup migrations: take your initial estimate, double it, and that is your realistic timeline. Not because engineers are bad at estimating, but because migration projects have more unknowns than almost any other category of engineering work.
Build that reality into your planning. A migration that takes six months instead of three is not a failure - it is what migrations take when done safely. The failure is a two-day migration that corrupts 2% of your data.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr