Moving from WordPress: what comes with you?

First, choose what is changing.

WordPress.com is a hosted service. A self-hosted WordPress website uses WordPress software with a hosting provider, which may also manage updates and backups. Ask who supplies yours and who controls the account. A WordPress login alone doesn't tell you who controls the hosting or domain.

If you're happy with the website and simply want another host or maintainer, retaining WordPress may be the sensible route. A replacement build makes more sense when the page structure, presentation or working arrangement needs changing. Our WordPress and custom website comparison helps you compare those responsibilities.

For WordPress.com, check the current plan and supported migration route. For self-hosted WordPress, involve the host or developer who can access the database and files. Neither route should begin by cancelling the existing service.

Three different things people call “the website files”.

Agree which materials the receiving provider needs before asking for a download. The distinction matters most when the new website will use a different platform.

On a small screen, scroll the table sideways.

WordPress.com's export guidance explains that the standard export contains content and media references, while the theme, design customisations, plugins and actual media files are excluded. Keep the old media reachable until the receiving provider has copied and checked it. Private material needs an agreed protected transfer.

For self-hosted sites, Tools → Export creates the WXR content file. WordPress's backup guidance explains why a typical full restore needs both database and files. Restoring WordPress and rebuilding elsewhere are different jobs.

A migration plugin may help with a compatible move. Ask the receiving provider to confirm suitability, licences and costs. A complicated shop or membership website needs its own scope; a free plugin doesn't establish that the whole move is free or straightforward.

Keep the parts people already find useful.

Make a page list before editing anything. Record each current address, its purpose and whether to keep, improve, merge or retire it. Include blog posts, service pages, PDFs and pages used in advertising. An old article answering a good customer question may deserve a better home on the replacement.

Gather original photographs, logos and downloadable documents with permission to reuse them. Check embedded galleries and page-builder layouts separately. A paragraph may survive an import while its surrounding layout, shortcode or custom field needs rebuilding.

Ask for a media inventory and compare it with the replacement. Open important PDFs and check images on real pages. Make sure the finished site serves its own agreed copies, rather than depending on image addresses that will disappear when the old hosting ends.

Follow the enquiry beyond the button.

A form needs more than its visible fields. Record where messages arrive, what the visitor sees afterwards, any spam protection and which system stores the submission. Ask for an authorised test that confirms delivery to the correct inbox or CRM.

Do the same for booking tools, newsletters, payments, maps, analytics and consent controls. List the account owner and whether each connection will be retained, replaced or removed. Moving a contact page doesn't automatically move the service behind it.

For shops and member areas, include orders, customer records, subscriptions and access rules in a separate migration plan. Agree how changes during the move will be captured. Share access through the provider's approved process, keeping passwords and customer data out of a general handover email.

Keep addresses stable where you can.

Preserve useful page and download URLs when practical. Where an address changes, map it to the closest relevant replacement and have the developer implement a permanent redirect. Sending every old page to the homepage can leave visitors without the information they came for.

Google's URL migration guidance recommends preparing that mapping, testing the new site and monitoring the move. It also describes possible ranking fluctuations. A redesign isn't a promise that search visibility will stay the same or improve.

Give someone responsibility for checking internal links, canonical addresses, sitemap entries and launch indexing settings. Keep control of the old domain and any infrastructure needed to serve redirects; include images and PDFs in the URL plan.

Domain registration, DNS, website hosting and business email can be supplied separately. Record who manages each before changing anything. Ask the domain or email administrator to preserve the mail records, including MX and relevant verification records, and test sending and receiving afterwards. Changing the website doesn't automatically require a registrar or email move. The broader provider handover guide covers those arrangements.

Name an owner for each part of the move.

1. You approve the scope. Decide what the business needs to keep, who can authorise access, and what a successful replacement must do.
2. The current provider prepares the handover. Request agreed exports, backups, assets, account details and dependencies. Confirm licence ownership and cancellation consequences.
3. The receiving provider proves the replacement. Review representative pages on phone and desktop, test agreed functions, and check the URL map before launch.
4. The named launch owner coordinates the change. Agree the timing, final content updates, DNS responsibility, rollback route and who monitors enquiries afterwards.

Cancel the old arrangement only when the agreed checks are complete and its remaining dependencies are understood. Keep the handover and restore instructions somewhere the business can access.

Download the editable WordPress handover checklist (.txt)