Drupal 6 to Drupal 11 migration

Drupal 6 to Drupal 11 migration: what the move involves

A Drupal 6 site cannot be updated in place to current Drupal, so the move means building a new Drupal 11 site and migrating into it. The core Migrate, Migrate Drupal and Migrate Drupal UI modules carry content and configuration across, while the theme is rebuilt by hand because it cannot be migrated. Drupal 11 is the current major version, and it requires PHP 8.3 or later, so the target hosting stack has to be planned around that requirement before any migration work starts. Drupal.org's upgrade guide for Drupal 6 or 7 is the natural starting reference for the sequence and the constraints.

The effort splits into three tracks. Content, users, taxonomy and the configuration that core covers for the modules that shipped in Drupal 6 core move through the migration, and the reader should confirm that each of their modules is covered by a migration path rather than assuming it. The theme, any custom modules written for Drupal 6 and every contributed module need separate work: custom code must be rewritten against current APIs, and contributed modules must be checked for a Drupal 11 release or replaced. Ask for an inventory of modules, custom code and the theme early, because those three items usually decide the scope of the quote more than the content volume does.

Plan the cutover before the build is finished. Run the migration with Drush against a copy of the production database, record every error and unmapped field, and repeat the run until the output is clean enough to sign off. Confirm with the team who owns the content how forms, views and custom listings will be rebuilt, since those do not carry over as-is. Treat the old Drupal 6 site as a read-only reference during testing, and keep it running in a controlled environment until the new site has been accepted.

Which Drupal 6 parts map cleanly and which do not

Content and configuration that Drupal 6 stored through core are the most predictable part of the move. Core provides a migration path for the modules that shipped in Drupal 6 core, so nodes, users, taxonomy, menus, URL aliases and the field definitions attached to them can be read by the core Migrate, Migrate Drupal and Migrate Drupal UI modules and written into a new Drupal site. The work still needs checking, because field types, text formats and revisions change shape between versions.

Nodes and fields: Content types and their CCK fields are mapped to current entity types and field storage, and multi-value fields need a deliberate mapping.
Users and roles: Accounts, role assignments and permissions are carried across, but permission names and access rules should be reviewed.
Taxonomy and menus: Vocabularies, terms and menu trees usually map well, while custom menu logic may need rework.
Text formats: Input filters do not map one to one, so HTML that depended on Drupal 6 filters needs a sample review.
URL aliases and redirects: Aliases can carry over, and a redirect map is needed to protect search rankings.

Confirm each core area with a sample migration on a copy of the production database before you commit to a timeline.

Drupal 6 capabilities and their Drupal 11 equivalents

This table compares each major Drupal 6 capability with its Drupal 11 equivalent and shows how it moves. Core migration covers modules that were in Drupal 6 core, while contributed modules and themes need separate decisions. Read the migration column first, because it sets how much rebuild work the project carries.

Drupal 6 capability	Drupal 11 equivalent	Migration path and notes
Nodes and fields	Content types, nodes and core field types	Core migration. Map content types and fields, then compare node counts and revisions after a test run.
Taxonomy	Vocabularies, terms and entity reference fields	Core migration. Check term hierarchy and term references on migrated fields.
Users and roles	Users, roles and permissions in core	Core migration. Review permission grants after the run and compare them with the source site.
Menus and menu links	Menu system in core	Core migration. Check link order, access rules and any menus built by contributed modules.
URL aliases	Path aliases in core	Core migration. Confirm aliases and plan redirects for old URLs before launch.
Files	Core file entities, with Media for media assets	Core migration copies file records. Confirm file paths, and treat any move to Media as separate work.
Views	Views rebuilt on the new site	Confirm in a test run which views carry over. Plan to rebuild the rest, starting with an inventory of each view.
CCK field types	Core field types and entity reference fields	Map each CCK type during migration. Confirm a core or contributed equivalent exists before the full run.
Contributed modules and themes	Current contributed modules or custom code for each version	Themes must be rebuilt. Each module needs a current version or a decision to remove it.

Documented import paths for Drupal 6 sites

Drupal.org documents a small set of paths for moving a Drupal 6 site into a current Drupal site. Each path covers a different part of the job, so the choice of path shapes the scope of the build, the rebuild work and the testing that follows.

