Planning a Drupal Migration: The 90-Day Calendar

The question we get right after “how much does this cost” is always the same: how long will it actually take? Most answers to that question are fiction — a single number pulled from a sales deck, disconnected from the site’s actual size. Ours isn’t a number, it’s a calendar, and we’re publishing the real one.

Ninety days is the realistic middle for a typical mid-market Drupal 7 site: a few dozen content types, some integrations, no exotic multilingual sprawl. We already published the 52-step checklist that covers what happens in each phase. This is the companion piece — when each of those steps actually runs, which ones can overlap, and where the real deadlines are.

Month 1 (Days 1–30) — Discovery & audit

The first month is slower than clients expect, and that’s by design. This is where the actual scope and cost get locked in, before a line of migration code exists. Module inventory, content audit, integration mapping, editor interviews — the first nine steps of the checklist, run in parallel where possible.

The month has one hard deadline: written scope sign-off by day 21. Everything after that date assumes the scope is frozen. Sites that blow past day 21 without sign-off are, without exception, the ones that miss day 90 — not because the work got harder, but because “let’s also migrate the old events calendar nobody’s touched since 2019” turned up in week 6 instead of week 2.

Content-model mapping and taxonomy rationalization start in the back half of the month, overlapping with the audit’s final week. That overlap is the only place in the whole 90 days where discovery and build genuinely share a calendar week — everywhere else, phases are sequential on purpose.

Month 2 (Days 31–60) — Build & migrate

This is where the calendar gets dense. The destination site gets built Composer-managed, migration pipelines get written per content type, and the theme gets rebuilt in Twig — usually the three biggest line items in the budget, running concurrently on separate tracks (backend migration, frontend theme, DevOps/hosting) rather than end to end.

The month’s milestone: a clean rehearsal migration by day 56, run against a full content snapshot with automated diff counts per bundle. If day 56 arrives and the rehearsal still needs manual fixes, that’s the signal to add a week here rather than borrow one from verification later — a rushed Month 3 is where rankings get lost, not a rushed Month 2.

Editors go on the rehearsal copy in the last week of this month. That’s deliberate sequencing: real people doing real editorial tasks catch what automated QA structurally can’t, and doing it here — instead of during launch week — gives you three weeks to fix what they find instead of three hours.

Month 3 (Days 61–90) — Verify & cutover

The last month has no new construction in it — only verification, and then the cutover itself. Every legacy URL gets tested by script against its 301, not sampled. Core Web Vitals get checked on the actual production hosting, not a developer laptop. The security review, form testing, and cron/queue verification all happen here, in roughly that order.

Day 83 is the final rehearsal — a clean run with zero manual intervention, which is the actual definition of “ready.” Day 87 is cutover: content freeze at T−48h, delta sync at T−2h, DNS cut at T−0, with the old site left warm so rollback is always one DNS change away, never a scramble. The remaining three days are the smoke test, the full crawl sweep, and the start of the 30-day ranking watch that continues well past the calendar you’re looking at.

Where 90 days compresses or stretches

Ninety days is the median, not a law. A brochure site with under 20 content types, no custom integrations, and a straightforward theme can realistically close in 45–60 days — Month 1 and Month 2 compress hardest, since there’s less to inventory and less to rebuild. On the other end, a site north of 80 content types, several live integrations (CRM, SSO, payment), and multilingual content routinely runs 120–150 days, almost entirely because Month 2’s build phase expands — more Views to rebuild, more field-type conversions, more integration re-plumbing done properly instead of ported as-is.

The one phase that resists compression regardless of site size is verification. Skipping or shortening Month 3 is the single most common cause of a migration that “finished on time” and then lost rankings in week two — the two events aren’t a coincidence, they’re cause and effect.

Who needs to be free, and when

The calendar above is also a staffing plan, and it’s worth sharing with whoever on your side needs to clear time. Month 1 needs your editors and stakeholders more than your developers — interviews, content decisions, the day-21 sign-off. Month 2 flips that entirely: it’s developer-heavy, with editors reappearing only in the final week for rehearsal-copy testing. Month 3 needs both again, plus whoever owns DNS and hosting for a two-hour window on day 87. The single worst scheduling mistake we see is a stakeholder who blocked time for “the migration” generically and then isn’t reachable on day 21 or day 87 specifically — those two dates are the ones that actually need them.

Use it, steal it, argue with it

Both graphics are free to reuse with attribution and a link. If your own migration ran a different shape — compressed further, stretched longer, phases overlapped where ours don’t — we’d genuinely like to hear where the calendar broke; ours gets revised by what happens in the field, same as the checklist it runs against.

Gspikes is a Drupal development and SEO agency; if you want this calendar built around your specific site instead of a median one, send us the details and we’ll turn it around as part of the free assessment on our Drupal migration page.