Writing the exit plan before you need it
Most teams find out what leaving a platform costs on the week they have already decided to leave. That is the worst possible time to learn that your CMS images are hosted on the site you are about to delete. The cost of an exit is knowable today, in an afternoon, while nothing is on fire. Four questions cover almost all of it: what shape does the data come out in, do the IDs survive, what happens to your users' passwords, and do your URLs stay put.
What comes out, and what quietly stays behind
Read the export docs before you trust the export button. Webflow's code export ships HTML, CSS, JavaScript and your Assets-panel images, and Webflow is direct about what it leaves out: CMS content and Collection functionality, User Accounts, Ecommerce, code components, localized pages, site search, and form submission processing. Exported Collection lists render their empty state. It is also a Workspace plan feature, so a Site plan alone will not give you the ZIP.
CMS content exports separately as CSV, and that file has a detail worth reading twice. Rich text comes out as HTML, which is fine. Images and files come out as URLs pointing back to the Webflow site you exported them from. Delete that site and the links break, including images embedded inside rich text. Webflow's own advice is to keep the old site alive as a backup or download the assets by hand. File field data cannot be re-imported into another Webflow site at all.
Airtable has a similar seam in a different place. Attachment download URLs live on airtableusercontent.com and expire after a short time by design, because Airtable treats long-lived public file links as a security risk. A CSV export therefore hands you a column of filenames attached to links that will be dead before you get around to using them. The files are not gone, but pulling them is a separate job you have to plan for, not a side effect of clicking export.
Bubble is friendlier here and still worth reading carefully. You can export a data type as CSV, JSON or NDJSON, but the export runs on the same scheduler as your API workflows, so a busy app queues its own backup behind its own traffic. Bubble also documents a specific round-trip trap: a date interval field exports as descriptive text such as "2 days" while the importer expects the raw millisecond value. Xano exports a table or view to CSV and emails you when it finishes. Knowing which of these applies to you is a ten-minute check.
IDs and passwords, the two things nobody plans for
Identifiers are where migrations actually get expensive. Every record in your old system has a key, and something out in the world points at that key: an invoice number a customer quotes on the phone, a webhook a partner fires, a bookmarked admin link, a foreign key in the spreadsheet your ops lead maintains. Import the CSV into a fresh PostgreSQL schema with auto-generated primary keys and you have silently rewritten every one of those references.
On the Stay World Class migration off Webflow and Xano, we treated this as a first-class requirement rather than cleanup. The ETL ran in four stages and carried the legacy identifiers across into PostgreSQL UUIDs, so old references still resolved after the cutover. The finished stack was Next.js, NestJS and Supabase, and Lighthouse went from 55.91 to 91 out of 100 with LCP 77% faster. The performance numbers are the part people quote. The ID mapping is the part that made the cutover boring, which is what you want a cutover to be.
Passwords are the other one. No platform will hand you your users' password hashes, and you should not want a platform that would. Webflow lists User Accounts, including users and access groups, among the things its code export does not include. So your auth migration is a product decision, not an engineering one: force a reset for everyone, run both systems in parallel and rehash on next login, or move to an identity provider and let people re-link. All three are workable. Discovering you need to pick one during migration week is not.
URLs are the asset you are least likely to get back
Your rankings are attached to paths, not to pages. If the old CMS produced /blog/post-name and the new framework wants /blog/2026/post-name, you have not moved a site, you have replaced it with a different one that happens to look the same. Google will treat the old paths as gone unless you tell it otherwise with 301 redirects.
So the exit plan includes a full URL inventory pulled before you touch anything: crawl the live site, export the list, and keep it. Every path that exists today either lives on unchanged in the new system or gets a permanent redirect written for it. There is no third option that ends well. This is tedious and it is also the single highest-leverage hour in the whole project.
The useful habit is to run all four checks on a normal Tuesday, write the answers in a document, and revisit it once a year. You are not committing to leave. You are pricing an option. A team that knows leaving costs three weeks negotiates its renewal differently from a team that has no idea.
When staying is the right answer
Plenty of teams should read their exit plan, file it, and carry on. If your site is marketing pages with a small CMS and your Core Web Vitals are already green, Webflow is doing its job and a migration buys you nothing you can measure. If your Airtable base has forty records and three collaborators, the expiring-URL problem is a morning of manual downloads, not a project.
The honest signal for leaving is not a bad platform. It is a specific thing you need and cannot have: a query the builder will not express, a test you cannot write, a page you cannot make fast, a bill that grows with usage faster than your revenue does. Absent one of those, the platform is still the cheapest way to run what you run. Write the plan anyway. The point of knowing the exit cost is that it lets you stay on purpose instead of by default.
