Zero-Downtime Migration: The Timeline Your Vendor Won't Show You

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A Series A SaaS or marketplace founder in India whose 3-year-old monolith is throttling growth but whose investors and enterprise clients cannot tolerate even a 2-hour maintenance window during cutover

A realistic zero-downtime migration of a 3-year-old Series A monolith takes five to nine months of elapsed time, not the 8–12 weeks most vendors quote in the first call. The gap is not padding. It is the parallel-run window (typically 8–16 weeks for revenue-critical systems, per parallel-run practitioners), plus 4–6 weeks of founder-level sign-offs that no vendor can shorten from their side, plus the integration access delays that only surface in week three. If you are comparing two proposals and one is dramatically shorter, it is almost certainly hiding one of those three.

This post breaks the elapsed time into the five phases a buyer can actually recognise on a Gantt chart, marks which weeks are blocked on the vendor versus blocked on you, and names the three things that most often add a month nobody planned for.

Why the 8-week promise and the 9-month estimate both exist

Both numbers are real. The 8-week proposals are counting engineering hours for the rewrite of one bounded context — the auth service, say, or the billing ledger. The 9-month proposals are counting from signed SOW to the day the legacy database can be turned off. Neither vendor is lying; they are answering different questions.

The question you actually need answered is: how many weeks until my production traffic runs on the new system and I can fire the old one. That number has five phases, and three of them have a hard dependency on something only you can provide.

Some context on the stakes. Industry analysis of 164 verified monolith-to-microservices migrations between 2022 and 2024 found projects run 6 to 24 months end-to-end. The upper end is usually an enterprise with hundreds of integrations. A Series A SaaS with one monolith, one database and 8–15 integrations lives at the lower end — but only if you plan for the non-engineering weeks.

The five phases, honestly timed

Phase 1: Discovery and dependency mapping (2–4 weeks)

The vendor reads your codebase, maps your integrations, identifies which modules share database tables (the ones that will fight you during extraction), and produces a strangler-fig sequence. If you have decent docs and a tech lead who can sit with them three hours a day, this is two weeks. If your original engineers have left and nobody can explain why the orders table has a nullable legacy_user_id, it is four.

Blocked on you: access to production read replicas, access to monitoring dashboards (New Relic, Datadog, whatever you run), and a single engineer with authority to answer "why does this exist". If any of those three take a week to arrange, the phase slips a week.

Phase 2: Integration access and compliance scoping (3–8 weeks, mostly in parallel with Phase 1)

This is where the published timelines start lying. Every third-party integration — payment gateway, SMS provider, KYC vendor, logistics API — needs either new credentials for the new service, or a webhook reconfiguration, or in the worst case a re-onboarding with a fresh contract. Razorpay or Cashfree will give you new API keys in a day. A bank partner for a lending stack will take six weeks and want a fresh security review.

Compliance scoping sits inside this phase. If you handle payment data, the RBI's 2018 data localisation directive requires end-to-end storage of transaction data exclusively in India, with foreign legs of cross-border transactions deleted and returned within 24 hours. Moving the service from one AWS region to another, or introducing a CDN that caches API responses, is not a decision your vendor can make unilaterally. Someone on your side has to confirm the new architecture does not break the SAR filings you have already made.

