An industrial manufacturer rebuilds an 8-language product catalogue as headless Drupal 11 with Next.js

The situation

A manufacturer of industrial valves and fittings sells through distributors in about 30 countries. Its Drupal 7 site was the public product catalogue in eight languages, and distributors used it daily to find datasheets and compare specifications. Product data came from a product information management system (PIM) through a nightly CSV import.

Drupal 7 support had ended, page loads from Asia and South America were slow, and marketing wanted a front end they could change without a Drupal developer. The board approved a rebuild on the condition that no language launched later than the others.

What we found in the assessment

The 2,600 product nodes held 19,000 SKU variants in Field Collections. Translation was inconsistent: five languages used Entity Translation on one node, three languages were separate nodes joined by a custom table. Around 40,000 PDF datasheets sat in a flat files directory.

The PIM import ran on Feeds with hand-written tamper plugins, took six hours, and failed silently on bad rows. Search ran on an Apache Solr 3 server nobody wanted to touch.

The decisions

Drupal 11 as the content and product store, exposed through JSON:API with JSON:API Extras for cleaner field names.
Next.js as the only public front end, statically generated per language with on-demand revalidation triggered by Drupal on save.
Product data would not be migrated from Drupal 7. The PIM was the source of truth and the Drupal 7 data was stale, so products would be imported fresh into Drupal 11. Only editorial content, dealer pages and downloads came across from Drupal 7.
One translation model. Every product became one node with core content translation in all eight languages.
Field Collections became Paragraphs for SKU tables, Solr 3 became Search API with Solr 9, and datasheets became Media entities keyed on the PIM's document identifier.

How the move ran

The PIM import was rebuilt as a Migrate API migration with a migrate_plus JSON source against the PIM's REST endpoint. It runs hourly, is idempotent, logs every skipped row with a reason, and posts a summary to the team's chat. The six-hour nightly job became a twelve-minute hourly one.

Editorial content came from Drupal 7 with standard migrations. Redirects were the largest risk: 21,000 URL aliases across eight languages. We exported them all into the Redirect module and crawled the Drupal 7 sitemap for every language against staging, twice. The final crawl returned 11 misses, all from a language prefix bug that took an hour to fix.

Editors were trained on Drupal only. A preview button in the editing form opens the Next.js draft route for the current translation, so editors never need to understand the front end.

One part of the decoupling was not worth it. We initially decoupled everything, including the news, careers and campaign pages that marketing builds with Layout Builder. Rendering Layout Builder sections through JSON:API meant rebuilding every block type as a React component. After two months and 14 components, marketing still could not add a block type without a front-end developer, the opposite of the goal. We reverted those pages: Drupal renders them with the same design tokens and Next.js rewrites serve them, so visitors see one site. The catalogue, where the gain is real, stays headless. That split should have been decided in the assessment, not in month four.

After launch

Largest Contentful Paint on product pages dropped by more than half, with the biggest gains outside Europe from Cloudflare's edge. All eight languages launched on the same day. Drupal runs in the client's own cloud account, tuned with Redis and Varnish and managed by us, and the Next.js build runs on Cloudflare, which together cost about 30 percent less per month than the old dedicated servers and the Solr box.