Website Migration Timeline: How Long 29 Real Drupal Migrations Took

Ask an agency how long a website migration takes and you will hear “it depends”, which is true and useless. We wanted a number, so we went to the one public archive where agencies describe finished Drupal projects in their own words: the case study section of drupal.org.

On 14 October 2026 it held 462 case studies, published between January 2024 and October 2026. 294 of them mention a migration, an upgrade, a rebuild or a legacy platform. Only 29 say when the project started and when the new site went live. Those 29 projects are the dataset behind this article, and every one is listed with its source at the end.

How we counted

A case study made it into the dataset only if the project replaced an existing website, platform or set of sites, and the text gave a start and a launch, or a duration that clearly covered the whole delivery. “Kickoff” means the start of the engagement as the case study describes it: mobilisation, a kickoff meeting or the first discovery workshop. “Launch” means the first public release, including a public beta after which the old site was switched off. Durations given in weeks were converted at 4.33 weeks to the month.

We left out brand-new sites with nothing to migrate, such as a new public inquiry, a new state agency or a new energy brand. We also left out add-ons to an existing platform, durations that described a single phase (a nine-week training programme, six months of content review), and phrases like “multi-year” or “multi-quarter” that come without a number.

Each project got one of three scope labels. A quick relaunch is a small site or a deliberately cut first release. An organisation website is one organisation’s main site, sometimes with its intranet. A platform is a multi-site or multi-brand estate, or anything over 50,000 pages.

Two caveats matter. Case studies are written by the agencies that did the work, about projects they are proud of, so read these numbers as how long successful migrations take. That is the useful comparison when you are planning one. And one UK agency, Big Blue Door, published 13 of the 29; their median is 7.5 months, exactly the same as the other 16 projects, so they do not move the headline.

The answer: about seven and a half months

Half of the 29 projects launched within 7.5 months of starting, and the middle half took between 4 and 10 months. The fastest took four weeks; the two slowest took 18 months each. Almost three in four (21 of 29) landed between four months and a year.

That range lines up with what we see in quotes. Our Drupal migration cost guide puts large institutional migrations at five to nine months, which is almost exactly the middle half of the organisation websites here. The spread around the median is the more useful part of the answer, though, because it is not random. It follows scope.

Scope sets the clock, not the platform you leave

Quick relaunches took weeks. The Global Carbon Pricing Challenge moved from Squarespace to Drupal CMS on a site template in four weeks. DamFailures.org went from WordPress to Drupal CMS in six. Australia’s Climate Change Authority had its GovCMS site rebuilt and live in four weeks, ahead of the end of the financial year. Brightly, a Siemens company, folded several acquired product sites into one rebranded site in 12 weeks, and Jan De Nul replaced a custom careers site without a CMS in three months. What these five share is one site, a scope frozen before work began and, in the fastest case, a ready-made Drupal CMS site template.

Organisation websites took most of a year. The 17 projects in this group had a median of 7.5 months, with the middle half between 5 and 9. Manchester Central went from Drupal 7 to Drupal 9 in 4.7 months; People First moved off Umbraco in four; Worcestershire County Council left Jadu after eleven; Australia’s Department of Social Services replaced a ten-year-old Drupal 7 site in eleven; the Diocese in Europe took twelve. Not one of the 17 launched in under four months.

Platforms took a year or more. ONERA moved 55+ Drupal 7 intranet sites into a Drupal 10 site factory in about ten months. GovCMS upgraded 300+ government sites from Drupal 9 to 10 over ten months, and that was an automated upgrade, not a rebuild. Universität Siegen migrated 100,000+ pages from XIMS in twelve months. Luiss University cut 65,000 pages down to about 25,000 in a fifteen-month programme. Bayer Consumer Health moved 437 sites in eighteen months, reaching a pace of up to 100 sites a month only once the core platform existed. The City of Potsdam migrated its family of sites one by one over about a year and a half.