Core Migrate framework

The core Migrate API is the engine underneath every documented Drupal 6 path. It reads a source database, maps fields and entities to a destination site and records each migration so it can be rerun. Teams use it directly when the standard upgrade path does not match their content, and they need to check that every migration they define covers a Drupal 6 entity type and its revisions. Confirm the exact migration definitions with your developers before scoping custom mappings.

Migrate Drupal module

The Migrate Drupal module provides the migrations that read Drupal 6 core content, users, taxonomy, menus and configuration. Core provides an upgrade path for every module that shipped in Drupal 6 core, so the inventory of core features is usually the simpler part of the work. It does not carry over contributed modules or themes, so every contrib module in the old site needs a destination decision before the migration runs.

Migrate Drupal UI

The Migrate Drupal UI module adds a browser-based wizard for running the same migrations without the command line. It suits content teams who want to review the outcome of a test run, but it offers less control than Drush for repeated runs, scripted cutovers and large sites. Plan to rerun migrations on a fresh copy of the database during rehearsals, and confirm in your environment which options the wizard exposes for your Drupal 6 source.

Drush migration commands

Drush runs the same migrations from the command line, which makes it the usual choice for repeatable rehearsals, scripted cutovers and logging. Commands can be run in sequence, rolled back and rerun against a clean destination, so the team can measure each dry run before production. It does not decide what to migrate, so the team still needs a written list of content types, users and configuration to check after every run.

Migrate Plus for other sources

Migrate Plus is a contributed module that adds source plugins for data outside the Drupal 6 database, such as CSV, JSON, XML and remote APIs. It fits content that lives in spreadsheets, a legacy system or a feed rather than in the old Drupal database. It is contributed rather than core, so check its release compatibility with the target Drupal version before relying on it in a production plan.

Themes must be rebuilt

The documented upgrade path does not migrate themes from Drupal 6, so the front end is a separate build with its own budget and testing. Teams usually build a new theme on the current core theming system and map each Drupal 6 template to a component. Treat theme work as a distinct workstream with design sign-off, accessibility testing and browser checks, because a successful content migration can still deliver a site that looks broken.

How the Drupal 6 migration runs from inventory to decommission

This sequence moves a Drupal 6 site into a new Drupal 10 or 11 site in controlled stages, so each step produces evidence that the content, configuration and theme are correct before the old host is retired. Each step has a named check that must pass before the next one starts.

Inventory content, modules and themes
Record every content type, field, view, menu, taxonomy vocabulary, user role and enabled module on the Drupal 6 site, along with the custom code and theme files. Mark each item as one of three things: covered by the core upgrade path, replaced by a contributed module, or to be rebuilt by hand. Your team and DeployOpen review the list together, and the step closes when every item has an agreed disposition in writing and the content volumes are recorded for later comparison.
Set up the target Drupal site
Build the new Drupal 10 or 11 site on the hosting stack you have chosen, with a PHP version that meets the current requirement for that release and a supported database. Install the core Migrate, Migrate Drupal and Migrate Drupal UI modules and any contributed replacements identified in the inventory. The step is complete when the empty site passes a deployment check in a non-production environment and the migration modules are enabled without errors.
Run a pilot migration on a copy
Take a copy of the Drupal 6 database and files, never the live site, and run the migration into the new site with a limited set of content types. Review the migration report for failed or skipped rows, check fields, file paths, text formats and taxonomy references, and log each mapping decision. The step closes when a second run of the same pilot produces the same results, which confirms that the migration is repeatable.
Rebuild the theme in parallel
Start the theme rebuild as soon as the pilot shows the content structure is stable, because Drupal 6 themes cannot be migrated and must be recreated for the new version. Your front-end developers build the templates and components against the migrated content types, and content owners review key page layouts on the new site. The step is complete when the templates render every content type in the inventory without missing fields or broken navigation.
Run the full migration and rehearse rollback
Run the full migration on a fresh copy of the production data using Drush, and keep the migration IDs so that a rollback can be run for each migration. Rehearse the rollback on this copy, confirm that the new site returns to its prior state, and then rerun the migration. The step is complete when the content counts, user counts and configuration match the inventory, and the rollback procedure has been performed successfully at least once.
Compare old and new sites in a parallel run
Keep the Drupal 6 site live while the new site runs on a staging address, and compare the two side by side. Check page counts, URL aliases and redirects, search results, forms, logins, scheduled jobs and any integrations that send or receive data. Record each discrepancy with an owner and a fix, and repeat the comparison after each refresh of the data. The step is complete when the agreed comparison checklist shows no open high-priority differences.
Cut over to the new site
Freeze content editing on the Drupal 6 site, run the final migration from the latest data, and switch DNS or the load balancer to the new site. Confirm that redirects from old paths resolve, that forms and logins work, and that integrations point to the new site. Keep the Drupal 6 host available for rollback during an agreed window, and document the cutover steps and the time they took. The step is complete when the signed-off checklist shows the new site serving production traffic.
Decommission the Drupal 6 host
After the agreed rollback window closes without a reason to revert, export a final backup of the Drupal 6 database and files and store it under your retention policy. Remove DNS records, monitoring and scheduled jobs for the old host, then shut it down and retire its credentials and certificates. The step is complete when the archive has been verified as restorable and the host is removed from your inventory and asset register.

