Moving between platforms

Moving a website from one platform to another carries across basic content reasonably well, and almost nothing else. WordPress to Shopify, a website builder to a custom-coded site, one CMS to another — the pattern is the same each time. That gap is the part most underestimated when a platform change is bundled into a redesign brief.

What generally carries across in a website migration

Plain body text content — the words themselves — generally transfers via an import tool or a straightforward copy process, sometimes with formatting adjustments needed afterward.

Basic page and post structure, where the two platforms have a roughly equivalent concept (a “page” on one platform mapping to a “page” on another), though the underlying organisation (categories, tags, custom post types) frequently does not map cleanly.

What almost never migrates cleanly between platforms

Custom functionality built specifically for the old platform. A booking system, a custom calculator, a bespoke integration with another business system — these are built against one platform’s specific architecture and data model. Moving to a different platform generally means rebuilding the equivalent functionality from scratch on the new system’s own terms, not importing it.

Design and templates. A theme or template built for one platform has no direct equivalent on a different platform’s system. The new site’s visual design needs to be built for the new platform specifically. That is normal and expected as the actual purpose of a redesign. But it is worth naming, so it is not assumed to be a smaller task than it is.

Metadata, structured data and platform-specific SEO configuration. Title tags and meta descriptions can generally be re-entered. But structured data implementations, redirect rules, and platform-specific SEO plugin configurations are frequently tied to the specific plugin or system that built them. They do not transfer to a different platform’s equivalent tool.

User accounts, memberships and stored customer data, where they exist, often require a dedicated export and import process specific to the two platforms involved. In some cases they cannot be transferred completely. This is worth checking directly against the specific platforms in question, before assuming it is possible.

Forms and their submission logic. Almost universally rebuilt directly on the new platform rather than migrated, because form-handling logic is deeply tied to each platform’s own system.

Why the underlying data model rarely matches when you migrate a WordPress, Shopify or Joomla website

Beyond the visible content, each platform organises information according to its own internal data model. These models are frequently structurally different, not merely differently named. A WordPress site built with custom fields attached to specific page templates, a Shopify store’s product metafields, and a Joomla or headless CMS’s structured content collections are three genuinely different ways of modelling the same underlying idea. Each is a page with extra, structured attributes beyond a title and a body. None of them maps automatically onto either of the others. An import tool moving between two platforms with different data models at best moves the plain content. It leaves every structured field to be manually re-created against the destination platform’s own system.

Why the direction of the move changes the difficulty, not just the destination

Moving from a highly open, self-hosted platform to a more restrictive, hosted one, and moving in the reverse direction, are not symmetrical amounts of work.

Moving toward a more restrictive platform

A move toward a more restrictive platform can mean features the old site had — a specific custom integration, a particular content type — simply have no equivalent to build on the new platform at all. That is a scope conversation to have before signing a contract, not a discovery made partway through the build.

Moving toward a more open platform

A move toward a more open, self-hosted platform generally removes that ceiling. But it shifts more of the ongoing technical responsibility — updates, security, hosting — onto whoever manages the site afterward, covered further in what a small business actually needs.

Testing on a genuine staging copy before cutover: old files and a backup

A platform migration should be built and reviewed on a staging environment that mirrors the intended production setup — the same content, the same integrations and the same domain-adjacent configuration, as far as practically possible. Don’t review it for the first time on the live domain at launch. This is the same discipline covered generally in the build process, applied specifically to a migration. The number of things that can go wrong during a platform change is large enough that discovering a broken integration or a missing content type on a staging copy, with time to fix it, is a materially different situation from discovering it on the live site during a cutover window.

Domain, DNS and hosting: the cutover step itself

Going live on the new platform is usually a separate, domain-level step from the content migration itself. If the new platform is hosted differently to the old one, cutover means updating DNS settings — the A record, or in some cases the nameservers themselves — so the domain points at the new host rather than the old one. That change happens at the registrar or DNS provider, not inside either platform. Before making that change, export a full backup of the old platform (files, database and any media library) and keep it independently of the account being migrated away from. That way a rollback to the old site is genuinely possible if the new platform surfaces a problem only visible once it is live. Once DNS has been repointed, treat the old hosting account as a fallback for a defined period rather than closing it immediately.

Retraining whoever edits the site day to day

A platform change generally means a different content editing interface, a different workflow for updating a page or adding a new item, and different terminology for the same underlying actions. Whoever on the business side actually updates the site day to day needs a genuine handover to the new system — not an assumption that “it’s still a website, they’ll figure it out”. This is a real, if modest, cost worth including in project planning. Content editor familiarity does not migrate automatically along with the content itself.

A realistic checklist for the conversation with a supplier: forms, exports and DNS settings

Element	Ask specifically
Custom functionality	Which pieces need to be rebuilt from scratch, and what that adds to the quote
Design and templates	Confirm the new design is being built for the new platform’s actual system, not assumed to transfer
Metadata and SEO configuration	How title tags, meta descriptions and any structured data will be re-established
Customer or user account data	Whether a genuine export/import path exists between the two specific platforms
Forms	Confirm they are being rebuilt on the new platform, including where submissions are sent

Where this connects to the URL and ranking question

A platform change very often changes the default URL structure the new system generates, which makes redesigning without losing rankings directly relevant to almost every platform migration — the redirect map has to account for whatever new URL pattern the destination platform produces by default, not just the content itself.

What to do next

Ask a prospective supplier to walk through each item in the checklist above specifically for the two platforms actually involved — the answer differs meaningfully depending on which systems are on either end of the move. For what this typically adds to a project’s scope and cost, web development services covers where platform migration work sits.