Drupal to Webflow migration

Drupal migrations are usually driven by cost of ownership rather than by anything wrong with the site. Drupal is built for developers and demands continuous technical investment: security updates, module compatibility, a person who understands it. Organisations leaving it are almost always making the same trade, which is less customisation depth in exchange for much less operational overhead and much more autonomy for the people who actually publish.

The content model maps, mostly

Drupal organises content as node types with fields and taxonomies, and Webflow organises it as collections with fields and references. The translation is direct enough that most of a Drupal content model has an obvious Webflow equivalent, which makes these migrations more predictable than they look. Where it strains is deep taxonomy hierarchies and heavily interlinked reference structures, because Webflow's reference model is shallower and those relationships have to be simplified rather than copied.

The workflow layer is what you actually lose

Drupal's editorial machinery has no direct counterpart: content moderation states, multi-stage approval, revision histories with rollback, and permissions granular enough to give one editor access to one field on one content type. If those exist because a compliance process requires them, that is a genuine blocker and it needs solving before a migration is agreed rather than discovered during user acceptance testing. If they exist because somebody enabled them in 2014, most teams do not miss them.

When we would tell you not to

A large-scale publishing operation with thousands of items across many content types, several concurrent editors and a real approval process is a case Drupal handles better than Webflow, and moving it would be a downgrade dressed as a modernisation. The migrations that work are marketing and communications sites carrying Drupal because of a decision made a decade ago, where the platform's strengths are no longer being used and its costs still are.

• Node types and taxonomies mapped to collections before anything is built
• An explicit decision on every workflow feature currently in use
• Reference structures simplified deliberately rather than by accident
• Redirect map from a crawl, since path aliases vary widely
• An honest recommendation to stay, where staying is the right answer

What a build here actually includes

Every build is scoped to the practice, but on this kind of site these are the parts that are not optional.

• Content model audit mapping node types and taxonomies to collections
• A named decision for every moderation and permission feature in use
• Reference relationships simplified with the trade-offs stated
• Redirect map built from a crawl of real path aliases
• A stay-or-go recommendation made before the project is agreed

What we keep seeing go wrong

None of these are hypothetical. They are the things that turn up again and again on sites in this vertical, and most of them are cheap to avoid and expensive to undo.

• Migrating a genuine publishing platform because the word Drupal sounds dated
• Discovering the approval workflow requirement during user testing
• Copying a deep taxonomy into a model that cannot hold it
• Assuming path aliases follow a pattern that can be handled with wildcards
• Treating the maintenance saving as the whole business case without pricing the loss

Questions we get asked first

Will our content model survive the move?

Mostly. Node types map to collections and taxonomies map to reference fields, and that translation is more direct than people expect. Where it strains is deep hierarchies and heavily interlinked references, because Webflow's reference model is shallower. Those get simplified, and the simplification should be a decision you agree to rather than something discovered in the build.

What about our editorial workflow?

This is the honest gap. Drupal's moderation states, multi-stage approval and field-level permissions have no direct equivalent. If a compliance process depends on them, that is a blocker to solve before agreeing the project. If they were enabled years ago and nobody uses them, most teams find they do not miss them.

Should we migrate at all?

Sometimes not, and we would rather say so early. If you are running a large publishing operation with many content types, concurrent editors and a real approval chain, Drupal handles that better than Webflow does. The migrations that work well are marketing sites carrying Drupal because of an old decision, paying for capability they no longer use.

How much maintenance does this actually save?

The recurring work that disappears is module updates, security patching, PHP version compatibility and the developer time those consume. What replaces it is a hosting subscription and a platform you do not patch. That is a real saving for most organisations and it is not the whole business case, so it is worth pricing the loss as well as the gain.