Webflow's code export gives you HTML, CSS, JavaScript and static assets. Everything that made the site work stays behind: CMS content, forms, site search, ecommerce, memberships, localized pages.
If you are scoping a Webflow migration, that gap is the estimate. Not the page count, not the design. I have run this both ways, into Webflow and out of it, and the projects that go badly are the ones quoted as "export, then upload".
Here is the actual perimeter, the two traps that cost the most, and the parts worth automating.
There is a longer, less code-heavy version of this for the people who sign the invoice: Webflow migration in 2026.
| Element | After code export | |---|---| | HTML, CSS, JavaScript | Exported, working | | Images and static assets | Exported | | CMS collection content | Not included. Collection lists render empty, template pages generate nothing | | Forms | Exported visually, they stop submitting, the backend was Webflow's | | Site search | Dead, it relied on Webflow-side indexing | | Ecommerce | Dead, catalog, cart and checkout are platform features | | Memberships / user accounts | Not included | | Localized pages | Not included |
CMS content exports separately: one CSV per collection, from the export icon in the collection panel, one collection at a time.
Open an exported CSV and look at an image field. It does not contain a file. It contains a URL pointing at your source project's asset hosting.
This is the failure mode that makes a migration look successful for months. The new site renders fine, every image loads, because it is still loading from the old Webflow project. The day the subscription is cancelled and the project is deleted, every image on the new site breaks at once. Webflow's own docs recommend keeping the original project alive as a backup, which tells you how common this is.
Run it against every collection CSV plus the exported HTML. Then diff the count of matched URLs against the files on disk: anything in the MISS column is an asset you were about to lose.
Reference and multi-reference fields, the links between collections, export as text. The relationships do not survive. You rebuild them at the destination.
Do it in two passes, because you cannot link to a document that does not exist yet:
Same shape whatever the destination CMS is. The part worth budgeting is not the script, it is deciding what the relations should be when the source model does not map cleanly onto the target one.
One-to-one, old URL to the equivalent new page. Not a blanket redirect to the homepage, that single decision destroys more organic traffic than every other migration mistake combined.
Build the inventory from two sources, not one: a crawl of the site, plus the page export from Search Console. The crawl misses URLs that receive traffic but are linked from nowhere.
That is fine up to a few hundred entries. Past that, next.config redirects get evaluated on every request and the config becomes unpleasant, move the map into middleware backed by a KV or edge-config lookup, and keep the JSON file as the source of truth in git either way.
Parity checklist before you flip DNS URL inventory from crawl + Search Console, not just the sitemap. 301 map, one to one. Every old URL resolves to its equivalent, verified with a script that follows redirects and asserts a 200 at the end. On-page parity. Titles, meta descriptions, H1s and structured data move across unchanged. If you want to rewrite them, do it afterwards as a separate, measurable change, otherwise you cannot tell a bad redirect map from a bad title rewrite. Performance parity. Measure LCP and INP before and after. A migration that ships a slower site is a paid downgrade. New sitemap submitted, main pages requested for crawl. 90 days of monitoring, query by query. A dip in the first weeks is normal. A dip that has not recovered after a month has a cause, and it is almost always the redirect map.
Google's site move with URL changes guide is the document to validate the plan against before executing it, not after.
Webflow repriced in May 2026: the CMS and Business plans were replaced by a single Premium plan at $25/month billed annually, with 20,000 CMS items but 50 GB of bandwidth, down from the 100 GB the old Business plan included. Existing sites move over at their first renewal from 29 June 2026.