M CloudSite / Migration
Start a move
Where the site lives now

An old stack you maintain by memory.

WordPress with a plugin list nobody wants to audit. A Webflow project that only one person can publish. Or a folder of HTML that was last touched by a contractor.

Where it can live instead

The same site, as files you can read.

CloudSite takes the output — HTML, CSS, assets — and serves it from Cloudflare Pages or Firebase Hosting. No plugin layer, no database to keep alive, no rebuild queue.

VS
The move

Five steps, in this order.

CloudSite does not import a WordPress database or a Webflow project. You bring the built site — the files a browser actually receives — and CloudSite hosts and edits that.

Export the output

From WordPress, publish a static copy through your existing export path. From Webflow, export the site. From a hand-built folder, use it as-is.

Check the root

The archive must place index.html at the site root. Fix nested folders before uploading, not after.

Take a preview

Upload once and open the pages.dev address. No DNS change is needed to look at the result.

Replace the site

Upload a zip or the individual files. The upload replaces the whole site on the current property.

Bind the domain

Point the domain from the console. CloudSite writes the CNAME at Cloudflare automatically.

Keep the old site up while you check. The preview address works independently of your domain, so you can compare page by page before switching traffic. Review on a phone as well as a laptop — exported layouts often break where the CMS used to handle wrapping.

Side by side

What actually changes on day two.

 The old stackOn CloudSite
PublishingA login, a builder and a publish button somebody ownsAn explicit deploy to Pages or Firebase, callable by an agent with a write token
EditingTheme settings, shortcodes, or a visual editor's approximation of the markupChat for intent, or a direct write to one named file
StructureContent lives in a database you have to back up separatelyThe site is the files; index.html at the root is the entry point
LanguagesA plugin per locale, or a translation service bolted onUp to four languages per property, managed as part of the site
DomainDNS records copied by hand from a support articleBinding writes the CNAME at Cloudflare automatically
ReviewStaging environments that drift from productionPreview links valid for one to 72 hours, openable without an account
CeilingWhatever the plugin ecosystem will still support2 MB per file, UTF-8; large media belongs elsewhere
Honest boundaries

What travels, and what stays behind.

Comes with you

  • Your copy, layout and visual identity
  • Static assets, provided each file is under the limit
  • Your domain, once you choose to bind it
  • Any HTML that a browser can render on its own

Needs another plan

  • Server-side WordPress plugins and the database behind them
  • Webflow's CMS collections as a live editing interface
  • Commerce checkout, memberships and comments
  • Anything that requires code to run on the server per request

If the site is mostly content, this is usually straightforward. If it is an application with accounts and transactions, keep the application where it is and migrate the marketing pages first. That is still a migration, and a much smaller one.

Start with the preview, not the DNS record.

Upload a site