The platform being left behind barely shows up in the data. Where a case study names it, it ranges from Squarespace to Jadu to Drupal 7, and the spread inside each scope band is far wider than any difference between platforms. Only four single sites came from an older Drupal, which is too few to compare; they took between four weeks and eleven months.

Deadlines make migrations smaller, not faster

Eight of the 29 projects named a hard date: a 160th anniversary, a venue reopening after the pandemic, an NHS trust merger, a rebrand, the end of a financial year. Those eight finished in a median of 2.9 months, against 8 months for the rest. It is tempting to read that as “deadlines speed things up”.

The data says otherwise. Five of the eight deadline projects were small relaunches, which are fast anyway. Compare like with like and the effect disappears: organisation websites with a fixed date took 7 months, those without took 7.5. The date did not compress the same work. It changed what went into the first release. Bristol NHS Foundation Trust launched on the day the new trust was formed with the essential information, and kept migrating content from its predecessor sites in phases after launch. That is the honest way to meet a date.

If your migration has a fixed date, decide what the first release leaves out before anything else, and put the second release on the plan from day one.

Building is the short part

Where case studies break the timeline down, the build is the shorter piece. The Autism Education Trust’s seven-month programme spent five months on discovery and iterative design and two on the technical build. The Church of England Pensions Board site, which is not in the dataset because the start of planning is not dated, had a main build of about four months, after planning and scoping. TelefonSeelsorge in Germany, also outside the dataset, spent three months on interviews, workshops and technical audits before a line of code was written.

That is how the numbers here square with our own 90-day migration calendar. The 90 days are the delivery window once the decisions are made: the content model, what comes across, what gets dropped and where the dropped URLs redirect. The case studies count from kickoff, and the decisions take as long as the build or longer. Much of that time is content triage, which is why we wrote separately about cleaning a decade of database cruft before you migrate, and why the migration checklist spends its first phases on inventory, not code.

Almost nobody publishes the number

The quietest finding is the one in the denominator. Of 294 case studies that mention a migration, an upgrade, a rebuild or a legacy platform, 265 give no usable start-to-launch duration. Agencies publish traffic gains, Lighthouse scores and editor satisfaction; they rarely publish the calendar.

That makes the timeline in a proposal hard to check. When you choose an agency, ask for the start and launch dates of its last three comparable migrations. A dated list is better evidence than an estimate, and an agency that cannot produce one is telling you something.

How to estimate your own migration

• Small site, fixed scope, little custom code: one to three months. The fastest projects in the data all had a frozen scope, and the four-week Squarespace move used a ready-made Drupal CMS site template.
• One organisation’s main website: plan six to nine months from kickoff. Nobody in the data did it in under four.
• Many sites or 50,000+ pages: plan a year and migrate in waves. Build the shared platform first, then move sites in batches, as Bayer and Potsdam did.
• Count discovery separately: if a proposal shows only build weeks, ask where the content decisions happen.
• Put the URL work inside the timeline: every page you drop needs a redirect before launch, not after. Our website migration SEO guide covers the repair side, and Migrate Redirect Map, the module we published on drupal.org, builds the redirect map from the migration itself.
• If there is a hard date: choose the scope of the first release first, then plan the second.

If you want a dated plan for your own site rather than a range, send us the site. We come back with your site placed in one of the scope bands above, a dated plan and a fixed price for the Drupal migration that follows. If you are still on Drupal 7, the State of Drupal 7 census shows how many sites are in the same queue.

The dataset

All 29 projects, shortest first. Months run from kickoff to first public launch, as stated in each case study; follow the link for the source text.

Method: all 462 case studies listed at drupal.org/case-studies were collected on 14 October 2026. Projects were included when they replaced an existing site and stated a start and launch or a whole-project duration. Coding and scope labels by Gspikes. Spotted an error or published a dated migration case study we missed? Tell us and we will add it in the next update.