Drupal 7 extended security support versus migration: which should you fund now?
If your team still runs Drupal 7 after January 5, 2025, the decision is not whether to leave, it is how fast you fund the move and whether to buy time first. Extended security support buys time for security patches from a certified vendor, while migration ends your dependency on an end-of-life platform. Drupal 7 security support ended on January 5, 2025, and the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Confirm directly with each vendor what they cover, which Drupal 7 modules are in scope, how they deliver patches, and how long their commitment runs, because the Drupal Association lists the providers without guaranteeing terms.
Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. Drupal.org's upgrade documentation describes building a new site and migrating content and configuration into it with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush. Themes must be rebuilt because they cannot be migrated. That means extended support does not replace the project, it only postpones it, and every month of delay adds to the rebuild backlog and to the number of contributed modules that will need replacements. The practical question is therefore how much of the work you can start now, such as inventorying content types, custom modules, integrations and forms.
Use extended support as a bridge with an exit date, not as a destination. Ask the vendor for a written statement of the end date, the patch delivery process and the cost structure, and plan your migration so that the final cutover falls inside that window with margin for a rollback. Also check your Drupal 7 modules against their current replacements, your PHP and database versions, and any third-party services that depend on old APIs. Your business case should compare the recurring support fee against a one-time migration budget, and it should state the risk of an unpatched public site if support lapses before cutover. Ask your implementation partner for a fixed-scope plan that sequences the rebuild so the new site can go live before the support window closes.
Which Drupal 7 assets carry over to a current Drupal site and which must be rebuilt
This table sorts common Drupal 7 assets into those the core Migrate path moves into a new site and those that need rebuilding, replacing or a separate migration piece. Read each row as a planning question: what the migration brings across, and what your team must budget to recreate by hand.
| Asset | Carries over with core Migrate | What to plan for |
|---|---|---|
| Content and nodes | Yes | Node bodies, revisions and fields map through the Migrate Drupal modules, but check embedded media tokens and text formats after the run |
| Users and roles | Yes | Accounts, roles and permissions migrate, but password hashing and custom user fields need a test login on the new site |
| Files and managed files | Yes | File entities migrate, while file storage paths and Media references usually need a separate Media migration piece |
| Taxonomy and fields | Yes | Vocabularies, terms and standard field types migrate, while field widgets and display settings must be reviewed |
| Themes | No | Drupal 7 themes cannot be migrated, so the front end must be rebuilt for the current theme system |
| Views | Not applicable | Views do not migrate reliably, so inventory listings and exports and rebuild them on the new site |
| Field Collection | Not applicable | Convert to Paragraphs as a separate step, installing the conversion module before the core run and checking nested revisions |
| Webform and Commerce | Not applicable | Webform and Commerce each have their own migration path, with Commerce needing checks on products, orders and payments |
Documented ways to move a Drupal 7 site into a new Drupal
Drupal 7 sites cannot be updated in place to Drupal 10 or later, so every route off the platform is a rebuild into a new site. The cards below cover the core migration tools, the Drush path, the parts that must be rebuilt by hand and the supporting modules that carry data the core tools do not handle well. Each one adds planning work, so compare them against the cost of extended support before you commit.
Core Migrate, Migrate Drupal and Migrate Drupal UI
The core Migrate, Migrate Drupal and Migrate Drupal UI modules move Drupal 7 content, configuration and users into a new Drupal site. The UI module provides a browser workflow, while the same migration can be driven from the command line. Run the migration against a copy of production, record the row counts for each entity type, and check the results field by field. Confirm which Drupal 7 modules have a migration plugin for your target version before you assume your content model will carry over.
Drush-driven migration path
Drupal.org documents running the migration with Drush instead of the UI, which suits repeatable runs, scripted cutovers and CI pipelines. Repeated dry runs against refreshed data expose mapping gaps early, and the same commands can be reused for the final cutover. Ask the team who will own the scripts after handover, since they become part of the operational record for the new site.
Themes must be rebuilt
Drupal 7 themes cannot be migrated into Drupal 10 or later, so the front end is a separate build. Budget for markup, component and template work, accessibility checks and responsive testing. This is often the largest visible change for editors and visitors, and it is where scope disputes start, so agree on page templates and breakpoints in writing before the build begins.
Migrate Plus for external data
Migrate Plus adds source plugins for CSV, JSON, XML and other feeds, which covers data that lives outside the Drupal 7 database, such as a legacy system export or a partner feed. It is a contributed module, so check its release line against your target Drupal version before you plan the work. Pull data from source systems into a staging area first, so that mapping problems do not surface in production.
Migrate Source CSV for spreadsheet data
Migrate Source CSV handles spreadsheet-style exports, usually for reference lists, legacy taxonomies or records held outside the site. Spreadsheets often contain encoding issues, merged cells and duplicate keys, so validate the file before loading it. Confirm the module's compatibility with your target Drupal version and document how each column maps to a field, since that mapping is what your reviewers will check.
Compatibility checks for every contributed module
Each contributed module on the Drupal 7 site needs a verified replacement, a migration plugin or a rebuild plan. Treat the compatibility check as a gate: a module without a stable release for your target version becomes a risk item, not a footnote. Record the module name, the version you will use, the replacement and who signed off on it. Ask the implementation partner to deliver this matrix as part of the scope.
How a Drupal 7 migration runs alongside extended support
This sequence moves a Drupal 7 site to a supported platform in controlled stages, with the live site and its extended support coverage kept in place until the new site has been proven against real content and traffic. Each phase ends with a written check, so the team knows when to move on and when the timeline needs to change.
Inventory modules, content and integrations
Start by listing every Drupal 7 module, content type, field, view, theme, user role, cron job and external connection, including the systems that send or receive data from the site. Your internal team usually knows the business owners, while the partner or developer reviews the code base and database to find custom modules and undocumented dependencies. Confirm which contributed modules have a supported successor on current Drupal, and note the ones that will need rebuilding, such as Views and themes, which do not migrate automatically. The step is done when you have a signed-off inventory with a migration path or rebuild decision recorded for each item.
Confirm extended support coverage for the build window
Before the build starts, confirm with the chosen certified provider what the extended security support covers, how patches are delivered to your Drupal 7 site, and what the provider expects from your side, such as keeping the codebase under version control. Ask how long the agreement runs and what happens if the migration takes longer than planned. Extended support covers security fixes on the old platform while the migration is being built, so it is not a substitute for the migration itself. The step is done when the terms are in writing and the migration team has a shared view of the coverage end date.
Build the target site and migrate a pilot copy
Create the new Drupal site on a currently supported version and run the core Migrate, Migrate Drupal and Migrate Drupal UI modules, or Drush, against a copy of the production database and files. Rebuild the theme on the new site, since Drupal 7 themes cannot be migrated, and map custom fields and content types to their new equivalents. Record every migration error, unmapped field and content item that failed to move. The step is done when the pilot runs end to end with a documented list of known gaps that the business has accepted or assigned to fixes.
Validate content, users and integrations on the pilot
Compare the pilot with the Drupal 7 source using a sample of nodes, users, menus, files, forms and search results, and test each integration, such as single sign-on, payment, CRM or email connections, against the new site. Involve content editors in checking that they can create, edit and publish content as they did before. Confirm that rollback works by rerunning the migration on a clean copy. The step is done when the business owners have signed off the pilot results and every blocking defect has a fix that has been retested.
Run the new site in parallel with the live Drupal 7 site
Keep the Drupal 7 site live for public visitors and editors while the new site is updated with a repeatable migration run, typically on a schedule agreed in advance. Track differences in content, users and integrations between the two sites, and fix the migration scripts or rebuilt components rather than editing the new site by hand. Keep applying the extended support patches to the Drupal 7 site until cutover, and review them as they arrive. The step is done when the delta between the two sites is small enough that the team agrees on a cutover window and the remaining differences are documented.
Cut over DNS and check redirects
On the agreed date, freeze content changes on the Drupal 7 site, run the final migration delta, and point traffic to the new site through DNS or the load balancer. Check that old URLs redirect to their new equivalents, that sitemaps and search engine references resolve, and that forms, logins and integrations work from the public internet. Keep the Drupal 7 site available so the team can roll back the DNS change if a critical problem appears. The step is done when a defined set of URL, login and integration checks passes on production and the cutover record is signed off.
Decommission the Drupal 7 site
Once the new site has run in production for an agreed period and the rollback option is no longer needed, archive the Drupal 7 code, database and files in line with your retention rules, and remove the server, database access and backups that are no longer required. Notify the extended support provider that the coverage is no longer needed, and confirm the end date in writing. Update the asset inventory, certificates, monitoring and access reviews to remove the old platform. The step is done when the old environment is removed or archived, the provider has confirmed the end of coverage, and the inventory no longer lists Drupal 7 as an active system.
What drives the cost and duration of a Drupal 7 migration
This table lists the main factors that change the price and length of moving a Drupal 7 site, and marks whether each one is a one-time project cost or a recurring one. Use it to shape the written scope you request from any partner, and to compare that scope with the extended support fee quoted for staying on Drupal 7.
| Driver | Why it changes cost or effort | One-time or recurring |
|---|---|---|
| Contributed module count and replacements | Each Drupal 7 module needs a Drupal 10 or 11 equivalent, a rebuilt configuration, or removal. Ask for an inventory mapped module by module. | One-time |
| Custom code | Custom modules and hooks must be rewritten for current core APIs. Sites with little custom code are usually cheaper to move. | One-time |
| Theme rebuild scope | Drupal 7 themes cannot be migrated, so every template, layout and component is rebuilt. Page template count drives this effort. | One-time |
| Data volume and revisions | Node count, file count and retained revisions affect migration run time, validation and rollback testing. | One-time |
| Identity and CRM integrations | Each SSO, CRM or API connection needs new configuration, credentials and test cases. Confirm which systems the site calls today. | One-time, with recurring maintenance |
| Multilingual content | Translated nodes, fields, menus and taxonomy need language configuration and separate checks after the move. | One-time |
| Commerce content | Products, orders and customers from Commerce 1 need mapping and checking, and payment and shipping rebuilt. Confirm the module versions in use. | One-time |
| Views and webforms | Views that do not migrate and complex webforms are rebuilt by hand. Count listings, exports and forms in the inventory. | One-time |
| Extended security support fee | Certified vendors charge for ongoing patches while the site stays on Drupal 7. Request the fee, term and renewal terms in writing. | Recurring |
| Hosting and PHP runtime | Running Drupal 7 on a supported PHP version and database during the transition may carry infrastructure costs. Confirm with your hosting team. | Recurring |
What goes wrong when a Drupal 7 site stays on an end-of-life platform
Staying on Drupal 7 after security support ended changes the risk profile of the whole site, not just one module. The cards below cover the failure modes that tend to appear together: exposure, partial coverage, orphaned code, runtime constraints and a migration that keeps moving. Each card names the control that keeps the risk visible and the terms to confirm before signing.
Unpatched exposure after support ends
Drupal 7 security support ended on January 5, 2025, so core and contributed modules no longer receive public security releases from the community. Any vulnerability disclosed after that date stays open on your site unless a provider patches it for you. Ask who triages advisories for your exact modules, how quickly a critical fix reaches your build, and whether the provider tests the patch against your theme and custom code before deployment.
Gap between extended scope and full platform
Extended security support covers the security side of Drupal 7, but it does not rebuild features, add new functionality or keep your integrations working with newer services. Your team still owns feature bugs, browser issues, third-party API changes and hosting changes. Write down which components the provider covers, which stay with your team, and who answers when a non-security defect blocks a release.
Contributed modules without a maintainer
Many Drupal 7 sites depend on contributed modules whose maintainers have stepped away, and some of those modules may not be covered by the extended support scope. A module with no maintainer cannot get a fix from the community, so a single abandoned dependency can leave a whole feature exposed. Inventory every contributed project, its last release and whether the provider covers it before you commit to a support term.
PHP version constraints
Drupal 10 requires PHP 8.1 or later, and no supported Drupal version runs on PHP 7. A Drupal 7 site therefore sits on a PHP runtime that current operating systems, libraries and hosting images may stop supporting, which blocks dependency updates and forces risky workarounds. Check your PHP version, your database and web server versions and whether your hosting provider can keep them patched while you wait for the migration.
Migration slipping under deadline pressure
Once support contracts are signed, the migration can drift because the site appears stable and the budget for the rebuild competes with new work. Drupal 7 sites cannot be updated in place, and themes must be rebuilt, so the work is larger than a routine upgrade. Set a dated plan with content freeze points, sign-off gates and a written decision on when extended support ends, and review progress against that plan at each milestone.
Support terms that are not written down
Verbal assurances about patch timing, covered modules and escalation paths are hard to enforce when an incident happens. Before you buy, ask for the coverage list, the response targets for critical advisories, the term length, renewal and exit conditions, and what happens to patches if you migrate partway through the term. Keep the signed terms in the same change-control record as your migration plan so both teams work from one document.
Where Drupal CMS and identity changes fit the target design
A migration off Drupal 7 is also the point where you can revisit how users sign in and how content is managed, but these are design decisions to make deliberately rather than carry over by default. For single sign-on, the contributed *SAML Authentication* module (samlauth) lets the new site act as a SAML service provider, and the contributed *OpenID Connect* module lets external OpenID Connect providers authenticate users and create accounts on first sign-in. Before you commit, confirm which release line supports your target Drupal version. The latest stable samlauth release, 8.x-3.14, supports Drupal 10.3 and later and Drupal 11, so a Drupal 7 identity setup cannot be assumed to map one to one onto it. Check the project page for current compatibility before you scope the work.
Drupal CMS is a distribution built on Drupal core, aimed at marketers and content teams, with recipes, site templates, the Drupal Canvas visual page builder and optional AI tools. Drupal CMS 2.0 is the current major release. It is an option for content teams that want a different editing experience, but it is not a drop-in replacement for the modules and configuration on your Drupal 7 site. Your Views, custom fields, workflows and theme still need to be inventoried and rebuilt or confirmed against the target version. Ask your partner to map each Drupal 7 feature to a supported component on the target release, and to flag any that exist only as custom code.
Treat identity and CMS choices as scope items that feed the migration plan, not as afterthoughts. Decide early whether the existing login process, roles and single sign-on must be preserved for users during cutover, because that affects testing and rollback. Ask the vendor to confirm the module versions, the identity provider settings they will configure, and how account matching works for existing users. Also confirm whether the Drupal CMS distribution would change your editorial workflow, content model or hosting needs, so that the decision is made once and documented in the written scope.
Questions buyers ask before choosing extended support or migration
What does Drupal 7 extended security support cost, and what drives the price?
Extended security support is sold by certified vendors, and the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting. Drupal itself has no paid edition, so you pay the provider, not the Drupal project. Price is usually set by the size and number of your sites, how many contributed modules you run, and the length of commitment you choose. Ask each vendor for a written quote that states the coverage period, which modules are included, how patches are delivered, and whether custom code is covered. Compare the total of the support fees across the months you expect to stay on Drupal 7 against the one-time cost of migration.
How long does a Drupal 7 migration take?
The window depends on the scope you can define, not on a fixed number. The main drivers are the number of content types and fields, custom modules that must be rewritten, how many Views, Webforms, multilingual setups and Commerce stores you run, and how many themes must be rebuilt. Drupal.org documentation states that Drupal 6 and 7 sites are migrated into a new site rather than updated in place, and that themes must be rebuilt. Ask any partner for a phased plan with a content inventory, a rehearsal migration and a cutover date, and confirm which contributed modules have stable releases for your target version.
What does our team need to provide for a migration?
Plan to supply the people and information that only your organization holds. This usually includes a named business owner who signs off content and workflow decisions, access to the live Drupal 7 codebase and database copy, a list of integrations such as single sign-on, CRMs and payment gateways, and test accounts for each external system. You will also need staff time for user acceptance testing and for approving redirects and URL aliases. Confirm these commitments in the written scope so that delays do not appear as vendor overruns.
Can our internal developers run a Drupal 7 migration themselves?
Internal teams can run a migration if they have Drupal engineers who know the Migrate API, the core Migrate, Migrate Drupal and Migrate Drupal UI modules, and Drush. The harder work is usually rebuilding custom modules and themes, not moving content. Assess your team against three questions: has anyone migrated a Drupal site before, can they test rollbacks, and can they keep the site patched during the project. If the answer to any is no, a fixed-scope partner engagement or a split of responsibilities may reduce risk. Ask which parts you will own after handover.
Does Drupal have a paid edition or license fee?
No. Drupal and all contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under the GNU General Public License, version 2 or later (GPL-2.0-or-later), and there is no paid edition of Drupal itself. Any fee you pay for Drupal 7 extended security support or for a migration is for services, such as patch delivery, engineering and testing, rather than a license to use the software. Check the Drupal.org licensing page with your legal team before you sign any contract that describes the work as a license.
What do the target version and PHP requirement mean for our hosting?
The target version sets your minimum PHP runtime. 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, and no supported Drupal version runs on PHP 7. Your current Drupal 7 hosting may therefore be unable to run the target release, so hosting, web server and database choices often change during the project. Drupal runs on Apache, Nginx and other web servers, with MariaDB, MySQL, PostgreSQL or SQLite as the database. Ask your hosting team to confirm the supported PHP and database versions before you choose a target.
What risks come with staying on an end-of-life Drupal 7 site?
Drupal 7 security support ended on January 5, 2025, so vulnerabilities reported after that date will not receive community fixes for core. Your exposure depends on what the site does, which contributed modules it uses, and whether it handles personal or payment data. Extended support reduces, but does not remove, this exposure, and it does not add new features. Your security team should record the risk in the register, confirm how patches are tested and deployed under any vendor contract, and set a date for the migration decision.
Official sources for Drupal 7 support and migration
Four Drupal.org pages set the facts behind the decision: who provides paid security patches, when Drupal's release cycle moves, how a Drupal 7 site is actually migrated, and which PHP version each release needs. Check each one against your own site inventory before you sign a support contract or set a migration date.
Extended support partners
This Drupal.org page lists the certified vendors that provide Drupal 7 extended security support, currently HeroDevs and Tag1 Consulting. Confirm which vendors cover the contributed modules your site actually runs, not only core, and ask each one for the written scope, the coverage period and how they receive and ship patches. Ask whether they also cover the PHP and database versions your hosts run.
Core release schedule
The core release schedule sets when Drupal 10 leaves support and when Drupal 12 is due, so it shapes the target version for a migration. Use it to check whether a Drupal 7 project that lands on Drupal 10 would need a second upgrade soon after launch. Security releases follow a fixed Wednesday pattern, which helps you plan patch windows for your own site.
Drupal 6 or 7 upgrade documentation
This documentation explains why a Drupal 7 site cannot be updated in place to Drupal 10 or later and must be migrated into a new site. Read it to confirm the core Migrate, Migrate Drupal and Migrate Drupal UI modules, or Drush, cover your content types and configuration. Note the documented point that themes must be rebuilt, since that is usually the largest line in the work.
PHP requirements by version
The PHP requirements page lists the minimum PHP version for each Drupal release and confirms that no supported Drupal version runs on PHP 7. Compare these minimums with your current hosting stack, since a Drupal 7 site on an older PHP build may need a hosting change before it can run any supported target. Include the PHP upgrade in your cost comparison, because it applies whether you pay for extended support or migrate.
Licensing and contributed code
Drupal core and most contributed projects are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. Paid extended support therefore covers the service of patches and advisories, not a license you must buy. Check the licensing page to understand which code you may modify, redistribute or hand to a new vendor during a migration.
How DeployOpen scopes a Drupal 7 migration
DeployOpen works on fixed-scope engagements, and the scope is agreed in writing before any work starts. For a Drupal 7 migration, that document should name every site, multisite instance, language, content type, user role and integration in the move, along with what is out of scope, such as Views or themes that will be rebuilt by hand rather than carried over. The scope normally follows five stages: inventory, migration build, testing, cutover and documentation. The inventory stage is where most of the uncertainty gets resolved, because it produces the list of contributed modules, custom code, field collections, Webform and Commerce data, and file storage paths that the migration has to handle. Ask any partner to show how the inventory output feeds into the build estimate, and to state which Drupal 7 components will be rebuilt rather than migrated.
DeployOpen does not publish a price list. A quote follows from the written scope, so the reader should expect the quote to itemize the stages above, the number of content and configuration types in scope, the test cycles agreed, and the cutover window. Ask whether the quote separates one-time migration work from recurring costs. Recurring costs usually include a retainer for ongoing support after launch, which DeployOpen offers as an optional arrangement covering the post-launch period, and any extended security support fees paid to a certified vendor if the cutover slips. Those vendor fees are paid to the vendor, not to DeployOpen, and the reader should confirm the vendor's own terms directly.
DeployOpen prepares systems, controls and evidence for compliance assessments, including records of the migration test runs, access changes, backup checks and cutover decisions. It does not issue audit reports, attestations or certifications. If the organization must demonstrate controls to an assessor, ask the partner which evidence will be produced at each stage and confirm with your auditor which artifacts they will accept. The written scope should also state who signs off each stage, so that the decision to stop running Drupal 7 has a named owner.
