A move that does not turn into a project of its own.
A Drupal migration for industrial manufacturers, engineering firms and technical distributors leaving the platform. The trigger is usually a major version reaching end of support: the upgrade would mean reworking custom modules, content types and templates anyway, so the question stops being whether to rebuild and becomes what to rebuild onto.
We map the node types, fields and taxonomy the current site is built on, assess the custom module debt precisely enough to scope it, move the content with a complete URL map, and verify after launch that product pages, technical documents and market variants resolve where distributors and search engines expect them.
Drupal major versions have historically demanded substantial rework rather than an incremental update, and support windows on older versions close on a published schedule. That combination puts industrial companies on an older release in front of a decision they did not plan for: fund a rebuild to stay where they are, or fund a rebuild that lands somewhere with lower ongoing specialist dependency.
The second factor is quieter. Drupal is capable and well engineered, but the people who can safely change a running industrial Drupal site are a narrower pool than the marketing team assumes, and the one developer who knows the build is a single point of failure. Our WordPress vs Drupal comparison for industrial B2B covers the trade-off in more depth.
An audit of the content model, node types, fields and taxonomy the current site runs on, plus a module inventory separating contributed modules from bespoke code. A recommendation for what to migrate onto, sized to your catalogue, your document library and the capacity of the team who will run it. The migration itself with a complete URL map and a redirect set that ships at cutover. Then reconciliation against the inventory, individual redirect testing, and coverage and crawl monitoring in Search Console through the weeks that follow.
The wider approach is described on our industrial website migration page.
Drupal sites are frequently the best-modelled content in an industrial company. Product families, material grades, applications, market availability and document categories are held as real content types and taxonomy terms with entity references between them, rather than as text buried in a page. A flat export loses all of that, which is the single most common way a Drupal migration goes wrong.
So the mapping is done at the field level: each node type to a target post type, each field to a target field, each vocabulary to a taxonomy, and each entity reference to a relationship the new platform can query. Taxonomy-driven archive URLs, faceted views and menu structures derived from those terms are mapped alongside the nodes, because they carry inbound links and are a common source of post-launch 404s.
Drupal implementations tend to carry more bespoke code than comparable builds on other platforms, because writing a module is the idiomatic way to solve a problem. Over years that accumulates: a product finder, a distributor lookup, a document access layer, an ERP synchronisation job, several small modules written to adjust behaviour someone wanted changed in 2017.
Each of those is assessed rather than reproduced by default. A meaningful share of custom modules exist to work around a Drupal constraint the target platform does not share, in which case a native feature or a maintained plugin does the same job with less to own. We mark each module as replicate, replace or retire during the technical audit, agree that list with you, and scope development from the agreed list rather than from the full inventory.
The other thing a version jump exposes is the contributed module layer. Community modules are maintained by volunteers, and after a major release some are ported quickly, some are ported with changed behaviour, and some are abandoned with the recommended path being core functionality that works differently or a successor module with a different data model.
That matters because a site can depend on a module for something structural: how documents are permissioned, how a view is faceted, how a language variant is resolved. Part of the audit is checking the status of every contributed module in your build against the target version, so the gaps are known during scoping rather than discovered mid-build. Where a gap exists, the choice between rebuilding on Drupal and migrating gets considerably clearer.
Drupal is the stronger choice for a fair number of industrial sites, and we would say so rather than quote for a move. If your content model is complex enough that entity references, revisions and granular field-level permissions are doing real work, Drupal handles that natively and a lighter platform would need building up to match it. If you run a multi-site estate under one codebase with shared configuration management, or if the site is a genuine application with workflow and role logic rather than a marketing platform, the fit is good.
The strongest reason to stay is an internal team. Where you already employ or retain Drupal capability, the version currently in support meets your needs, and the module layer is maintained, a migration solves a problem you do not have. The hiring and maintenance risk we describe above is real, but it is a reason to look, not a reason to move.
Drupal administration, module development and version upgrades are not services we take on, and we would not be the right partner for an organisation planning to stay on the platform. Our part is getting the content off cleanly, including the taxonomy relationships that organise it, so that a product page still knows which documents belong to it and which markets it is available in after the move.
Code Industrial is the industrial B2B practice of Code Barcelona, an agency building corporate websites and digital platforms since 2015. The same strategy, design and engineering team works on every industrial project, from the first scoping session through to life after launch.
The trigger differs by company. A Drupal migration starts from whatever forced the decision, and the scope follows from that.
What comes up when an industrial company moves off Drupal.
Sometimes, and it depends on figures we can only establish by looking. A major version upgrade can involve as much module and template rework as a move, particularly once bespoke modules and a deep taxonomy are in play. We assess your current version, the contributed module layer against the target release, and the content-type complexity first, then compare that rework cost against migrating to a platform with lower ongoing specialist dependency. The audit gives you both numbers.
Through a full content and URL mapping exercise before launch. Every node, path alias, taxonomy archive and faceted view URL is matched to a destination, since Drupal path structures rarely align with the target routing. Server-side 301 redirects ship with the launch, sitemaps are regenerated, canonicals and hreflang are rebuilt, and we monitor coverage and crawl errors in Search Console afterwards. That is the mechanism; no agency can guarantee a ranking outcome.
They are mapped field by field rather than flattened. Each node type goes to a target post type, each field to a target field, each vocabulary to a taxonomy, and each entity reference to a relationship the new platform can query. That is what keeps a product page knowing which documents belong to it, which material grades it uses and which markets it is available in. A flat export loses those relationships, and rebuilding them by hand afterwards is expensive.
Most can, though we reassess each rather than rebuilding it as-is. Many custom modules were written to work around a Drupal constraint the target platform does not share, so a native feature or a maintained plugin often does the same job with less code to own. During the technical audit each module is marked replicate, replace or retire, and the list is agreed with you before development starts, which is also what keeps the scope bounded.
Then it becomes a scoping question rather than a surprise. Community modules are volunteer-maintained, and after a major release some are ported, some change behaviour and some are abandoned. We check the status of every contributed module in your build against the target version during the audit. Where something structural has no maintained successor, the work has to be funded either way, which usually clarifies the choice between upgrading and migrating.
When the platform is doing work you would have to rebuild elsewhere. If entity references, revisions and field-level permissions are load-bearing in your content model, if you run a multi-site estate under one codebase with configuration management, or if the site behaves as an application rather than a marketing platform, Drupal handles that natively. The strongest reason to stay is an internal team: where you hold the capability and the version is supported, a migration solves a problem you do not have.
Drupal migration connects closely with these related technology pages.
A Drupal version approaching end of support, or a build only one developer can safely change. Tell us your current version and module inventory and we will tell you how we would approach the Drupal migration, including where we would advise staying.