What breaks when you leave Drupal, and when you should not
The content model maps more cleanly than people expect. The editorial workflow around it has no equivalent at all, and for some organisations that is a reason to stay.
Drupal migrations are usually driven by cost of ownership rather than by anything being wrong with the site. Drupal is built for developers and it expects continuous technical investment: security updates, module compatibility, and somebody on hand who understands it. Organisations leaving are nearly 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 publish.
The content model maps, mostly
Drupal organises content as node types with fields and taxonomies. 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 from the outside.
Where it strains is depth. Webflow's reference model is shallower than Drupal's, so deep taxonomy hierarchies and heavily interlinked reference structures have to be simplified rather than copied across. That simplification is a content decision with editorial consequences, and it belongs in the audit rather than in the build.
The workflow layer is what you actually lose
Drupal's editorial machinery has no direct counterpart, and it is worth being blunt about the scale of that. Content moderation states. Multi-stage approval. Revision histories with rollback. Permissions granular enough to give one editor access to one field on one content type. These are not harder in Webflow. They are absent.
So the useful question is why the workflow exists. If it exists because a compliance process requires a named approver before anything is published, that is a genuine blocker and it has to be solved before a migration is agreed, not discovered during user acceptance testing. If it exists because somebody enabled it in 2014 and nobody has switched it off, most teams do not miss it and several are relieved.
When you should stay on Drupal
Not every Drupal site should move, and an agency that never says so is not worth listening to on the question. The cases where staying is right are reasonably clear.
- A regulated approval chain that has to be evidenced. If an auditor needs to see who approved what and when, you need the revision history, and rebuilding that on top of a hosted CMS costs more than the maintenance you were trying to escape.
- Very large or deeply relational content. Webflow's CMS has hard ceilings, and a catalogue that is comfortable in Drupal can be structurally impossible in a collection.
- Dozens of editors with genuinely different permissions. Webflow's roles are coarse by comparison, and the workaround is process rather than software.
- An application rather than a website. If Drupal is running membership logic, complex forms or integrations that are the product, you are migrating software, not content.
The Drupal sites that migrate well are the ones where Drupal was the wrong tool from the start. The ones that migrate badly are the ones where it was the right tool and the team simply got tired.
Being tired is a legitimate reason to look, and it is not on its own a reason to move. The honest audit answers whether the maintenance burden comes from Drupal being Drupal, which a migration fixes, or from the site genuinely doing something complicated, which a migration relocates. The route, if it is the right call, is on the Drupal to Webflow migration page.