DPDP adds a second layer. The DPDP Rules notified in November 2025 introduced phased compliance timelines with penalties up to INR 250 crore per violation. If your migration changes how user consent is stored, logged or revocable, your DPO (or your lawyer, if you don't have one yet — and you should talk to one for this) needs to sign off before any production traffic flips.

Blocked on you: introducing the vendor to your payment partner's integration team, getting your compliance consultant on a call, and — this is the one that bites — finding out your enterprise customer's security questionnaire requires 20 business days to re-process a sub-processor change.

Phase 3: First usable slice in production (4–8 weeks)

One bounded context, fully rewritten, deployed behind a feature flag, taking 1% of traffic. Usually the lowest-risk module — a notification service, a read-heavy catalog API, a report generator. The vendor is doing most of the work here; your team is reviewing PRs and running pre-prod verification.

Four weeks is realistic if the chosen slice is genuinely independent. Eight weeks is what happens when the "independent" module turns out to share a users table with billing, and now you need a read-through adapter to keep both systems consistent.

This is where the 73% failure rate of microservices migrations shows its teeth. The failure mode is not "the code doesn't work" — it is "the new service calls the old monolith 14 times per request and the whole thing is now slower". If your vendor's first slice doesn't publish p95 latency numbers side-by-side with the legacy path, ask why before approving Phase 4.

Phase 4: The parallel run (6–12 weeks, sometimes 16)

This is the single phase vendors systematically under-quote, because it is the phase where nothing looks like it is happening. Both systems run. Writes go to both (dual-write) or writes go to the new system and get replicated back (shadow-write). Reads are compared. Discrepancies are logged, triaged, fixed. Repeat until the error rate is low enough that you trust the new system with 100% of writes.

Published industry guidance puts most enterprise parallel runs between 4 weeks and 3 months, with revenue-critical or compliance-bound systems running 8 to 16 weeks. For a Series A SaaS handling live transactions, 8 weeks is the floor, not the average.

And here is the hidden delay inside the hidden delay. Before dual-write can start, somebody has to approve the dual-write strategy itself — specifically, the decision that for 8–12 weeks your system of record is ambiguous. No senior engineer on the client side will sign that off. It almost always goes to the founder or CTO, and it almost always sits in their inbox for 4–6 weeks while they ask three advisors, two investors and their lawyer whether this is sane. This is the single longest avoidable delay in the entire project.

What you can do in week zero to kill this: write the dual-write RFC yourself, before the vendor starts, and get it approved during discovery. More on this at the end.

Phase 5: Cutover and decommission (2–4 weeks)

Flip reads to the new system. Monitor for a week. Flip writes. Monitor for another week. Turn off the legacy service. Keep the legacy database read-only for 30–60 days as a rollback option. This phase is genuinely short because, if Phase 4 was done right, there is no uncertainty left.

The decommission tail — actually deleting the old database, cancelling the old infrastructure contracts, removing the old service from your SOC 2 scope — adds another 4–8 weeks of calendar time but is not blocking anything.

What this adds up to

For a representative Series A SaaS — one monolith, ~15 integrations, one production database, live transactions but no custody of customer funds, 50 enterprise customers of whom 3 have security questionnaires that gate sub-processor changes — the honest elapsed time looks like this:

That is 5–8 months. Not 8 weeks. Not 9 months. The vendors quoting the extremes are either scoping just Phase 3, or baking in protection for client delays they have seen before and will not describe in writing.

For comparison: Atlassian's Vertigo project moved 100,000+ customer instances of Jira and Confluence to a multi-tenant AWS architecture with no service interruption. The customer migration itself took about ten months. The overall effort took closer to two years. You are not Atlassian, but the ratio of visible-work to invisible-work is similar.

The three things that most often add weeks

1. The dual-write sign-off

Already covered above. Early signal: in week 2, your vendor asks "who approves the cutover strategy?" and you don't have a one-sentence answer. Fix it that week, not in week 14.

2. The security questionnaire from one enterprise customer

You have 50 customers. One of them — usually a BFSI or public-sector client — treats any sub-processor or architecture change as a material change requiring a fresh InfoSec review. Their process is 20–30 business days and cannot be accelerated. Early signal: your MSA with that customer has a clause titled "Change in Processing" or similar. Read it in week 1.

3. An integration partner whose roadmap doesn't match yours

You want to switch your payments integration from REST to webhooks because the new service is event-driven. Your payments partner's webhook product is in beta and the SLA is unacceptable. Now you are either waiting on their roadmap or building a translation layer you didn't scope. Early signal: in Phase 1 discovery, the vendor asks "does your payment partner support async callbacks" and you don't know.

What to do in week zero to shorten the whole thing

Four things, in order of leverage:

1. Write the dual-write RFC before signing the SOW. One page. What the strategy is, what the acceptance criteria for cutover are, who approves. Get founder sign-off during vendor evaluation, not after.
2. Audit your enterprise MSAs for change-notification clauses. Make a list of which customers need N days of notice for a sub-processor or architecture change. Start that clock on day one of the project, not day one of Phase 4.
3. Get your compliance advisor (DPDP, RBI if applicable) on a 60-minute call with the vendor in week 1. Not week 10. The constraints they will surface are usually architectural and are 20x cheaper to accommodate in design than in rework.
4. Insist the vendor's proposal has five phases, not one number. If they will not break it out, they have not planned it. If they will, you now have five smaller conversations instead of one bet.

A sensible scoping conversation for an India-based Series A — whether with us or anyone else — should cover the three specifics that turn the range into a real number: how many integrations are in scope and which ones are compliance-bound, how many of your enterprise customers have change-notification clauses, and whether you have founder bandwidth for sign-offs in weeks 2–4. For teams working through this, our write-ups on legacy modernization and migrating a fintech accounting SaaS cover the architectural side in more detail.

Frequently Asked Questions

How long does a zero-downtime migration actually take for a Series A SaaS in India?

Realistically 5–8 months of elapsed time for a single monolith with ~15 integrations, split across five phases: discovery (2–4 weeks), integration and compliance access (3–8 weeks, mostly parallel), first production slice (4–8 weeks), parallel run (8–16 weeks for revenue-critical systems per published guidance), and cutover (2–4 weeks). The parallel run is the phase vendors most often under-quote.

Why do vendor timeline estimates vary so wildly — 8 weeks to 9 months?

They are answering different questions. An 8-week quote is usually scoping only the engineering work for one bounded context. A 9-month quote is counting from SOW to legacy-database decommission, including compliance reviews and the full parallel-run window. Ask any vendor to break their number into the five phases above; the gap will show which one they are quoting.

Can we really migrate without any maintenance window?

Yes, if you use the strangler-fig pattern with dual-write and a parallel-run period of 8–16 weeks, true zero-downtime cutover is achievable — Atlassian migrated 100,000+ Jira instances this way. The tradeoff is you spend 2–4 months running two systems, paying double infrastructure cost, and triaging data discrepancies. If your SLA permits a 2-hour window, the project is 30–40% shorter and cheaper.

What drives the cost of a zero-downtime migration?

Four variables: number of bounded contexts to extract, number of integrations needing re-onboarding, length of the parallel run (which multiplies infrastructure cost), and compliance scope (RBI payment-data rules, DPDP). Published analysis of 164 real projects puts total cost between $300,000 and $3 million, but that range covers everything from a 3-service extraction to a 40-service enterprise rewrite. To turn that into a real number for your situation you need an integration count, a parallel-run duration target, and a compliance scope — worth a scoping conversation.

What is the single biggest avoidable delay?

Waiting for founder-level sign-off on the dual-write strategy during Phase 4. No senior engineer will approve a change that makes the system-of-record ambiguous for 8+ weeks, so it escalates to the founder or CTO and sits for 4–6 weeks. Write and approve the dual-write RFC during vendor evaluation, before Phase 1 starts, and this delay disappears.

What are the compliance constraints specific to India that affect timeline?

Two main ones. The RBI's 2018 data localisation directive requires payment transaction data stored exclusively in India, which constrains your region and CDN choices. The DPDP Rules notified November 2025 add consent-handling and breach-notification requirements with penalties up to INR 250 crore. A lawyer or compliance consultant — not your vendor — should sign off on whether your new architecture maintains compliance before cutover.