WordPress migration

WordPress migration services rehearsed before anything moves

New host, new domain, new CMS or a network that needs splitting. We move content, media, users and orders, map every URL and plan the cutover around your quietest hour.

  • 500+ WordPress projects delivered
  • Full rehearsal on staging
  • Project manager on every move
What is included
  • Host-to-host moves
  • Other CMS to WordPress
  • Multisite splits and merges
  • Page builder to blocks
  • URL mapping and redirects
  • Users, orders and subscriptions
Get a free quote Reply within one business day. NDA on request.
The problem

What makes a WordPress move risky

Copying files and a database is the easy part of a migration. What hurts is everything that was attached to the old address: serialized settings that still hold the old domain, image paths inside ten years of posts, customers who can no longer log in, and a few thousand indexed URLs that now return a 404.

People come to us at different points. Some are leaving a host that keeps going down. Some are moving from Drupal, Joomla, Wix or a custom site onto WordPress. Others are merging brands into one install, breaking a multisite apart or retiring a page builder. The method is the same each time. We inventory what exists, rehearse the move on a copy, compare the result against the source, and only then schedule the cutover. If the destination is not WordPress at all, our wider migration and modernization service covers it.

  • Rankings drop after the move

    URLs changed, redirects were incomplete or the staging noindex setting went live. Traffic falls for weeks and nobody kept a list of what the old site had indexed.

  • The site moved but settings did not

    Widgets, theme options and builder layouts store the domain inside serialized data. A plain find and replace corrupts them, and sections of the site come up empty.

  • Orders and signups arrive mid-move

    A store or membership site keeps taking payments while the copy is in progress. Anything written to the old database after the export is missing on the new one.

  • Email and logins break at cutover

    DNS was switched as a single step. Mail records were overwritten, password reset emails stopped sending and users from the old system cannot sign in.

What we do

Moves we carry out

We handle the move end to end, including the parts a migration plugin does not cover: redirects, users, DNS and the checks afterwards.

Host-to-host moves

Files, database, cron jobs, SSL, caching and PHP settings rebuilt on the new host and tested through a temporary URL before any DNS record changes.

Other CMS to WordPress

Content from Drupal, Joomla, Wix, Squarespace or a custom database mapped to post types, taxonomies and fields, with authors, dates and media brought along.

Multisite splits and merges

A single site lifted out of a network, or separate installs combined, with table prefixes, user roles and upload paths rewritten so each site stands alone.

Page builder to blocks

Builder layouts rebuilt as block patterns and templates, leftover shortcodes removed from post content, and editors moved to the block editor with a written guide.

URL mapping and redirects

A crawl of the old site matched to new addresses, 301 rules for every changed URL, and a check that each redirect resolves in one hop.

Users, orders and subscriptions

Accounts, roles, order history and active subscriptions moved with their relationships intact, and a final sync to pick up changes made during the move.

Typical projects

Common migration scenarios

01

Leaving a slow or unreliable host

The same site on better infrastructure. We copy, test on a temporary address, lower DNS TTL in advance and switch in a quiet hour with the old server kept as a fallback.

02

Replatforming to WordPress

A rebuild on WordPress with the old content imported by script, not by copy and paste, and every legacy URL redirected to its new home.

03

Rebrand and domain change

New domain, same site. Database references rewritten safely, redirects from the old domain, updated sitemaps and the change registered in Google Search Console.

04

Consolidating several sites

Regional or brand sites merged into one install or one multisite network, with duplicate users reconciled and each old domain redirected page by page.

In depth

The details that decide a migration

Inventory first

Before touching anything we list what the site consists of: post types and counts, users by role, media volume, active plugins and where each keeps its data, scheduled tasks, mail configuration and every URL a crawler or the sitemap can find. On a WooCommerce site we note whether orders sit in the posts tables or in WooCommerce's dedicated order tables, because the two are exported differently. This list becomes the checklist the finished migration is measured against.

Search-replace without breaking serialized data

WordPress stores many settings as serialized PHP arrays, where each string is recorded together with its length. Change a domain inside one with a raw SQL replace and the length no longer matches, so WordPress discards the whole value. Widgets empty out and theme options reset. We run replacements with WP-CLI, which unserializes, replaces and repacks each value, and we do a dry run first to see how many rows each table would change. Builders that keep layouts as JSON in post meta need their own handling, since slashes in URLs are escaped there.

