Most WordPress-to-static migration guides assume you're comfortable exporting XML, running a plugin, or scripting against the REST API. offloadcms's importer skips all three: it connects directly to the WordPress database and reads the uploads directory on disk. Nothing to install on the old server, nothing that depends on the site staying up during the migration.
What gets imported
- Posts and pages, including drafts and revisions
- Categories and tags, hierarchy intact
- Custom fields (ACF-style field groups)
- Media — uploaded to R2, with URLs rewritten and hotlinked assets flagged
- Permalink structure, so existing links and search rankings survive the move
Then it prints
Import and publish are two separate commands on purpose. Import gets your content into D1; publish is the step that walks that content and prints it to static HTML, as described in how the publish pipeline works. You can inspect what came across before you decide the old site is safe to turn off.
$ offloadcms import \
--db wp_natalievo \
--uploads ./wp-content/uploads
✓ 248 posts, 31 pages
✓ 12 categories, 86 tags
✓ 1,204 media -> R2
✓ permalinks preserved
$ offloadcms publish
✓ 279 entries printed to static
We ran this on a real WordPress installation before shipping it
Before this was a feature we'd sell, it was a migration we had to actually get right: natalievo.com, a real WordPress site on one of our own servers, was our first end-to-end test of the importer and the publish pipeline together. That's one migration, not a thousand — but it's the one that told us the direct-database approach holds up against a site that wasn't built with a migration in mind.
If you're weighing whether to migrate a site yourself, start with the WordPress migration overview or get in touch and we'll walk through your specific setup.