A Drupal to Drupal migration typically takes days for a small, simple site and weeks to months for a larger, complex site. Most business sites with custom content types, forms, and integrations land in the middle, around several weeks of focused work.
A Drupal to Drupal migration moves articles, pages, users, files, and settings from an older Drupal version to a newer one. Timeline depends less on page count than on structure, custom code, and how much must be rebuilt. Theme rebuilds, missing modules, multilingual content, and commerce rules add the most time.
Table of Contents
- What does the move actually involve?
- What stretches the timeline?
- How long for simple, mid-size, and complex sites?
- How can you keep the project on schedule?
What does the move actually involve?
Drupal major versions often require a fresh site build rather than an in-place click to update. The team prepares a clean target site, then migrates content and configuration into it. That separation keeps the live site running while builders test safely. Migrated material usually includes content nodes, taxonomy terms, users, files, images, menus, and URL aliases.
Site builders map old fields to new fields and check formatting, authors, dates, and permissions. Media and documents need path checks so links and embeds keep working. Much else is rebuilt rather than moved. Themes, page layouts, views, search settings, forms, and custom logic usually need new versions. Contributed modules may have changed or disappeared, so replacements must be selected and configured.
What stretches the timeline?
Custom data structures add review and testing. Paragraphs, custom entities, revisions, workflows, and access rules each need mapping decisions. Multilingual sites, user groups, memberships, and order histories add further checks. Integrations often drive delay.
CRM links, email tools, payment gateways, single sign-on, analytics events, and marketing tags must be reconnected and tested. Redirects and metadata need care so search visibility and ads keep pointing to correct pages. Content quality matters too. Duplicate pages, unused types, old files, and inconsistent tags slow field mapping. A short cleanup before migration prevents repeated fixes during test imports.
How long for simple, mid-size, and complex sites?
Size alone does not set duration, but common patterns help planning. Use these as starting points, then adjust for custom code and integrations.
A content freeze shortens every pattern. If editors keep changing the live site during migration, the team must rerun imports and recheck differences.
- Small brochure site: few content types, standard modules, new theme from a starter. Active migration work often takes days to two weeks.
- Mid-size business or publication site: blogs, forms, search, redirects, some custom views. Work often takes several weeks including testing.
- Large or complex site: commerce, multilingual content, memberships, custom modules, system integrations. Work often takes several months across audit, build, migration, and QA.
How can you keep the project on schedule?
Start with a full audit of modules, themes, content types, users, files, and integrations. List what stays, what goes, and what must be rebuilt. Decide URL handling, redirect rules, and SEO checks early.
- Inventory content types, fields, users, roles, files, and redirects.
- Match each old module to a current module or replacement.
- Run a trial migration and fix mapping errors before design polish.
- Rebuild the theme with accessible, responsive templates.
- Test logins, forms, search, checkout, and editors with real content.
