Builder Content Assessed
What is stored as clean markup and what is stored as builder shortcodes.
Moving WordPress between hosts is routine. Moving it to or from another platform is not, because content built in a page builder is stored as builder markup, plugins keep data in their own tables, and permalink structure decides whether the URLs survive. WordPress migration is mostly those three problems.
A page built in a visual builder is not portable content. Finding that out mid-migration is expensive.
What is stored as clean markup and what is stored as builder shortcodes.
Custom tables and field values that a standard export does not touch.
URL structure kept, or redirected completely where it has to change.
Including sized variants and the references inside content.
Content and URLs checked on staging rather than after launch.
Four situations with very different difficulty.
Discuss Your Migration →The routine case. Files, database and DNS, with care over URLs stored in the database.
From another platform. Content mapping and redirect planning dominate.
To a headless or static build. Builder content and plugin data are the obstacles.
Splitting or merging sites, where URL and user handling get complicated.
Assessment, content, URLs and verification.
Ongoing WordPress work is covered by WordPress development.
Audit how content is stored first. It determines whether this is a week or a month.
Clean markup, builder shortcodes, custom fields or plugin tables.
Every indexed URL, including attachment and archive pages.
Content, media and database, with URL references corrected.
Page-by-page parity checks and redirect testing.
Launch with rollback available, then watch errors and coverage.
It is the single biggest factor in how difficult a migration away from WordPress will be.
Most visual builders store a page not as HTML but as their own structure — shortcodes or serialised layout data that only that plugin can render.
Exported through the standard WordPress export, that content arrives as unreadable markup. It has to be rendered by the builder and captured as HTML, or rebuilt by hand.
A site with fifty builder pages therefore has a very different migration cost from a site with fifty pages of standard editor content, and it is worth establishing which you have before scoping anything.
Anything a plugin stores in its own tables. Form submissions, ecommerce orders, membership records, event data, and frequently custom field values depending on how they were registered.
The WordPress export covers posts, pages, custom post types, taxonomies and their metadata. Plugin tables sit entirely outside it.
Finding what those plugins hold requires looking at the database rather than at the admin interface, which is why the audit comes before the plan.







WordPress migration moves a WordPress site between hosts, or to or from another platform — handling content storage formats, plugin data, permalink structure and the media library.
Yes, and the cost depends on volume. Builder content has to be rendered and captured as HTML, or rebuilt. Fifty builder pages is a substantially larger job than fifty standard editor pages.
They should where the current structure is reasonable. Where the destination imposes a different pattern, a complete one-to-one redirect map is required — see website migration.
It depends on the plugin. Data in custom tables — form entries, orders, memberships — is not included in a standard export and needs separate handling. The audit identifies what exists before the plan is made.
Low, with care. The main pitfall is URL references stored inside serialised database values, which break if replaced with a naive find-and-replace. Proper migration tooling handles this correctly.
Still deciding if wordpress migration is right for you?
Talk to UsThe WordPress export produces a single file containing every post, page and custom post type. It looks like the whole site, and for many sites it very nearly is.
What it does not contain is anything a plugin decided to store its own way. Three years of form submissions, the membership records, the event bookings — all in tables the export does not touch.
This is discovered after the old site is decommissioned, which is the point at which it stops being a technical problem and becomes a data loss.
Tell us where the site is and where it is going. We will audit how the content is stored and what the plugins hold before quoting anything.