What data and integration work sits outside the import

The migration moves content, users, configuration and files into a new site. It does not port the custom code, rebuild the theme or reconnect the systems around the site, so these need their own line items in the plan. Start with an inventory of every custom module on the Drupal 6 site, every contributed module without a Drupal 11 equivalent and every place the site calls outside services. Each custom module must be rewritten against current Drupal APIs, and each one that fills a gap in the core upgrade path adds effort that the import itself will not show.

Integrations are where most surprises appear. If staff currently sign in through a corporate identity provider, check whether the site uses SAML or OpenID Connect and plan the replacement before cutover. The contributed samlauth module lets Drupal act as a SAML service provider, and its 8.x-3.14 release supports Drupal 10.3 and later and Drupal 11. The OpenID Connect module creates accounts on first sign-in, so confirm how existing user accounts will map to external identities. Search, forms, file storage and CRM or payment connections need the same review: confirm the replacement module, the credentials, and who owns each connection after launch.

Confirm the platform before the build starts. Drupal 11 requires PHP 8.3 or later, so check the PHP version on the current host and the modules the new site will depend on. Drupal runs on Apache, Nginx and other web servers, and the database can be MariaDB, MySQL, PostgreSQL or SQLite. Ask the hosting team to confirm the chosen web server, database version and PHP runtime in writing, and test the custom code and integrations against that stack in a staging environment. Platform gaps found late usually delay the cutover more than the content import does.

What drives the effort of a Drupal 6 migration

What makes a Drupal 6 migration cost more or less?

The biggest cost drivers are how much content, how many custom modules and how many bespoke features the site carries, not the Drupal version alone. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later, so the work is a rebuild into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush. Costs rise with the number of content types, fields, revisions, translations, custom code that has no equivalent in current core, and the number of themes that must be rebuilt. Costs fall when the content model is clean, the custom code is small, and the team can make decisions quickly. Ask any provider for a fixed-scope quote that lists each content type, module, integration and theme, because that list is what the figure depends on.

How long does a Drupal 6 to Drupal 11 migration take?

Duration depends on the same inventory that drives cost: content volume, custom modules, integrations, the number of theme templates and how much content must be checked after each trial run. Teams that rehearse the migration on copies of the database usually need more time for validation than for the initial import. Any timeline should come from a written scope that sets out phases, review points and acceptance criteria. No general duration applies to every site, so treat any single figure you hear without an inventory as a guess.

What must our team provide before a migration starts?

Your team needs to name the business owners who approve content models, provide access to the Drupal 6 codebase and database copy, and supply the hosting environment for the new site. You should also list every custom or contributed module in use, identify which integrations (payment, search, single sign-on, CRM) feed the site, and confirm which content must be kept, archived or dropped. Without these decisions the provider cannot produce an accurate written scope, and the schedule slips while questions are answered.

Can our in-house team migrate a Drupal 6 site without a partner?

Yes, an experienced in-house team can run the core Migrate path, provided it has Drupal development skills, can write custom migration code where core does not cover a source, and can rebuild the theme. The decision depends on capacity and risk tolerance: the team must learn the migration API, run repeated trial imports, verify content by hand and own the rollback plan. Teams that cannot commit those people for the full project usually scope a partner for the parts they cannot staff. Ask yourself whether the people who build the site will also operate it after launch.

