Drupal → Next.js · Updated
Drupal to Next.js Migration
A Drupal to Next.js migration exports nodes, taxonomies and files out of Drupal, remodels them as structured content in a headless CMS, and serves them through a Next.js frontend. For Drupal 7 sites the move is overdue: Drupal documents that its end of life was January 5, 2025 and the security team no longer issues advisories for it.
Who this migration is for
- Drupal 7 sites that missed the upgrade window and now run without security support.
- Organizations with large structured content (many content types, taxonomies, references) that would map well to a modern headless model.
- Public-sector and association sites that need accessibility, performance and a maintainable editing workflow.
What Drupal lets you export
Taken from the vendor’s own documentation, linked below. We do not promise an export the platform does not provide.
Documented export
- Drupal content is structured by design: nodes, fields, taxonomy terms and file references can be exported through Drupal’s APIs or directly from the database, which makes mapping to a headless content model straightforward.
Not exported or stops working
- Themes, Views configuration and module behavior do not transfer; they are rebuilt as components and queries in the new stack.
- Per Drupal.org, after January 5, 2025 "The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core", so staying put is a risk rather than an option.
Source: Drupal.org PSA-2023-06-07, Drupal 7 end of life. Accessed October 2026.
What we rebuild rather than import
- Content types become CMS document types; taxonomies become reference fields so relationships survive the move.
- Views and listing pages are rebuilt as queries against the new content model.
- Design and templates. A migration is a rebuild of the presentation layer; we do not try to convert a theme or builder output into React.
- Forms, lead routing and spam protection, wired to your CRM or inbox and tested end to end.
- Structured data: one Organization node, Service and FAQ markup that mirrors the visible page, validated before launch.
- Analytics, consent and conversion events, so the first month after cutover is measurable.
Want to know what your Drupal site would keep?
The free audit inventories your URLs and traffic and tells you what a migration would have to preserve.
How rankings are preserved
Drupal-specific notes first, then the eight steps every migration follows.
- Drupal path aliases and /node/ID URLs are both inventoried; aliases are preserved and node IDs are redirected to them.
- Taxonomy term pages that earn traffic are recreated as hub pages; the rest are redirected.
- Files under /sites/default/files are migrated and their URLs redirected or preserved.
- 1
Inventory every URL that exists and every URL that earns
Crawl the live site, pull the sitemap, and export the Search Console Pages and Performance reports. The union is the redirect map input; the Performance rows decide what must be preserved exactly.
- 2
Decide the new URL structure before building
Keep paths where they are sane. Change them only where the old structure was a liability, and record the change in a one-to-one map. No wildcard redirects to the homepage.
- 3
Carry metadata field by field
Titles, descriptions, canonicals, Open Graph and existing structured data are exported with the content and loaded into the new pages, then diffed against the live site.
- 4
Rebuild structured data from one identity
One Organization node with the real address, phone and founder; Service, Article and FAQ markup that mirrors the visible page; validated before launch.
- 5
Preserve internal links and images
In-body links are rewritten to the new paths rather than left to bounce through redirects. Images are self-hosted so nothing depends on the old platform staying up.
- 6
Test the redirect map against the inventory
Every old URL is requested and must return one 301 to a 200 page. Chains, loops and 404s fail the launch.
- 7
Cut over and submit
DNS switch, new sitemap submitted, IndexNow ping, and a full crawl of the new site within the first day.
- 8
Monitor index coverage for a month
Indexed versus submitted, crawl errors, redirect-reported URLs and the top earning queries are checked weekly. A migration is done when coverage matches or beats the old site, not when the new one is live.
Why coverage is the finish line: our index coverage research. How AI agents read the result: which AI crawlers visit your site.
Why businesses make this move
- Security support ended for Drupal 7, and a Drupal 10 upgrade is itself a rebuild of theme and modules; moving to a headless stack costs similar effort and ends the upgrade cycle.
- Server-rendered HTML. Search engines and the search-type AI agents read the page as delivered, not after a browser runs scripts.
- No plugin or app layer to patch, which removes a class of security and performance regressions.
- Content modeled as data, so the same facts feed pages, schema and llms.txt without drifting apart.
How the engagement runs
| Phase | What happens |
|---|---|
| Discovery | Goals, constraints, what the current platform does well, what it blocks. Access to analytics, Search Console and the admin. |
| Inventory | URL list, content audit, export of everything the platform allows, capture of everything it does not. |
| Content model and design | Document types and fields, page templates, components. Approval before build. |
| Build | Next.js frontend, CMS setup, content load, forms, schema, analytics and consent. |
| Redirect map and QA | Old to new URL map, automated redirect test, page-by-page content diff, accessibility and performance checks. |
| Cutover | DNS switch, sitemap and IndexNow submission, first crawl, old platform kept read-only until coverage is confirmed. |
| Monitoring | Weekly index coverage, crawl errors and query checks for a month; fixes shipped as found. |
Common questions
Should I upgrade to Drupal 10 instead?
Drupal recommends migrating Drupal 7 sites to a supported version. An upgrade is a rebuild of theme and custom modules on the Drupal side. If your team is committed to Drupal that is a valid path; if the site is primarily content, a headless CMS and Next.js ends the upgrade treadmill for similar effort.
How is Drupal content exported?
Through Drupal APIs or a direct database export of nodes, fields, taxonomy and file references. Because Drupal content is already structured, mapping it to a headless content model is mostly a field-by-field exercise.
Will /node/123 URLs break?
No. Both the node ID paths and the path aliases are inventoried and redirected to the new URLs with one 301 each.
Can accessibility requirements be met on Next.js?
Yes. Accessibility is a property of the markup and the components, not the CMS. The rebuild is audited against WCAG before launch.
Related
Other migration paths
Planning a Drupal move?
Tell us the page count and what the site has to keep doing. We will come back with what can be exported, what has to be rebuilt, and a dated plan.
Book a Free Call