How I Moved a Webflow CMS Site Without a Big-Bang Cutover

I like Webflow for the part where a site gets designed. I get less excited when a small CMS-driven site becomes tied to one hosting bill, one publishing path, and one place where a hurried change can become production immediately.

The last time I moved one, I did not replace Webflow in a weekend. I built a static copy beside it, proved that its CMS pages and media made the trip, then cut DNS only after the boring checks passed. That made the move feel like an operations task instead of a leap of faith.

For the export step, I used ExFlow, a Webflow exporter that can pull pages, CSS, JavaScript, media, and CMS content into a static bundle. A pretty homepage is easy to copy; a collection template with dozens of routes is where an export plan earns its keep.

1. Inventory the routes that actually make money

Before exporting, I make a route inventory: the homepage, utility pages, collection listing pages, individual CMS detail pages, forms, redirects, and the assets those pages rely on. I count collection templates and inspect a handful of old and new records—not just the one pretty example in the designer.

/                         homepage
/guides/                  collection index
/guides/{slug}/          CMS detail route
/resources/{slug}/       second CMS template
/contact/                form and confirmation path
/old-campaign/           redirect target

That list becomes the static site’s acceptance test. It is far more useful than the vague goal of “export everything.” The same discipline helps with a review-first Shopify blog automation: define what must be correct before automation publishes.

2. Export a complete snapshot, not just the shell

In ExFlow, I select all pages plus CSS, JavaScript, images, and media. I also make sure the export uses .html pages, because that makes conventional static hosting less surprising. ExFlow can sync the bundle to Git, S3, or FTP; I prefer Git here because it gives me a reviewable history and a fast rollback point.

I treat sync credentials like production secrets. They belong in the exporter configuration or secret store, never inside an exported JavaScript file or a committed .env file. The exported repository should be deployable by someone else without exposing the keys that got it there.

A static export is also a useful time to spot dependencies you have not planned for: form handling, search, gated downloads, analytics, or scripts that assume a Webflow-hosted URL. Exporting does not erase those dependencies; it makes them visible.

3. Put the first export on a private preview URL

I deploy the bundle to a preview branch, temporary subdomain, or static-host preview. The Webflow site remains live and canonical. The preview has one job: prove that the exported site is a faithful copy before any public switch.

That is the lesson behind my Webflow CMS pre-launch export checklist: test rendered routes, media paths, navigation, responsive behavior, and forms independently. A successful download is not the same as a successful site.

4. QA CMS pages like an operator, not a demo

I check at least three records in every CMS collection: the newest, the oldest, and one with awkward content such as a long title, missing image, or unusually large body. That catches issues a single hand-picked record will hide. Then I test desktop and phone breakpoints, internal links, canonical URLs, and page titles.

For a quick route pass, I keep expected URLs in a file and run:

while read -r url; do
  curl -ILs -o /dev/null -w '%{http_code} %{url_effective}\n' "$url"
done < routes.txt

I want an intentional response for every line. A redirect can be fine; a quiet 404 on an old collection entry is not. This is the same QA habit I used in my static-site cutover runbook: enumerate routes, then make the checklist executable.

5. Make content ownership explicit before DNS changes

Where will the next CMS edit happen after the static site goes live? If Webflow remains the authoring tool, schedule an export and sync after editorial changes. If Git becomes the source of truth, write down who edits data files and who reviews pull requests. If neither answer is clear, do not cut over yet.

For a lightweight site, I usually choose scheduled export-to-Git, then deploy from the main branch. It keeps the familiar Webflow editing workflow while giving the host a static artifact. Teams comfortable with repositories may move publishing into Git, similar to my static blog build notes.

6. Cut over with a rollback, not a promise

Once preview checks are clean, I lower DNS TTL ahead of time, preserve the existing Webflow configuration, and point the domain to the new host. I do not delete the old project during the first window. I monitor the highest-value routes, form submissions, and real-device rendering.

My rollback is simple: keep the prior DNS record documented, retain the last known-good Git commit, and set a short observation window. If a collection route or checkout-adjacent page breaks, I can restore service first and diagnose second.

The part I would do first

A Webflow migration does not have to mean abandoning the designer or rebuilding the site. Start by exporting one complete, private static copy with ExFlow, then compare it to your route inventory. If the copy is accurate and the next publishing owner is clear, the final cutover becomes a small, reversible infrastructure change—not a big-bang launch.