WordPress to Webflow migration

The content moves in an afternoon. The plugins are the project, and they are the part nobody scopes.

Best for marketing sites on WordPress carrying years of plugins, where maintenance has become the reason to leave.

WordPress migrations are misjudged in a consistent direction: teams price the content move, which is genuinely straightforward, and discover the real work afterwards. Posts, pages and custom post types export to a structured file and import into collections. What does not come with them is every piece of behaviour a plugin was quietly providing, and on a site that has been running for years that is most of what the site does.

Anything that was a plugin becomes a decision

Forms, site search, memberships, multilingual, bookings, reviews, popups, redirects, caching and whatever else was installed years ago and became part of how the business runs: none of it crosses over, because none of it is content. Each one turns into a choice between a Webflow native feature, a third-party embed, or dropping it deliberately. Make that list during the audit rather than the week before launch, because two of them will be load-bearing and one will need a budget nobody scoped.

The redirect map is the migration

WordPress permalink structures are configurable, which means they vary by install and cannot be assumed. A site using the date-based default produces a completely different URL shape from one using post name, and sites that changed the setting midway carry both. Build the map from a full crawl of the live site plus the analytics list of pages that actually receive traffic, and expect fewer clean pattern rules than a platform with a fixed URL scheme would give you.

What we do differently on these

We model the CMS around what the site publishes now rather than replicating what it published in 2018. A page-for-page copy is tempting and it carries every accumulated mistake across: the four category pages nobody reads, the tag archives generating thin duplicates, the service page that was never finished. Deciding which old URLs survive as pages and which survive only as redirects is a content decision, and it is the one that determines whether the new site is actually better or just newer.

  • A full crawl and a plugin inventory before anything is quoted
  • CMS modelled on current publishing, not on the old structure
  • Redirect map built from crawl plus analytics, imported in bulk and tested
  • Metadata carried across per page rather than regenerated
  • A named replacement for every plugin that was doing real work

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.

  • Plugin inventory with a named replacement or a deliberate drop for each
  • Content export and CMS modelling based on what you publish now
  • Redirect map from a crawl, imported in bulk and verified after launch
  • Metadata and Open Graph carried page by page
  • A staged switch, with the old site live until the new one is verified

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.

  • Pricing the content move and discovering the plugins during the build
  • Building the redirect map from the sitemap instead of a crawl
  • Recreating the old structure page for page, mistakes included
  • Changing the URL structure and the platform in the same release
  • Switching off the old site before the redirects have been tested

Questions we get asked first

Will we lose rankings?
Not if the redirect map is complete and the content survives. Most ranking drops after a migration come from skipped steps rather than from the platform change: URLs that were never mapped, metadata regenerated instead of carried across, or a restructure shipped in the same release. Do those properly and the usual outcome is stable rankings and better Core Web Vitals.
How long does it take?
It depends far more on the plugin list and the content volume than on the page count. A marketing site with a blog and three plugins is a short project. A site running memberships, a store and a multilingual layer is three projects that happen to share a domain, and each one needs its own decision before anything is quoted.
Can we keep our forms?
Not the plugin, but the function, yes. Webflow handles forms natively and connects to most systems either directly or through an automation platform. What needs deciding is where submissions go and what happens when that fails, which is the part most migrations leave until somebody notices enquiries stopped arriving.
What about our custom post types?
They map to CMS collections, usually cleanly. The question worth asking during the audit is whether all of them still earn their place. Custom post types accumulate on long-running WordPress sites, and a migration is the cheapest moment to retire the ones nobody has published to in two years.

Construisons le site que votre entreprise mérite.

Envoyez ce que vous avez aujourd'hui et où vous voulez aller. Vous obtenez une réponse claire sur le périmètre, le calendrier et le budget, généralement dans l'heure.

Nous travaillons en Amérique du Nord, en Europe et au Moyen-Orient.