WordPress to Webflow

Migrate from WordPress to Webflow

WordPress migrations are rarely just content moves. The site usually carries years of plugins, theme decisions and small workarounds. I rebuild what has to be rebuilt, carry across the content and CMS structure that should move, and map every changing URL so the move does not throw away what the old addresses had already earned.

Start a project

A migration like this usually takes 3–4 weeks

Why people move

What changes when you move from WordPress to Webflow.

What is being compared	WordPress	Webflow
Where the features come from	WordPress Plugins, and the ones you chose years ago	Webflow Built in, or a deliberate integration More plugins is not always worse. If four of yours are doing real work, four integrations is what replaces them.
Content model	WordPress Post types and custom fields, often via a plugin	Webflow CMS collections with references, native
Who maintains it	WordPress You: core, plugins, PHP versions, security	Webflow Webflow, for the platform itself
Themes and the design layer	WordPress A theme, a custom build, or a page builder layered on one	Webflow Layout built directly, no theme underneath
Publishing at volume	WordPress Multiple authors, scheduling, revisions, editorial states	Webflow Capable, not specialized WordPress genuinely wins this. Whether it is decisive depends on the editorial workflow the team actually runs rather than on the volume alone.
Extending it	WordPress Anything, if somebody writes PHP	Webflow Anything Webflow renders, plus code that runs elsewhere The honest trade of the whole move.
Hosting cost	WordPress Cheaper on paper	Webflow A site plan, with the maintenance included Compare total cost, not the hosting line.

WordPress genuinely wins some of these rows. If the site depends on high-volume publishing, WooCommerce, memberships or WordPress-specific functionality, the audit can end with a recommendation not to move it, or with Webflow taking the marketing pages while another platform keeps running the store or the member area.

Once you have decided

What actually migrates.

What you have	What happens	Why
Pages	Rebuild	Theme markup and page-builder output do not transfer. The design carries; the implementation does not.
Posts and custom post types	Move	Exports as structured data and lands in collections once the model exists. ACF and similar fields usually extract too, and how cleanly depends on the field types and where the plugin stored them, which is worth testing before committing to XML or the REST API.
Media	Move	Files are rehosted and the references inside post content rewritten to match.
Plugins	Rebuild	Each one becomes a native feature, an integration, a line of custom code or a deliberate removal. That review is its own line in the quote.
URLs and SEO metadata	Reconfigure	Every address that changes gets a rule pointing at its replacement, and the titles and descriptions sitting in postmeta are pulled deliberately rather than regenerated by a site that never knew the old ones.
WooCommerce and memberships	Depends	The biggest single factor, and usually better left in systems built to run them, with Webflow in front.

Before you budget it

Where this migration gets complicated.

01

A custom post type has no destination waiting for it

A post and a page map onto shapes Webflow already has. A custom post type is a shape somebody defined in PHP, so the content can come across and there is nothing on the other side to put it in yet. The collection and its fields get designed first, and that design is the work rather than the import.
02

The URL archive is larger than the site

Category archives, tag archives, author pages, pagination and whatever permalink structure preceded the current one are all live addresses that nothing in the navigation points at. On the ProductPlan migration that came to 773 redirects against a site nobody would have called large.

How it runs

How the migration works.

01

Plan

What WordPress will actually hand over, what has to be rebuilt, and what each thing becomes: a page, a collection, a field, or nothing.
02

Build

Templates built in the Designer, against the model rather than against the old pages.
03

Migrate

Content in, assets rehosted and checked against the source, and every address that changes given a rule pointing straight at its replacement.
04

Launch

Forms at the record, every template at three widths and every old address requested, all before anything is switched. Then typically 3–4 weeks from start to live, and a week of watching what the old addresses return.

What you are buying

What is included.

Design rebuild

Rebuilt directly against the existing site.
Responsive development

Desktop, tablet and mobile, built and checked.
CMS architecture

Collections and fields mapped before build.
Content migration

Migrated and checked against the source.
Asset migration

Collected, compressed and rehosted.
Forms and integrations

Tested through to the final record.
Redirects

Changed URLs mapped directly to replacements.
Metadata and canonicals

Preserved wherever possible.
Search footprint preservation

URLs inventoried before and checked after.
Pre-launch QA

Forms, templates and old URLs verified.
Post-launch support

One week of indexing and traffic checks included.

Search visibility can move during a migration. The goal is to preserve what search engines already understand, and to catch what changed quickly after launch.

Other migrations

Coming from somewhere else?

Reach out and see if we are a good fit.

Start a project

Currently booking two to four weeks out.