Moving a WordPress site to Contentive: what transfers and what doesn't

Migration posts usually oversell. This one is a list of what actually comes across, what doesn't, and what you'll have to do by hand — because the failure mode of a migration isn't a hard error, it's discovering three weeks later that something quietly didn't make it.

How the import works

Point the importer at a WordPress site and it reads the standard REST API at /wp-json/wp/v2/. If that's turned off, upload a WXR export file instead — the same pipeline handles both. Everything lands in staging as content you review before anything reaches production, so a bad import costs you a look rather than a live site.

What transfers

Posts and pages. Title, body, date, status, excerpt.

Slugs, exactly. This is the one that matters commercially. A post at /blog/how-we-price-projects keeps that path, so the client's search rankings and inbound links survive the move. It's also what feeds the generated sitemap, so the new site's URLs are right on day one.

Media. Images and files are downloaded from the old site and re-hosted, and the references inside post bodies are rewritten to the new URLs. You're not left with a site quietly hotlinking a server you're about to switch off.

Taxonomies. Categories and tags come across as content of their own, related to the posts through real references rather than a text field. That means "all posts in this category" is a query afterwards, not a string match.

Bodies, converted to structured content. HTML becomes structured rich text rather than a blob of markup — headings, lists, links, emphasis, images. That's what makes the content portable afterwards instead of being welded to one theme's stylesheet.

Simple custom fields. Values that WordPress exposes through the REST API — plain strings, numbers, booleans, the kind of thing a custom-field plugin adds — come across as fields you can map onto your model.

What doesn't transfer

Your theme. None of it. Template files, stylesheets, JavaScript, customiser settings, widget areas. You rebuild the design as a Liquid theme. This is the largest single piece of work in any migration, and anyone telling you otherwise is selling something.

Plugin-specific data. If a plugin stores its data in its own tables rather than as posts or exposed fields, the importer cannot see it. Event calendars, stored form submissions, membership records, custom sliders, page-builder layouts held as serialised metadata — assume none of it comes.

Page-builder layouts. An Elementor or Divi page is a proprietary structure. What you get is the rendered content, not the layout. In practice the page gets re-composed from your own sections, which is usually what you wanted anyway.

Shortcodes. Known, safe ones are unwrapped to the content inside them. Anything else is left in place as literal text and the document is flagged for review, so it shows up in a list rather than silently vanishing or silently rendering as [some_plugin id="4"] on the live site.

Comments, users and their passwords. Not imported. If the site needs accounts, that's the memberships app and a fresh sign-up, not a password migration.

Redirect rules and server config. Bring your own list. Because slugs are preserved, you generally need far fewer than you expect.

The work that's genuinely yours

Three things, roughly in this order.

First, decide the content model. The importer can suggest one from what it finds, or map onto types you've already defined. An honest migration is a good moment to stop having one page type with fourteen optional fields.

Second, rebuild the theme. A layout, a template per content type, a template per section.

Third, re-compose the pages that were page-builder pages. This is manual and it's where the time goes.

A sensible sequence

Import into staging. Look at the flagged documents first — the shortcode ones — because they tell you what the old site was actually doing. Fix the model, re-import if needed; the import is idempotent, so a second run updates rather than duplicating. Build the theme. Compose the awkward pages. Check the routes and the sitemap. Then promote to production, and keep the old site up for a fortnight.

When not to do this

If the site's value is in plugin behaviour rather than content — a complicated shop, a booking system with rules, a membership site with years of records — the import gets you the content and leaves the hard part untouched. That's not a migration, it's a rebuild with a head start. Price it accordingly, or don't take it.