Not every Drupal site that needs work needs a migration. A site on an outdated minor version with maintained custom modules may need a version upgrade. A site with accumulated technical debt may need remediation. A site with misaligned architecture may need modernization. Migration — moving to a new platform or a fundamentally restructured version of the current one — is the right answer in specific circumstances, and understanding which circumstances those are shapes whether the project goes well.
When Migration Is the Right Answer
The platform version is no longer supported. Drupal 7 reached end of life in January 2025. Drupal 8 reached end of life in November 2021. Sites still running on these versions are not receiving security updates from the Drupal security team, which means documented vulnerabilities accumulate without remediation. Migration to a supported version — Drupal 10 or 11 — is not optional for sites that need to maintain security.
The existing architecture cannot support current requirements. A Drupal site built on a data model or architectural approach that cannot accommodate what the organization now needs — new content types, new integrations, new editorial workflows, new scale — may require a migration rather than an extension. If the existing structure would need to be substantially rebuilt to support current requirements, rebuilding from a current foundation is often more efficient than extending a structure that was not designed for the purpose.
The codebase is not maintainable. Heavily customized Drupal 7 or 8 sites sometimes contain so much technical debt — undocumented custom modules, fragile dependency chains, patterns that no longer have active community support — that maintaining the existing codebase costs more than rebuilding on a current foundation. A technical assessment distinguishes between a codebase that is maintainable with focused remediation and one where the debt has compounded to the point where a migration is more practical.
The organization’s needs have fundamentally changed. A site built to serve one function that now needs to serve a substantially different one — a simple informational site that needs to become a member portal, a single-language site that needs to become multilingual at scale — may require the kind of structural rethinking that is easier to do as a migration than as an extension of the original build.
When Migration Is Not the Right Answer
A site on a current, supported version of Drupal with a sound codebase and accumulated technical debt in specific areas is more likely a candidate for remediation than migration. Incremental cleanup — addressing debt in the areas that are actively causing problems, updating dependencies systematically, improving documentation — is less disruptive and often faster than a full migration.
A site that needs new features but has a sound foundation is a candidate for feature development, not migration. New functionality built on a working Drupal platform does not require starting over.
Understanding the distinction between a platform that needs attention and a platform that needs replacement is the work of a technical assessment, not a preference.
What a Drupal Migration Actually Involves
Whether migrating from Drupal 7 to Drupal 11, from a legacy custom build to Drupal CMS, or from a different platform to Drupal, the process follows a consistent structure.
Content and configuration audit. What content exists, how it is structured, what integrations exist, what custom modules do, and what the new platform needs to do that the current one does not. This audit produces the scope.
New platform architecture. Content model design, hosting and infrastructure selection, editorial workflow design, and integration architecture — all decided before build work begins against the requirements the audit surfaced.
Content migration. Drupal’s Migrate module provides a framework for moving content from a previous Drupal installation to a new one. Content types, fields, and taxonomy terms can be mapped and migrated with varying degrees of automation depending on how much the data model changes between versions. Content that cannot be migrated automatically is recreated.
Custom module migration or replacement. Custom modules from a previous Drupal version cannot be directly installed in a new version without updates. Each custom module needs to be assessed: is it still needed, does a contributed module now handle the same function, or does it need to be rebuilt for the new version?
Theme development. The frontend theme from the previous installation does not migrate directly. A new theme is developed for the current version, reflecting the current design and built to the current theme system.
Testing and launch. The full site is tested against a defined checklist before go-live. The launch is a DNS change that points the domain to the new installation.
How Long It Takes
A migration from a well-maintained Drupal 9 or 10 installation to Drupal 11 with a relatively clean codebase and modest customization: six to twelve weeks. A migration from a heavily customized Drupal 7 installation with significant custom modules and large content volume: three to six months. The audit produces the actual estimate for the specific situation.
How Cool Fire Inc Approaches Drupal Migrations
Cool Fire Inc has managed Drupal platform migrations and modernization projects since 2005, including migrations from Drupal 7 through current versions. Every project begins with a technical assessment that determines whether migration is the right approach and produces a realistic scope before any migration commitment is made.
Frequently Asked Questions
How do I know if my Drupal site needs a migration or just an upgrade?
A version upgrade addresses the platform version without substantially changing the architecture or content model. A migration involves restructuring the platform — new content model, new theme, potentially new hosting — alongside the version change. If the current codebase is maintainable and the architecture supports current requirements, an upgrade is usually the right path. If either is not true, migration is likely more practical.
How much does a Drupal migration cost?
It depends on the current platform’s complexity and the requirements for the new one. A straightforward migration from a well-maintained recent Drupal version can run $15,000 to $40,000. A complex migration from a heavily customized Drupal 7 site with significant custom modules and large content volume is a larger project. A technical assessment produces a specific estimate.
What happens to my content during a Drupal migration?
Content is migrated using Drupal’s Migrate module or custom migration scripts, depending on the complexity of the data model change. Structured content — nodes, taxonomy terms, media, users — migrates with high fidelity when the destination content model is designed to receive it. Content that cannot be automatically migrated is recreated.
Will my site go down during a Drupal migration?
No. The new site is built and fully tested before the domain is pointed to it. The go-live is a DNS change that typically propagates within 24 hours. There is no required downtime.
What is the difference between a Drupal migration and a Drupal upgrade?
An upgrade updates the version of Drupal core and contributed modules on the existing installation. A migration builds a new installation on the current Drupal version and moves content, configuration, and custom functionality to it. Most version transitions from Drupal 9 or 10 to 11 are upgrades. Transitions from Drupal 7 to current versions are effectively migrations because the architecture changed too significantly to upgrade directly.