Migration fear delays more signatures than price does. We see it in almost every pre-sales call: the buyer wants the new system, then someone asks how the team is supposed to sell while the data moves, and the project goes back to committee for six months. The caution is understandable. A frozen CRM is a sales team that records nothing: follow-ups stop and orders end up on sticky notes. Divide your annual revenue by 250 working days and you have what one day of downtime costs on average, before counting what never gets re-entered.
The real question behind the hesitation is whether legacy data migration without downtime exists anywhere outside sales brochures. It does. It is a three-step method, documented publicly by Stripe's engineering team, and one we have run in production: on a CRM migration for a real estate group, and on data moves inside the airport parking booking platform we operate. The old system stays in production from the first day to the last. The new one works in the shadows until it has proven it is ready.
Here is the playbook, its limits, and what it should change in your quote.
Why big bang cutovers fail: the irreversibility problem
The big bang has a seductive logic: shut the old system down on Friday night, migrate over the weekend, go live on Monday morning. The flaw shows up Monday at 9:02. From the first record typed into the new system, the two databases diverge. Find a serious defect on Tuesday and you have two options: roll back and lose two days of data entry, or merge two databases by hand. Nobody picks either. The team patches the new system live, under pressure, with the business running on top of it.
The real problem with a big bang is not that it can fail. It is that it cannot be undone. Everything that follows is built for one property: at every step, you can go back without losing anything.
Legacy data migration without downtime, in three steps
Three steps, in this order. Never the reverse.
Step 1: dual write, the new system shadows the old one
We start by wiring up dual writes: every create and every update in the old system is replayed into the new one, silently. Nobody reads from the new system yet. It absorbs real production traffic and the ugly edge cases with not a single user depending on it. Your sales team notices nothing, which is the point. If the new system falls over during this phase, nothing happens: the old one is still the only source of truth. We leave the shadow running long enough to see a full business cycle pass through it, a month-end close or a booking peak.
Step 2: backfill and verification, proving the copies match
Dual writes only cover data that moves. The years of history behind it are copied by the backfill, batch by batch, while the dual writes keep running. Then comes the part everyone underestimates: reconciliation. We compare the two databases record by record, count the mismatches, fix the scripts, replay. The target is zero unexplained differences. Not roughly zero: zero, or a written explanation for every difference that remains. On the real estate group's CRM migration, reconciliation ate more days than anything else: duplicates and dates stored in free-text fields, the ordinary sediment of a ten-year-old database. Until the mismatch report is clean, nobody cuts over.
You do not trust a copy on its word. You trust a mismatch report that reads zero.
Step 3: the cutover, a rollback lever, and someone holding it
Prepared this way, the cutover is an anticlimax: we flip the direction of reads. Users now read from the new system while the old one keeps receiving mirrored writes. That mirror is the rollback lever: as long as it runs, going back to the old system takes minutes and loses nothing. The question that matters is who holds the lever. We write the answer down before the cutover: a named engineer, rollback criteria decided in cold blood (which error rate triggers it, and within what delay), and someone on the client side who knows they can call the rollback without arguing for it. A lever nobody dares to pull protects nothing.
The mirror only goes dark after a full cycle without incident. That day, the migration is over.
When a maintenance window is honestly cheaper
The method has a price. Dual writes are code you write, test, and later remove. If your business stops on weekends, if the users are internal, if the volumes are modest, a Saturday maintenance window does the same job for far less.
Let us price both paths at our public day rates. Zero downtime on a mid-size CRM: 5 dual-write days at 300 EUR, 10 backfill and reconciliation days at 300 EUR, 4 cutover and parallel-run days at 450 EUR. Total: 6,300 EUR. The same scope through a maintenance window fits in 8 days at 300 EUR, so 2,400 EUR, plus one weekend offline. If a weekend offline costs you nothing, the decision is already made. We recommend the zero-downtime path when the business runs seven days a week, or when the team's trust would not survive a broken Monday. Not on principle.
Migration risk in your quote
A vendor who has run this playbook has no reason to hide it. In a serious quote, migration risk takes up visible lines:
- dual-write days, including the removal of the code afterwards
- reconciliation days, with a numeric exit criterion: zero unexplained differences
- cutover days, parallel run included
- the name of the person holding the rollback lever
When data migration is a single line that says included, the risk has not disappeared. It has moved to your side of the table.
Those lines appear in our quotations at public day rates of 150 to 450 EUR. On a larger scope they become a dedicated pod at 15,000 to 40,000 EUR per month. Our hybrid model, steering, quality and contracts in Belgium with an engineering center in Rabat, is what holds those rates without cutting the reconciliation short.
Across our 17+ shipped projects, we have run these three steps far more often than we have accepted a big bang, and no client has ever regretted paying for the mismatch report. To find out what this path costs on your own system, describe it at jadev-corp.com/quote. An engineer reviews every request, the formal quotation arrives within one business day, and the earliest a project can start is two weeks after the request.