Topic hub

Migrating from Website Builders

Moving away from a website builder is normally a rebuild plus a controlled migration, not a one-click transfer. Text and some data may export, but templates, apps, forms, product logic and page layouts often depend on…

3 published guides0 subtopicsUpdated 21 July 2026

Start here

The main guide for this topic

Practical guide

Moving from Wix to WordPress

Wix does not provide a complete export that recreates a Wix site as a WordPress website. The safe approach is to inventory and export available data, rebuild the design and functions in WordPress, pre…

Open the complete guide →

Published guides

Articles in this section

Practical guide2 September 2026

Moving from Wix to WordPress

Wix does not provide a complete export that recreates a Wix site as a WordPress website. The safe approach is to inventory and exp…

Read guide →

Practical guide29 August 2026

Moving from Squarespace to WordPress

Squarespace can export certain content in a WordPress-compatible XML format, but the export does not recreate the full site. Templ…

Read guide →

Practical guide26 August 2026

Migrating Away from a Website Builder

Moving away from a website builder is usually a controlled rebuild rather than a one-click transfer. Content, products and contact…

Read guide →

About this section

Decide whether migration is justified

Migration is sensible when a real limitation affects revenue, operations, compliance, content management or ownership. A dislike of the editor may be solved with training; an inability to support required data, integrations or URLs may justify a move.

Create an inventory before cancelling anything

Every public URL, page title, meta description and canonical setting.
Page text, images, files, alt text and embedded media.
Forms, notifications, booking rules, products, variants and customer messages.
Analytics, Search Console, advertising tags and conversion events.
Domain, DNS, email records, subdomains and verification records.
Orders, customers, members, subscriptions and consent records where applicable.
Paid apps, licences, integrations and renewal dates.

Separate what can move from what must be rebuilt

Migration expectations
Asset	Often exportable	Often requires rebuilding or verification
Page text and blog posts	Sometimes, in a platform-specific export	Layout, reusable blocks, embeds and formatting
Images and files	Sometimes, but links and filenames need checking	Cropping, responsive variants and alt text
Products and orders	Frequently through CSV or platform tools	Variants, tax rules, subscriptions, discounts and integrations
Design	Rarely as a reusable theme	Templates, styling, mobile behaviour and components
Forms and bookings	Results may export	Form logic, notifications, calendars and automations
SEO settings	Can often be recorded manually	Redirects, structured data, canonicals and platform-generated URLs

Protect search visibility and email

Keep the domain stable where possible. Map each old URL to the closest equivalent new URL and use permanent redirects only after the destination is ready. Preserve email-related DNS records and verify mail flow before and after changing nameservers or DNS hosting.

Use a staged cutover

Build and test the replacement away from the live domain.
Freeze or synchronise changing content and order data.
Back up the existing site and export all available data.
Prepare the redirect map and DNS change.
Switch during a monitored period, not immediately before a holiday or campaign.
Test key URLs, forms, checkout, email and analytics.
Keep the old account available until the new site and all data have been verified.

Do not cancel too early

Cancellation should be the final administrative step, after the new site, domain, email, redirects, customer data and billing records have been checked. Record how long the old platform retains data after cancellation.

Choose the destination before extracting content

The new platform should be selected from requirements, not simply because it is the opposite of the old one. Identify which limitation is being solved and verify that the destination handles it without creating a different operational problem.

Preserve evidence and history

Before migration, save invoices, plan details, DNS records, form submissions, order exports, customer consent records, redirects and screenshots of important settings. Some information is needed for accounting, disputes or data-protection responsibilities even when it will not appear on the new site.

Content migration needs editorial review

Do not copy every old page automatically. Decide whether each URL should be retained, improved, consolidated, redirected or retired. Preserve pages that have users, links or business value, but avoid carrying obsolete content into the new architecture merely to keep the migration simple.

Monitor after cutover

Check server responses, redirects, forms, checkout, email, analytics and Search Console after launch. Continue monitoring for several weeks because old URLs, cached DNS and delayed customer journeys can expose problems after the initial test window.

Sources and date checked

Platform features, plan names and commercial terms can change. The official sources below were checked on 21 July 2026. Recheck them before choosing or renewing a plan.

Practical next step: Create a migration inventory before cancelling or rebuilding anything: URLs, content, forms, products, integrations, domain, DNS, email and data exports.