Migrating from WordPress to Webflow is not a conversion, it is a rebuild with your content carried across. There is no button, no plugin that does it faithfully, and the projects that go badly are the ones that assumed otherwise. Done deliberately it is a few weeks of well understood work, and the parts that carry risk are almost never the design.
First, be sure the platform is the problem
Most companies leaving WordPress describe the same symptoms: it is slow, it breaks, updates are frightening, and changing anything requires a developer.
Every one of those is usually a symptom of how the site was built rather than of WordPress itself. A multipurpose theme plus a page builder plus twenty plugins produces exactly that experience, and a lean rebuild on the same platform can fix it for less than a migration costs.
Move to Webflow for a real reason: you want design control without a developer, you want a marketing team publishing safely, and you want to stop maintaining infrastructure. Those are good reasons. Comparing the two properly first takes an hour and occasionally saves the whole budget. Know also what you are accepting on the way in, because leaving Webflow later has its own shape.
Inventory before anything else
Export every URL, then attach traffic, conversions, and last updated date to each one. This table is the project.
Give each row a verdict: move, rewrite, merge, or delete. Mature WordPress sites usually carry a long tail of posts nobody has read in years, plus tag and category archives that exist only because WordPress generates them. Moving all of it is expensive and pointless; merging thin overlapping posts into one strong page tends to improve rankings rather than threaten them.
Note the pages that earn traffic and the pages other sites link to. Those are the ones that must survive with their value intact, and the inventory is the same discipline any migration needs.
Model the CMS from your content, not your pages
WordPress sites accumulate structure: custom post types, taxonomies, custom fields, and whatever a plugin invented. Webflow’s CMS is cleaner and shallower, so this is a modelling exercise, not a copy.
List what your content genuinely is: articles, case studies, services, team members, locations. For each, list the fields it needs. Then check the shape against Webflow’s limits before you commit, because collection and item caps are per plan, nesting is shallow, and deep taxonomies do not translate. A WordPress site with three levels of category and multiple custom fields per post will need simplifying, and it is far better to discover that now than in week four.
Content itself moves by CSV import or the API. Expect to clean it. Formatting from a page builder does not survive, shortcodes become literal text, and embedded galleries need rebuilding. Budget real hours for this; it is the step that consistently gets underestimated, and the design cannot be finalised without real content anyway.
Rebuild the design as a system
Do not recreate the old site page by page. Build the class system first: global typography, a spacing scale, colour, then the components that repeat, and only then the pages.
The payoff is that changes stay cheap afterwards, which was probably one of your reasons for moving. Getting from a design file into Webflow properly is its own discipline, and the same rules apply here: responsive behaviour is decided in the browser, semantic heading order is set by hand, and every state that is not the resting state has to be built.
The redirect map decides whether this works
This is where WordPress to Webflow migrations lose traffic, and it is entirely preventable.
WordPress permalinks rarely match what you build in Webflow. Dated URLs, /category/ prefixes,
tag archives, attachment pages, and pagination all need decisions. Every old URL needs a
mapped destination: the closest equivalent page, never a bulk redirect to the homepage, which
gets treated as a soft 404 and loses whatever the page had earned.
Load the redirects in Webflow before launch, then test the entire old URL list against the live site within the hour after cutover. Automate the check; a spreadsheet of nine hundred URLs is a job for a script. Then watch Search Console daily for a fortnight and fix the rows you missed, because the fix window that matters is measured in days.
The things that do not come with you
Plan replacements for each of these before launch, not after.
Forms and their notifications. Anything a plugin was doing: memberships, events, advanced search, multilingual, WooCommerce. Server side redirects living in your old configuration. Email, if it was on the same hosting, which has to keep working through the DNS change. Analytics and tag manager, which need reinstalling and verifying on every template.
And keep the WordPress install running, untouched, for at least a few weeks after cutover. It is your rollback and your reference, and the cutover itself has an order of operations worth following.
A realistic shape
For a thirty to eighty page site: a week to inventory and model, two to three weeks to design and build, a week for content migration and QA, then a launch day and a fortnight of watching. Content volume and how much rewriting you take on drive the timeline far more than page count.
Considering the move and want to know what your site would actually involve? Send the URL and the page count: hello@beconfidency.agency.
If you want the model, the build and the migration owned by one team, that is exactly what our web development service is for.