Gemin
Get in touch

Drupal to Webflow

Migrate from Drupal to Webflow

Drupal is powerful, but many marketing sites no longer need that much machinery. I preserve the useful structure and retire the parts that make every change expensive.

Start a project

A migration like this usually takes 4–5 weeks

What the migration covers

What moves, and what we figure out first.

What moves

  • Content types mapped to Webflow CMS collections
  • Taxonomies and relationships as references or fields
  • Files and media, exported and optimized
  • URL aliases, redirects, metadata and crawl checks

What we figure out first

  • Views are logic, not just pages. Each Drupal View becomes a Webflow collection list, collection page, custom build or simpler editorial pattern.
  • Large Views need a new rendering strategy. A View can represent a filtered set larger than one collection list will render in a single pass. Pagination, filtering, search or a pattern that is not a list at all replaces what Drupal was generating, and which one gets decided up front.
  • Multilingual content needs Localize planning. Drupal’s multilingual model and Webflow Localize need a field, locale and URL mapping before content moves.
  • Roles and gated areas need replacements. Drupal permissions do not migrate into Webflow as-is.

Drupal migrations start with the content model, not the homepage. Content types, taxonomy, Views and modules can encode years of decisions, so I work out which of them the marketing site still needs before rebuilding anything in Webflow.

Why people move

What changes when you move from Drupal to Webflow.

What is being compared Drupal Webflow
Content modeling Drupal As deep as you like, and often deeper than needed Webflow Collections and references, with real limits Drupal wins this outright. If your model genuinely needs it, that is a reason to stay.
Permissions and workflow Drupal Granular roles, editorial workflow, moderation states Webflow Editor access, scoped per collection Also Drupal's. A site with a five-stage approval chain is not a Webflow site.
Who maintains it Drupal You: core, modules, PHP, security advisories Webflow Webflow
Design changes Drupal A developer and a theme layer Webflow Anyone on the marketing team
Publishing a landing page Drupal A ticket Webflow An afternoon

What actually changes

Webflow takes the marketing jobs. The rest needs somewhere else to live.

Now

One Drupal site

  • Content types and fields
  • Taxonomy
  • Views
  • Roles and permissions
  • Editorial workflow
  • Contributed modules

After

Webflow

  • Collections, flattened where a reference went too deep
  • Reference fields, or collections of their own
  • Collection lists, filtered and sorted

Somewhere else, or nowhere

  • Roles and permissions, if they are real
  • Editorial workflow, which has no equivalent
  • Whatever the modules were doing
Webflow comfortably takes the marketing layer. Permissions, editorial workflow and module-driven behavior either need another home or become reasons not to migrate.

Once you have decided

What actually migrates.

What you have What happens Why
Pages Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. Twig templates and the theme layer do not transfer.
Content types and nodes Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. Exportable with effort, usually through Views or a migration module, and they move after the Webflow model they are moving into has been decided.
Taxonomy Depends Not answerable in general. Which one it is turns on your plan, your export or a decision nobody has made yet. A simple vocabulary becomes a field or a collection. A deep or heavily reused one gets remodelled around the relationships the new templates actually render, which is a deliberate simplification rather than a flattening.
Media Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. Files are rehosted and the references inside body fields rewritten to match.
Users, workflow and permissions Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. These do not become ordinary Webflow CMS features. Anything load-bearing is scoped as its own piece of work, or it is the reason to stay.
Modules and custom behavior Depends Not answerable in general. Which one it is turns on your plan, your export or a decision nobody has made yet. Each one becomes an integration, an external service, a custom implementation or a deliberate removal. That review is its own line in the quote.

Before you budget it

Where this migration gets complicated.

  1. 01

    Drupal models relationships more deeply than a marketing site renders

    Drupal can model deeply connected entities that do not map cleanly into a simpler marketing CMS. Some relationships become references, others get flattened or intentionally duplicated around what the Webflow templates actually need to render.

  2. 02

    Taxonomy terms are usually doing more than tagging

    On a mature Drupal site terms drive menus, access and generated pages as well as categorisation. Mapping them to a Webflow reference field carries the label and drops every behavior attached to it.

  3. 03

    Editorial workflow has no equivalent

    Draft, review, approve and scheduled publishing with roles attached is a thing Drupal does well and Webflow does not do at all. If the workflow is load-bearing, that is an argument against the migration rather than a task in it.

  4. 04

    Multilingual is an architecture decision, not a field

    Drupal's translation model and Webflow Localize disagree about what a translation is. Locale, field and URL mapping all get decided before content moves, and the answer changes what the build costs.

The part quotes leave out

How I move it without losing the search footprint.

  1. The search footprint is inventoried before anything moves

    A crawl shows what the current Drupal site links to now. Analytics and Search Console show which addresses people and search engines are still reaching, including ones nothing on the site points at any more, so the list is the union of all three. The traffic, the top pages and the queries earning impressions get written down at the same time: without a baseline, a change in how you count and a change in what you get are the same graph.

  2. What can stay where it is, stays

    Addresses first, then the titles and descriptions attached to them, then the canonicals. Metadata is the easiest thing to lose in a rebuild, because the new site will happily generate something plausible for every page and nothing will report a problem.

  3. Everything that changes gets one rule, not a chain

    A redirect pointing at a redirect still arrives, so nothing looks broken. Each address gets an intentional destination rather than an inherited one: individual rules where the destinations differ, a pattern where a whole route family changes predictably. The new sitemap goes in at cutover carrying the canonical addresses and nothing else.

  4. Every old address is requested after launch and the response recorded

    The whole list, not a sample. Looking for anything returning 404 that should not, anything returning 200 that should have moved, and anything taking more than one hop. Then indexing and traffic by landing page for the week after cutover, which is the window included, and longer by arrangement where the site is large enough to warrant it.

None of this guarantees a ranking, and search results can move during a migration for reasons nobody controls. The goal is to change platforms without unnecessarily changing what search engines already understand about the site, and to notice quickly when something did change. Afterwards I watch indexing, what the old addresses return and traffic by landing page, so normal recrawling can be told apart from an implementation problem.

How it runs

Six stages, and what each one looks like.

Drupal

Other migrations

Coming from somewhere else?

Reach out and see if we are a good fit.

Start a conversation

Currently booking two to four weeks out.