Drupal officially dropped support for PHP 7.4 starting with Drupal 10, which was released in December 2023. If you’re still running PHP 7.4 on a Drupal site, you need to upgrade to at least PHP 8.1—and preferably PHP 8.2 or higher—to continue receiving security updates and maintaining compatibility with current Drupal versions. This is a hard deadline, not a gentle suggestion; Drupal 9 reached end-of-life in November 2023, and PHP 7.4 itself was deprecated in 2021, so you’re operating on an increasingly isolated system vulnerable to both known vulnerabilities and compatibility breakage.
For most site owners, this means either upgrading Drupal core to version 10 or 11 (which requires PHP 8.1+) or staying on an unsupported Drupal 9 installation that no longer receives patches. The exact path depends on your codebase, custom modules, and hosting provider. A live e-commerce site running custom payment integration code written for PHP 7.4 may take weeks to audit and test; a blog with standard modules may migrate in days. The earlier you assess your situation, the more time you have to plan for the transition without rush fees or downtime.
Table of Contents
- Why Did Drupal Drop Support for PHP 7.4?
- Understanding the Version Compatibility Chain
- Assessing Your Custom Code and Contributed Modules
- Planning and Executing the Drupal Upgrade
- Common Migration Pitfalls and Warnings
- Testing and Validation Post-Upgrade
- Hosting and Long-Term Support Considerations
- Frequently Asked Questions
Why Did Drupal Drop Support for PHP 7.4?
drupal‘s move away from PHP 7.4 reflects the broader ecosystem shift toward modern PHP versions. PHP 7.4 reached end-of-life in November 2022, meaning the PHP developers themselves stopped issuing security updates. Running an end-of-life PHP version exposes your Drupal site to known, unpatched vulnerabilities in the language itself—something no security-conscious team can justify for production sites. Additionally, PHP 8+ introduced significant language improvements: named arguments, match expressions, attributes, and readonly properties that allow Drupal developers to write cleaner, more maintainable code and catch bugs at compile-time through stricter type checking.
Drupal 10 and 11 lean heavily on these PHP 8 features internally. The core framework now uses type declarations throughout, union types for functions, and newer OOP patterns that simply don’t work in PHP 7.4. Rather than maintain backward compatibility code to support a three-year-old PHP version, the Drupal core team made a clean break, allowing the framework to move forward without legacy workarounds. This isn’t punishment; it’s pragmatism. If you’re building a Drupal site from scratch today, starting with Drupal 10 on PHP 8.2 gives you years of forward compatibility and access to the full breadth of modern contributed modules.
Understanding the Version Compatibility Chain
Drupal’s version support structure works like this: Drupal 7 (deprecated since 2022), Drupal 8 (end-of-life November 2021), Drupal 9 (end-of-life November 2023), and Drupal 10+ (actively supported). Each Drupal version has its own PHP requirements. Drupal 9 officially supported PHP 7.3 through 8.0; Drupal 10 requires PHP 8.1 at minimum. The limitation is real: if you attempt to run Drupal 10 on PHP 7.4, the installer will fail during the requirements check, and the site will refuse to boot. You cannot force it; the code simply won’t execute.
Your hosting provider plays a role here. Many shared hosts still offer PHP 7.4 in their cPanel or hosting control panels, but they’re actively deprecating it. Some hosting companies, like Kinsta and WP Engine, have already dropped PHP 7.4 entirely. If your host still supports it, you need to verify they offer at least PHP 8.1 as an option before planning your migration. Some smaller hosts lag behind, and you may need to contact support to confirm they’ve built PHP 8.2 binaries in their environment. Additionally, if your site uses third-party services or APIs (payment gateways, CDNs, email services), check their documentation to ensure they support PHP 8.1+; occasionally an old API client library may not, forcing you to upgrade that dependency first.
Assessing Your Custom Code and Contributed Modules
The biggest risk in upgrading Drupal isn’t usually core—it’s your custom modules, contributed modules, and theme code. A site built with standard, well-maintained Drupal modules may upgrade cleanly; a site with five-year-old custom code written before PHP 7.4 deprecations may have serious issues. The most common problems are: functions removed in PHP 8 (like `each()`, `split()`, or `ereg*()`), relying on implicit type coercion that’s now stricter, or using old MySQL functions instead of MySQLi or PDO. For example, if your custom module calls `mysql_query()`, the entire module will fail instantly in PHP 8, because those functions were removed entirely. Start by running Drupal’s `upgrade_status` module.
This tool scans your codebase, contributed modules, and custom code, and reports which ones are compatible with Drupal 10 and PHP 8+. It won’t catch everything—subtle type errors can hide until you run real queries—but it gives you a clear inventory of what needs attention. For each flagged module or custom script, you have three options: update it to be PHP 8 compatible (sometimes a one-line fix, sometimes weeks of work), find a replacement module that’s been updated, or remove the functionality entirely. A real-world example: a legacy Drupal 7 site with a custom content-type-specific backup module that used the deprecated `create_function()` to generate callbacks. The fix required rewriting those callbacks as proper closures—not hard, but it needed testing to ensure the backups still ran correctly.
Planning and Executing the Drupal Upgrade
The recommended path is to upgrade to Drupal 10 first, then to Drupal 11 (released June 2024) once you’ve stabilized on 10. This staged approach reduces risk. You should perform the upgrade in a local development environment first, then a staging site that mirrors production, then finally production itself. This testing process typically takes 2-4 weeks for a complex site and 3-7 days for a straightforward one. During testing, you’ll run through all critical user journeys: creating and editing content, checking e-commerce checkout flows, verifying API integrations, and testing any custom admin screens or reports.
When upgrading, you must also upgrade PHP at the same time or very soon after. The recommended approach is to upgrade Drupal to 9.5 (the final release) while still on PHP 7.4 (to verify backward compatibility isn’t blocking you), then upgrade PHP to 8.1, run the test suite again, and then upgrade Drupal to 10. Some teams prefer a different order—upgrading PHP first, then Drupal—but this requires more thorough testing because you’re changing two variables at once. A tradeoff: upgrading everything simultaneously gets you to modern versions faster, but makes troubleshooting harder if something breaks. Staging both changes separately takes longer but isolates problems more clearly.
Common Migration Pitfalls and Warnings
One frequent mistake is assuming that because a module’s Drupal.org page says “Drupal 10 compatible,” it will work without issues. Compatibility means it won’t immediately crash; it doesn’t guarantee all features work perfectly or that there are no subtle bugs. Always test contributed modules thoroughly against your specific configuration. Another pitfall: database migration. Drupal’s database structure sometimes changes between major versions. The upgrade process handles most migrations automatically, but custom database tables in your code won’t auto-update.
If you have custom code that creates or modifies database tables, you need a corresponding update hook in a `.module` file to ensure those tables migrate correctly. A serious warning: don’t attempt this upgrade on a live site during business hours without a solid rollback plan. If the upgrade fails halfway through—a custom module throws an uncaught exception, a database constraint violation occurs, or PHP simply crashes—you need a way to restore the previous Drupal version and PHP immediately. The safest approach is a full database backup, a code backup, and ideally a separate staging environment running in parallel so you can keep the old site live while you prepare the new one. One real incident: a Drupal 9 site running a custom bulk-import module that worked fine in PHP 7.4 but, after upgrading to PHP 8.1, crashed during imports because the module used uninitialized variables. The developer had relied on PHP’s loose type juggling; PHP 8 was stricter and threw warnings-turned-errors, breaking the import. The site was down for 90 minutes until the fix was deployed.
Testing and Validation Post-Upgrade
After upgrading, you must run the Drupal test suite and any custom test suite you’ve built. Even if you’ve tested manually in staging, automated tests often catch subtle issues: race conditions, edge cases in form handling, or API response mismatches that you missed. Enable Drupal’s logging (`/admin/config/development/logging`) to ERROR or WARNING level and monitor it for 48 hours after upgrade. Spikes in logged errors often reveal problems your manual testing missed. Also check security-focused logs: has the PHP error log grown? Are there new permission errors or deprecated function warnings? Performance testing is critical.
PHP 8+ is generally faster than PHP 7.4, but your site’s caching configuration may need adjustment. If you’re using OPcache or Memcached, clear those caches after upgrade and monitor memory usage for 24 hours to ensure caching behavior is stable. A concrete example: a Drupal 9 site upgraded to Drupal 10 and PHP 8.1, and initially showed a 15% increase in page load time because a cached module’s initialization was being called multiple times per request. The issue was a change in PHP 8’s object-comparison semantics; the module’s cache-key logic wasn’t accounting for the stricter type checking. The fix was minor (casting a string to int), but it required reading PHP 8 migration documentation and understanding the change.
Hosting and Long-Term Support Considerations
Before committing to the upgrade, verify that your host will support PHP 8.1 or 8.2 for the foreseeable future. Contact their support team and ask their PHP 8+ roadmap. Some budget hosts lag 12-18 months behind the PHP release cycle; if they’re still selling PHP 7.4 as a “supported” option, they may not have PHP 8+ ready in their infrastructure yet. If your current host doesn’t support modern PHP, now is the time to migrate to one that does. Moving hosts and upgrading Drupal simultaneously adds complexity, but it’s sometimes the best long-term decision.
Managed Drupal hosts like Pantheon, Acquia, or Platform.sh have Drupal 10+ and PHP 8.2+ pre-configured and regularly tested; this eliminates uncertainty around hosting compatibility. Once you’re on Drupal 10, you’re locked into a support window: Drupal 10 will receive security updates until June 2026, and Drupal 11 (released June 2024) has security support through June 2027. Plan for a Drupal 11 migration by mid-2026 to avoid being on an unsupported version. The sooner you migrate from Drupal 9 and PHP 7.4, the longer your security window and the fewer “legacy” code patterns you’ll accumulate. A site that stays on Drupal 9 until November 2024 and then rushes to upgrade faces a compressed timeline; a site that migrates now has 18 months to refactor custom code and test thoroughly.
Frequently Asked Questions
Can I keep running Drupal 9 on PHP 7.4 indefinitely?
Technically yes, but no. Drupal 9 stopped receiving updates in November 2023, and PHP 7.4 stopped receiving patches in November 2022. You’re running on an unsupported, unpatched stack vulnerable to known exploits. Any new vulnerabilities discovered won’t be fixed. Security-conscious hosting companies and payment processors may refuse to work with such old versions. You should treat this as a temporary state, not a long-term strategy.
What’s the real cost of upgrading in terms of downtime?
For a straightforward Drupal 9 site with standard modules, 30 minutes to 2 hours of downtime is typical. For a complex site with custom code, 4-8 hours is common. Using a staging environment and running the upgrade there first can reduce live downtime to just a code deployment and database swap, potentially 5-15 minutes. The exact cost depends on your site’s complexity and how thoroughly you test beforehand.
Will upgrading to Drupal 10 and PHP 8.1 break my custom theme?
Possibly. If your theme uses Twig templating and pure CSS, it’s likely compatible. If it has custom PHP functions or relies on old Drupal APIs, you may need to update it. Running Drupal’s upgrade_status module will flag theme issues. Have a developer review your theme’s custom code before upgrading.
Can my hosting provider upgrade PHP for me automatically?
Many shared hosts offer an automated PHP upgrade tool in the control panel, but it won’t upgrade your Drupal installation automatically. You must upgrade Drupal core separately, which usually involves running database updates. Managed hosts sometimes offer migration services; it’s worth asking.
Is Drupal 11 worth the immediate jump, or should I stay on Drupal 10?
Drupal 10 is currently stable and well-supported (until June 2026). If you’re upgrading from Drupal 9, reach Drupal 10 first, stabilize for a few months, and then plan a Drupal 11 migration. Trying to jump directly to Drupal 11 compresses the testing window and increases risk.
What if I have a custom module that the upgrade_status tool says is incompatible?
You need a developer to update it. First check if there’s a newer version of the module available on Drupal.org that’s already been updated. If not, you’ll need to hire someone or use a module replacement. If the module is critical and you can’t update it, delaying the upgrade may be necessary, but only temporarily—it pushes you closer to an unsupported stack.
