Drupal 7 reached end of life on January 5, 2025. A year later, in 2026, there are still tens of thousands of Drupal 7 sites in production, most of them running on borrowed time. If yours is one of them, this checklist is for you.
This is the exact checklist we use internally when we onboard a Drupal 7 migration project. No fluff, no generic advice, just the steps that actually matter.
Why you cannot delay this anymore
- No more security patches. Drupal 7 core and contrib modules no longer receive security updates from the community. Every day your site runs is a day it accumulates known vulnerabilities.
- No more PHP support. Drupal 7 officially supports PHP 5.6 through 8.1. Most hosts have moved on to PHP 8.2 and 8.3. Running on older PHP means your host will eventually force an upgrade you cannot complete.
- Module ecosystem is dying. The contrib modules you depend on are losing maintainers. Bugs will not get fixed. Features you need will not be added.
- Compliance risk. Running unpatched software is a red flag in security audits, SOC 2 reviews, and GDPR assessments. Your customers, insurers, and partners will notice.
If your organization has any compliance obligations at all, "we are planning to migrate next year" is no longer an acceptable answer.
Your options (in order of common choice)
- Migrate to Drupal 10 or 11. The native upgrade path. Preserves your Drupal knowledge, content, and integrations. Usually the cheapest and least disruptive option if your site was built reasonably cleanly.
- Migrate to WordPress. Sometimes makes sense for smaller sites that no longer need Drupal's power. Usually a content-only move.
- Rebuild on a different stack. Headless CMS, custom framework, Jamstack. Only worth it if you have a specific reason to leave traditional CMS territory.
- Do nothing and hope. Technically an option. Not a good one.
For most Drupal 7 sites, option 1 is correct. The rest of this article assumes you are going to Drupal 10 or 11.
The migration checklist
Phase 1: Audit and planning (1 to 3 weeks)
Inventory your content:
- Total node count, broken down by content type
- Total user count and roles
- Total taxonomy terms and vocabularies
- File storage size and file count
- Custom block count
- Menu structure and depth
Inventory your modules:
- List every contrib module and its version
- List every custom module and its purpose
- Check which contrib modules have a Drupal 10 or 11 port (most do, some do not)
- For modules without a port, decide: replace, rewrite, or drop the feature
Inventory your integrations:
- External APIs you call
- Services that call your site (webhooks, form submissions)
- Analytics, advertising, and tracking pixels
- Email infrastructure (transactional, marketing, notifications)
Audit your theme:
- Custom theme or contrib base theme?
- How much PHP in templates (PHPTemplate is gone in Drupal 10, everything is Twig)
- Responsive breakpoints and design system maturity
- Frontend framework dependencies (Bootstrap 3 is gone, jQuery is partly gone)
Audit your SEO:
- Export the full URL list with Google Analytics or Screaming Frog
- Identify top 200 pages by traffic (these are your "must preserve" URLs)
- Document existing meta tags, OG tags, and structured data
- Export your redirect rules (you will need them for the new site)
Phase 2: Technical planning (1 week)
- Decide: Drupal 10 or Drupal 11? In 2026, Drupal 11 is the safer bet.
- Pick your hosting. Managed Drupal hosting removes a whole category of cost and risk.
- Pick your deployment strategy: staging environment, Git workflow, CI/CD pipeline.
- Plan your rollback. Every migration needs a documented "what do we do if production breaks" plan.
- Schedule your cutover window. Pick a low-traffic period for your audience.
Phase 3: Build the new site (2 to 8 weeks)
- Set up a fresh Drupal 10 or 11 installation on staging
- Recreate content types with matching field structures
- Install contrib modules (or their replacements) on the new site
- Port custom modules to Drupal 10 or 11 (this is usually the biggest chunk of work)
- Recreate the theme in Twig (PHPTemplate themes must be converted)
- Configure views, blocks, and layout
- Set up caching (Redis, Varnish, CDN)
Phase 4: Migrate content (1 to 3 weeks)
- Use Drupal's Migrate module to pull content from the old database
- Map fields explicitly, including custom field formatters
- Migrate files with their paths preserved so existing references still resolve
- Migrate users with their roles and permissions (but invalidate passwords for security)
- Migrate URL aliases so your existing links do not break
- Generate redirect rules for any URLs that must change
- Run the migration repeatedly until the output matches the source
Phase 5: QA and testing (1 to 2 weeks)
- Compare page-by-page content on staging vs. production
- Test every form, including webforms, contact forms, and search
- Test authentication: login, password reset, social login if applicable
- Test editorial workflows: create, edit, publish, unpublish, revise
- Test integrations: API calls in both directions
- Performance test: Lighthouse, WebPageTest, real traffic simulation
- Accessibility test: WCAG 2.1 AA at minimum
- SEO test: verify that meta tags, structured data, and redirects are correct
Phase 6: Cutover (1 day)
- Lock content changes on production 24 hours before cutover
- Run a final content sync from production to staging
- Point DNS to the new site with a short TTL pre-set
- Verify the new site is serving at the old URLs
- Smoke test the top 20 pages, plus forms, login, and search
- Leave the old site accessible at a backup URL for 30 days in case you need to reference it
Phase 7: Post-launch (2 weeks)
- Monitor Google Search Console for crawl errors
- Monitor your analytics for traffic drops that would indicate a redirect problem
- Monitor uptime and error logs aggressively for the first 72 hours
- Resolve any issues surfacing from real users
- Run a final security audit: fail2ban, firewall, file permissions, user cleanup
Common mistakes to avoid
- Underestimating custom module work. This is where most migrations go over budget. Every custom D7 module needs a D10/11 port, and the port is not always straightforward.
- Not preserving URLs. URL changes destroy SEO ranking overnight. Preserve the top 200 URLs at all costs, and use redirects for anything that must change.
- Skipping staging validation. Every client who has tried to migrate directly to production has regretted it. Staging is not optional.
- Forgetting about cron and queue. D7 sites often have cron tasks or queue workers that are invisible until they stop running. Document them during audit.
- Not planning rollback. If the cutover fails at 2am, you need a written plan that any engineer on your team can execute.
How long will this take, honestly?
- Small site (under 500 pages, minimal customization): 4 to 6 weeks
- Mid-size site (1,000 to 5,000 pages, some custom modules): 8 to 14 weeks
- Complex site (5,000+ pages, many custom modules, heavy integrations): 12 to 24 weeks
Our typical D7 to D10/11 migration engagement at WebEvra runs 6 to 10 weeks for mid-size sites, with fixed-scope pricing starting at $8,000.
Ready to start?
If your Drupal 7 site needs to migrate (it does), book a free migration audit. We will review your site, give you an honest scope, and a fixed-price quote in USD. No surprises, no mid-project scope creep.
Not sure whether to go with Drupal or consider WordPress? Read our Drupal vs WordPress comparison first.
Planning to budget for the migration? Our Drupal development cost breakdown has the real numbers.