What happens if we delay the migration and stay on Drupal 6 or 7?

Drupal 7 security support ended on January 5, 2025, according to Drupal.org. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet, so organizations that need more time can buy extended coverage from those vendors. That coverage buys time but does not remove the need to migrate, and the cost of extended support recurs for as long as you stay. Confirm terms, coverage and duration directly with the vendor, because they are set by the vendor rather than by Drupal.org. Delay also raises the cost of the eventual migration when modules and content drift further from current core.

How do the theme rebuild and the content migration affect effort?

The content migration is usually the more predictable part, because core provides an upgrade path for modules that were in Drupal 6 and 7 core. Themes must be rebuilt, not migrated, so the effort depends on the number of templates, layouts, components and responsive breakpoints in the current design. A design that is largely a copy of the old look can be rebuilt quickly, while a site with heavy custom templates, bespoke JavaScript or complex navigation needs design and front-end time. Ask for the theme rebuild to be scoped separately from the content migration so each can be reviewed on its own.

Which Drupal versions and PHP requirements shape the target?

The target version determines the required PHP version, and that choice affects hosting, module compatibility and the work needed after launch. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, according to Drupal.org. Drupal 11 is the current major version, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Choosing Drupal 11 now, rather than a version that will reach end of life sooner, reduces the number of upgrades you must plan after launch. Confirm the target and PHP version with your hosting team before the scope is written.

What raises or lowers the cost and duration

This table compares the main drivers of effort on a Drupal 6 to Drupal 11 migration and shows what pushes each one up or down. Use it to see which parts of your site are likely to dominate the quote, and to ask a partner how each driver was counted in the written scope. The main takeaway is that content volume, custom code and theme design usually matter more than the raw number of sites or pages.

Driver	What raises it	What lowers it
Content types and volume	Many Drupal 6 content types, nodes with deep revision history, and large media libraries that must be checked after each test run	A reduced content model agreed before the build, archiving of stale content, and migrating only what the business still uses
Custom modules	Site-specific code written against Drupal 6 APIs that has no Drupal 11 equivalent and must be rewritten or replaced	Removing unused custom code during the audit, and relying on contributed or core functionality instead of local hooks
Contributed modules	Many Drupal 6 contributed modules with no current release, or modules that lack a documented migration path to a current version	A short list of modules in active use, with replacements confirmed on Drupal.org before the scope is fixed
Themes and design complexity	A custom Drupal 6 theme with many template overrides, layout variants and page-specific styling that must be rebuilt by hand	A simpler design system, reuse of an existing current theme base, and a decision to rebuild only the templates the site needs
Multilingual needs	Content translation or entity translation in use, with translated nodes, menus and taxonomy terms to verify in each language	A single language, or a decision to migrate the default language first and add translations as a later phase
Integrations	Feeds, payment, CRM, search or single sign-on connections that depend on Drupal 6 modules and must be rebuilt on current equivalents	Clear inventory of external endpoints, and retiring integrations that no longer carry traffic
Quality of source data	Inconsistent field usage, broken references, mixed text formats and content stored in files outside the managed file system	A data cleanup pass on the Drupal 6 site before migration, and agreed rules for dropping or fixing invalid records

What usually goes wrong in Drupal 6 migrations

Drupal 6 migrations rarely fail on the core data move. They fail on what surrounds it: the theme, the contributed modules, the content nobody checked and the URLs that users and search engines still expect. Each risk below has a prevention step you can put into the plan before the build starts.

Assuming the theme migrates

Drupal 6 themes cannot be migrated to current Drupal, so the markup, regions, templates and CSS have to be rebuilt for the new theme system. Teams that budget only for content often find the theme is the largest line item once designers review the rebuilt pages. Prevention: inventory every template and region on the Drupal 6 site, decide which pages are redesigned and which are rebuilt to match, and agree that rebuild effort in the written scope.

Missing contributed module equivalents

Core covers the modules that were in Drupal 6 core, but many sites depend on contributed modules for views, fields, forms, pathing or workflow. Each one needs a current equivalent, a different approach or a deliberate decision to drop it. Prevention: list every enabled module on the source site, mark core, contributed and custom, and confirm the target module and its Drupal 11 support before any content mapping starts.

