Drupal to Next.js: what moves, what breaks, what it takes.

What transfers from Drupal to Next.js, and what does not?

Your content model survives only if you keep Drupal behind the new front end. The same rule applies to your permissions and your editors' habits. Your Twig templates and theme do not transfer either way, so do not plan on carrying the old presentation with you. In a decoupled setup, your pages pull from the JSON:API module, standard across decoupled Drupal applications, and you rebuild only the presentation layer. But if you retire Drupal, you redesign the model on the target instead.

Check your assumptions before building. Start with the hidden pieces. You cannot query your site name, slogan, front page, logo, or favicon over JSON:API because they live in simple config, so you rebuild those manually. Those details are not edge cases, and they are the ones that get forgotten. Your inline images and view-embed tokens break like WordPress shortcodes, so you audit every instance before cutover. Paragraphs and entity reference fields map closer to headless models than WordPress structures do, which gives you an early start on the schema.

How do you plan the URL map and redirects so your search traffic survives?

You map your URLs before you write code: export every live URL and path alias, then pair each one with a single new address. Do that first. Drupal's Redirect module assigns one canonical URL per piece of content and points other aliases there with a 301, so your existing redirects belong in your inventory from the start. Existing aliases are part of the map, and treating them as post-launch cleanup is how traffic quietly leaks. If your site routes multiple aliases to one node, you decide which one survives.

On the new host, you configure server-side 301 or 308 redirects without chains. Then clean up. Update your internal links, publish a new sitemap, point your canonical tags to the new URLs, and clear any temporary noindex rules. Canonical tags must name the new addresses, not the old ones. And if you rely solely on rel=canonical, remember Google treats it as a hint, not an instruction. Use the URL Inspection Tool to test your redirects, or write a script if you manage thousands. For your large site, migrate in sections, monitor your traffic on both origins, and check your 404 reports for URLs you missed. Keep your redirects live for at least a year.

How is content moved from Drupal: export, API or crawl?

You extract content from Drupal through API requests. Database exports and page scrapes are the other paths. Use the cleanest source when you can. The API provides that source because your content is already structured. With JSON:API enabled, you request a path like /jsonapi/node/article and receive your articles as typed JSON with references intact. A raw export produces flat files you must reshape. A crawl captures only what your rendered pages show, so treat it as a fallback for orphaned pages (and nothing more).

You still map the data manually first. No shortcut here. Schema translation requires your attention before any script runs. Reference modeling and locale rules do too. Run your automated import last, not first. After that, your target system ingests records through its import tool or write API. If you keep Drupal as the backend, you skip the import, and your front end queries the same API live.

Your media needs its own pass: files, alt text and PDFs move separately, and your editors should spot-check a sample of each content type afterward.

What do your editors get on Next.js compared with Drupal?

Your editors get preview screens and on-demand publishing only if you build them, because your Next.js front end drops Drupal's theme layer. Drupal no longer does that work for the new front end. In the decoupled route, your editors keep the Drupal admin they know, and you wire up Draft mode so they can open a node page and preview unpublished drafts and revisions. The preview button can also work before the first save.

You configure what refreshes. Be exact. With the tags plugin, your Drupal site pushes cache tags to your Next.js revalidation endpoint, and that endpoint invalidates the related data. That only covers what you connect. If your front page lists articles, you must add its path to the article revalidation settings manually. So verify every listing page you run (the stale ones are always the ones nobody checked).

If you move to a headless CMS instead, your editors learn a new hosted interface. That is the trade. Sanity Visual Editing gives them a click-to-edit jump from your site preview into the Studio, on all plans. Behind that, you leave Drupal's modules behind, and you rebuild your permissions rather than carry them over.

How long does a Drupal to Next.js migration take, and what drives the effort?

Your timeline depends on five drivers you can count today. Start with your URL count and your content types. Count your media assets next. Add your integrations and your locales. On the heavy end, one published benchmark places typical enterprise Drupal to Contentful migrations at 12 to 22 weeks with moderate risk. That window covers model redesign and import, plus a full front-end rebuild. Localization, workflow setup, and editor training sit in that same window. Your site may sit well below that, so size it from your own counts, not from someone else's average.

Keeping Drupal cuts your content migration time. But you still run two systems. That means a Drupal host and a Next.js host for your team to patch and monitor. Replacing Drupal adds your content migration and ends your Drupal hosting footprint.

I plan and run migrations like this one, taking legacy setups and WordPress estates to Astro or Next.js. Counts come first. Your locale count and your integration list tell me more at the start than your page count does, so I look there before I look at volume.

When should you not move from Drupal to Next.js?

You should not move if your Drupal site is healthy. If your editors work well in it and your search traffic is stable, a migration puts all three at risk. Stay where you are when the free assessment rates your site in good standing, 80 to 100, and your weak points, such as HTTP headers, caching, schema output, or image weight, can be fixed inside Drupal. That is a fix-in-place case, and calling it a migration case would be selling you work you don't need.

Stay if you cannot afford to run two systems, since a decoupled build leaves you with Drupal plus a separate front end. Cost counts. Hold off if your only reason is fashion. A move pays when you need an application. And it pays when you need personalization or many editors working in a structured model.

You choose by fit. Keep it that simple. Astro suits you if your site is content or marketing pages. For an application, personalization, or many editors, Next.js with Sanity or Contentful suits you. Astro drops your editors' visual canvas, and a headless CMS swaps your modules and self-run admin for a managed dashboard.

Questions, answered.

Your next read.

1. 01Drupal alternativesUpgrade, decouple or move, judged by your pages.
2. 02Drupal to WordPressWhen simpler is right, and what the content model loses.
3. 03Next.js SEO auditRendering mode, metadata, hydration cost.
4. 04Headless CMS SEO auditRendering, canonicals, previews, schema from the template.