Migrating off Webflow: what actually exports, and what you rebuild

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.

What the export contains

CMS content exports separately: one CSV per collection, from the export icon in the collection panel, one collection at a time.

Trap 1: your images are still on Webflow's CDN

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.

Mirror the assets before you cancel anything:

// mirror-assets.mjs, node >=18, run once per exported CSV
import { readFileSync, mkdirSync, createWriteStream } from "node:fs";
import { Readable } from "node:stream";
import { pipeline } from "node:stream/promises";
import path from "node:path";

const csv = readFileSync(process.argv[2], "utf8");
const urls = new Set(
 csv.match(/https?:\/\/[\w.-]*(?:website-files\.com|webflow\.com)\/[^\s",]+/g)?? []
);

mkdirSync("assets", { recursive: true });

for (const url of urls) {
 const res = await fetch(url);
 if (!res.ok) {
 console.warn("MISS", res.status, url);
 continue;
 }
 const name = decodeURIComponent(path.basename(new URL(url).pathname));
 await pipeline(Readable.fromWeb(res.body), createWriteStream(path.join("assets", name)));
 console.log("OK", name);
}

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.

Trap 2: reference fields come out as plain text

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:

// pass 1, create every item, no relations
const idBySlug = new Map();
for (const row of rows) {
 const doc = await payload.create({
 collection: "articles",
 data: { title: row. Name, slug: row. Slug, body: row["Post Body"] },
 });
 idBySlug.set(row. Slug, doc.id);
}

// pass 2, now every target exists, patch the relations
for (const row of rows) {
 const related = (row["Related articles"]?? "")
 .split(";")
 .map((s) => idBySlug.get(s.trim()))
 .filter(Boolean);
 if (!related.length) continue;
 await payload.update({ collection: "articles", id: idBySlug.get(row. Slug), data: { related } });
}

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.

Redirects are where the traffic actually goes

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.

// next.config.mjs
import redirects from "./redirects.json" with { type: "json" };

export default {
 async redirects() {
 return redirects.map(({ from, to }) => ({
 source: from,
 destination: to,
 permanent: true, // 301
 }));
 },
};

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

1. URL inventory from crawl + Search Console, not just the sitemap.
2. 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.
3. 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.
4. Performance parity. Measure LCP and INP before and after. A migration that ships a slower site is a paid downgrade.
5. New sitemap submitted, main pages requested for crawl.
6. 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.

When not to migrate

Plenty of the time the right answer is to stay.

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.

If that is the whole reason you are considering a move, run the numbers first. You are talking about a few hundred dollars a year, including extra bandwidth packages. A migration costs many multiples of that. Compress your images, move heavy video to an external player, delete the collections nobody uses, and the bandwidth overage usually disappears.

Migrate when the limit is structural: real-time integration with an ERP or CRM, business logic that needs a server, memberships with non-trivial permissions, a catalog past the CMS item ceiling, or because owning the code and the data is a strategic decision rather than a technical one.

One more thing, since it is the cheapest advice in this post: if the site is more than three or four years old, migrating it pixel-for-pixel is a waste. You are paying for the most tedious work there is, replicating something dated, to end up with the same site on different infrastructure. During a migration the marginal cost of rethinking it is at its lowest, because everything is being rebuilt anyway.

I'm Enrico, CPO at WMIE. We build on Next.js and Payload, and we are also a Webflow partner, which mostly means we get called when someone needs an honest answer about which side of the migration they belong on. Some of the work is here.