Unvalidated content after import

A migration can finish with no errors and still leave broken fields, lost revisions, missing files or text formats that render differently. Editors are the only people who can judge much of this. Prevention: define sample sets per content type, including old and heavily edited nodes, and require editors to sign off on rendered pages, attachments and taxonomy terms before cutover.

URL and redirect loss

Drupal 6 sites often have years of path aliases, legacy paths and inbound links that search engines and partners still follow. If the new site does not reproduce them, traffic and rankings fall at launch. Prevention: export the full alias table and top inbound URLs from analytics, map each one to a new destination, and test redirects on staging before DNS changes.

Running the upgrade without a rollback plan

Migrations are run with Drush and the migrate tools, and incremental runs can overwrite or duplicate content if the sequence is not controlled. Teams that have no tested rollback discover this during cutover. Prevention: run the full migration repeatedly on a copy of the source database, record the commands and order, and agree in advance who can stop the launch and how the old site stays available.

Staying on an end-of-life platform

Drupal 7 security support ended on January 5, 2025, and Drupal 6 is no longer a supported platform, so a site that waits for a convenient moment accumulates unpatched risk. Extended support from certified vendors can buy time, but it does not replace the migration. Prevention: set a migration deadline in the plan, confirm which support options apply to your version, and keep the old site under access controls until it is retired.

What your team provides and what you receive

The Drupal 6 codebase and a current copy of the production database are the first inputs DeployOpen needs, because the migration reads from the old site's data rather than from a description of it. Provide read access to the custom modules, the theme files, the settings.php file (with secrets handled through a secure channel rather than email), and a database dump taken from a point close to the planned cutover. Also confirm which contributed modules are installed and at what versions, since the upgrade path differs for modules that were in Drupal 6 core and for those that were not. Ask your team to confirm whether the site uses multiple languages, custom PHP filters, or file storage outside the default directory, because each changes the inventory.

Your team also supplies named content owners who can validate migrated content in a staging copy, and a decision-maker who can sign off the content that is retired. Before the build starts, decide which node types, users, comments, and old files will be left behind, and record those decisions in writing. Content that is not migrated still needs a redirect plan and a clear answer for the business. Confirm who will test forms, search, and any integrations with external systems, and make sure those people have time booked during the validation window. Expect the validation cycle to be the part of the project most dependent on your staff.

What you receive is defined by the written scope agreed before work starts. Typically that covers the new Drupal site on a supported PHP version, the migration of content and configuration that the agreed mapping includes, a rebuilt theme, a repeatable migration run that your team can rehearse, and documentation of the decisions, mappings, and known gaps. Ask for the scope to state explicitly which Views, custom code, and contributed modules are rebuilt, which are replaced, and which are dropped, so that acceptance testing has a clear reference. Ask also what is handed over for ongoing operations, and whether support after cutover is a separate arrangement.

How DeployOpen scopes and delivers a Drupal 6 migration

DeployOpen plans, builds, documents and supports Drupal 6 to Drupal 11 migrations inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.

How we scope

Inventory the Drupal 6 modules, content types, views, users and files that must move to the new site.
Decide which modules have a core migration path and which need a rebuilt or replacement equivalent on Drupal 11.
Record the theme rebuild, cutover approach and rollback expectations in the written scope before any work begins.

How we build

Build the Drupal 11 target on the PHP version and database your environment supports, confirming requirements against the Drupal.org documentation.
Run the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush migrations against a copy of the Drupal 6 database, repeating runs until results are verified.
Rebuild the theme and custom code, then test content, permissions, URLs and configuration against the source site.

How we hand over

Document the migration steps, Drush commands, mapping decisions and known gaps so your team can rerun or audit them.
Walk through the cutover runbook, including the rollback path, with the people who will operate the site.
Deliver the code, configuration and build artifacts in repositories your organization controls, with access transferred at handover.

How we support

Offer post-launch support for fixes, updates and security patches as a retainer, scoped separately from the migration.
Plan the path from Drupal 11 onward, including Drupal 10 end of life on December 9, 2026, so the next upgrade is not an emergency.
Ask about retainer terms, response expectations and what is covered before signing, since these are set in the written agreement.

Drupal 6 to Drupal 11 migration