Users and passwords

Between two WordPress installs, accounts move with their password hashes and people log in as before. From another CMS the hashes use a different scheme. We can either ask everyone to reset on first visit, or add a small bridge that checks the old hash once and saves a WordPress one, which spares your support inbox. When sites are merged, user IDs collide, so authorship, order ownership and course enrollments are remapped to the new IDs. Role data also depends on the table prefix, a detail that locks administrators out when it is missed.

Redirects are part of the migration

Every old URL gets one of three outcomes: it stays the same, it redirects with a 301 to its closest equivalent, or it is retired on purpose. We build the map from a crawl plus the pages that receive search traffic and backlinks, load the rules at server level where possible, and test the full list on staging. Redirect chains and blanket redirects to the home page are the two shortcuts we refuse to take.

Cutover and the week after

For busy sites we freeze content or place the store in a short maintenance window, run a final delta of orders and signups, switch DNS with a low TTL already in place, and leave mail records untouched. Then we watch. Server logs show any 404s that slipped past the map, Search Console shows crawl errors and indexing, and we confirm the staging noindex flag is off. Pairing the move with a maintenance plan keeps that watch going after the first week.

Process

The migration runbook

  1. 1

    Audit and inventory

    We catalog content, users, plugins, integrations and URLs on the current site, then agree what moves, what is retired and what gets rebuilt.

  2. 2

    Rehearsal on staging

    The full move is run on a private copy at the destination. Scripts and settings are saved so the real run repeats the rehearsal exactly.

  3. 3

    Verification

    Record counts, media, logins, checkout, forms and redirects are compared against the source. You review the staging site and sign off.

  4. 4

    Cutover

    In the agreed window we freeze changes, sync the final delta, switch DNS and confirm SSL, email and payments on the live address.

  5. 5

    Post-launch checks

    We monitor 404s, crawl reports and server load, fix stragglers and keep the old environment available until you are satisfied.

Deliverables

Left in your hands once the move is done

  • An inventory of what moved and what was retired
  • A tested redirect map for every changed URL
  • Before and after record counts for content, users and orders
  • A rollback path until you sign off
  • Access details and documentation for the new environment
FAQ

Before you move a WordPress site

Will the site go offline during the migration?
For most moves, no. The new copy is built and tested while the old site keeps running, and visitors shift across as DNS updates. Stores and membership sites may need a short planned freeze so no order or signup is written to the old database. We agree that window with you in advance.
Will we lose search rankings?
A careful move should hold them, though short-term fluctuation is normal when URLs or domains change. We keep URLs where we can, redirect every one that changes with a 301, carry over titles, descriptions and structured data, and watch Search Console after launch. We cannot promise positions, only that nothing avoidable is missed.
Can you move a site to WordPress from Wix, Squarespace or a custom CMS?
Yes. Content is extracted by export, API or a crawl, cleaned and imported into proper post types and fields. Designs do not transfer between platforms, so the look is rebuilt as a WordPress theme. See WordPress theme development for that part.
What happens to user accounts and passwords?
WordPress to WordPress, they move unchanged. From other systems we either trigger a password reset or add a login bridge that converts each password the first time its owner signs in. Customer order history, memberships and course progress are remapped to the migrated accounts.
Can you separate one site from a multisite network?
Yes. We extract that site's tables, rename prefixes, pull its users out of the shared user tables, move its uploads and rewrite paths. The reverse, bringing standalone sites into a network, is equally possible. Network-activated plugins and shared plugin licenses need review in both directions.
How long does a migration take?
A like-for-like host move is usually short. A replatform with content mapping, a new theme and thousands of redirects is a project of weeks or more. The volume of content matters less than the number of content types, integrations and special cases. The quote sets out milestones after the audit.
What if something goes wrong after the switch?
The old environment stays intact until you sign off, and DNS is prepared with a low TTL so traffic can be pointed back quickly. Because the cutover repeats a rehearsed run, most problems have already been found on staging, and the rollback steps are written into the runbook before launch day.
Start a project

Planning a move? Send us both ends

Tell us where the site is now and where it needs to be. We will reply within one business day with what the audit covers and a free quote.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.