WordPress migration steps

What moves, and what does not

A WordPress migration is a copy of a full site onto another server. Three parts move together. Files: the theme, plugins, and uploaded images live in wp-content. The database: posts, pages, comments, users, menus, and settings live there. The address: visitors keep seeing the old server until DNS changes. The copy can be ready on the new server while the domain still points at the old one. The live site stays put.

The old company’s own backup does not arrive by itself. The domain registration can stay at the company where you bought the name. A migration does not have to transfer the domain. Mailboxes should not be counted inside the WordPress step either. Free migration on the WordPress hosting page covers the database, files, and content. The team checks that pages fit. A mailbox is not in that sentence.

1. Back up while the old site is still up

The first job is not deleting the old site. Take the files and the database from the old panel, or from a backup plugin. Download a copy to your own computer. If the move stops halfway, that file is the way back. An OwnHost backup covers the days after the account exists. The Personal card lists a weekly backup. The Pro card lists a daily backup. Neither replaces the backup at the old company.

The second job is a list. Write down the WordPress version, the active theme, the active plugins, and the permalink structure. If there is a shop, note the order count. An order does not live in a file. It lives in the database. Copying only wp-content and opening an empty WordPress leaves posts and orders behind. The site opens, and the catalog looks empty.

2. Compare the size with the plan

Uploads are what usually take the space. The Personal card lists 15 GB NVMe. If the site is larger than that, it does not fit that card. The Pro card lists the disk as unlimited NVMe. Ten sites, staging, and a daily backup are on that card too. A single blog looks at Personal. WooCommerce and more than one site look at Pro. Personal is $0.79 a month, or $8.99 when billed yearly. Pro is $3.29 a month, or $26.99 when billed yearly. A PHP version is not on these cards. Read the old site’s PHP in its panel. If you are on 8.2, security support ends on 31 December 2026. The detail is in the PHP article.

3. Do not mix a fresh install with a migration

Both cards list free migration. The FAQ says a WordPress site at another company is moved at no charge. One-click install is a different button. That button opens an empty WordPress. A migration brings your full site. Do not stack both in the same directory. If the team is moving the site, do not start the empty install yourself. If you are moving it yourself, the empty install can be the base you import into. Write the path down before the work starts.

For the free migration, open a support request after the account exists. The page lists live chat, a ticket, and the phone. Put the old panel or WordPress admin access inside that request. Do not post the password in a public place. Name the domain and say that the site is WordPress. If it is a shop, add WooCommerce. If there are orders or downloads, say that too. A file list alone does not bring those records.

4. Files and the database arrive together

The order does not change. First a database is created on the new account. Its name, user, and password are written into wp-config.php. The old wp-config.php is not copied as-is. The old database details are not valid on the new server. Then the files go into the new directory. If wp-content is missing, the site opens without a theme or without images. Then the database is imported. Do not open it to visitors before the import finishes. A half-loaded set of tables drops part of the posts.

If the address changed, the old address is replaced with the new one. Doing that with plain SQL breaks menus and widgets. WordPress stores those fields with a length. When the character count changes, the record breaks. The replacement has to be a tool that understands that storage. search-replace in WP-CLI is written for this job. A hand find-and-replace can look fine on a short post and break in the customizer.

When the import is finished, open Settings, Permalinks, and save once. That does not invent a new address rule. It rewrites the old structure on the new server. On most sites, that save stops posts from returning 404.

5. Check before DNS

See the copy before you change the domain. If the account gives a temporary address, use it. If it does not, do the check with the team while the domain still points at the old server. Look at the home page, one post, one page, broken images, the admin login, and a form message. On a shop, use the cart and one test order. The test should not take a live charge. The payment plugin stays in test mode. If you sell a download, click an old download link.

SSL comes at the end of this check. The card lists free SSL. The certificate often cannot finish until the domain points at the new server. Copy first, then DNS, then the lock. The reverse order produces a browser warning. The Nginx line does not replace the migration either. The web server accepts the request. The WordPress files and the database are a separate job.

6. Change DNS last, and do not touch MX

Point the record at the registrar to the target written in the new account’s panel. Do not memorize a nameserver from this article. The line in the panel is the one that counts. Do not touch the MX record. MX is where mail goes. Treating it as the web server drops mail while you move the site. If mail is moving too, that is a separate request. Personal lists 25 mailboxes and Pro lists 100. The note on the card says each mailbox cannot pass 1 GB. The WordPress migration sentence does not cover those mailboxes.

Do not delete the old server the day DNS changes. Propagation can take hours. If the old copy stays up, a late visitor does not see an empty page. Close the old account after forms and orders are flowing on the new site. Waiting a few days costs less than one wrong DNS record.

7. Read the versions when the move is done

On the new site, read the WordPress version and the plugin versions. If the old server was behind, the hole moves too. The October 2026 security releases are in a separate article. If the shop is older than 11.2, upgrade on a copy, not on the live site. The staging line is on Pro. Personal does not have it. The WooCommerce note is here. If you want major release 7.0, test that the theme and plugins know it before the check, not on migration day. What 7.0 added is in the Armstrong article.

The short order is this. Take a backup. Compare the size with the plan. Do not mix an empty install with a migration. Bring files and the database together. Change the address with a tool that understands serialization. Check the pages. Change DNS last. Do not touch MX. Keep the old server for a few days.