This is your complete guide to all the nuances, caveats and points of failures to ensure a successful site migration with the lowest possible downtime.  And yes, no downtime is possible!  PDF Checklist Companion Guide Included. 

In this post, I’ll be going over a highly detailed step-by-step process, elaborating on numerous precautions of key steps. A table of contents will appear further below this introduction. As not all sites are the same, they may not need the same level of care and several steps could be skipped; however, the overall sequence applies to all. The extra details provided are more catered to eCommerce and enterprise grade sites that can’t afford any mishaps.

Note, this guide assumes your email provider will not change. If your email provider will also change to your new host, please reach out to your new hosting provider to ensure there won’t be an interruption in email service, or loss of existing emails.

Another quick but uber important note is regarding your primary domain. Is it, or is it not, using www? It’s imperative you ensure this does not change after the migration is complete, or your established SEO will be greatly negatively impacted. Unfortunately Google is very intolerant of such a change. I’ve seen this happen several times over the years, so don’t make this mistake. I’ll mention this again in step 7.

And finally, I laid out the steps in what I believe is the most ideal order. However, some of the steps are interchangeable and don’t have to be done in that specific sequence. Just ensure not to proceed past Crunch Time before all the previous steps are complete. Please also find my custom PDF checklist companion at the very bottom of this post!

Misconceptions

Before we begin, let’s first clear up two misconceptions and make sure we’re on the same page. These misconceptions are “downtime” and DNS Propagation.

What is downtime? There is planned downtime, unplanned downtime and hard downtime. For unplanned and hard, there are roughly four definitions for this, and they come from four different perspectives.

1. Company owner: If they try to load the site and they don’t see what they are expecting, they likely consider the site is down. This includes errors, strange layouts, missing images, forms not submitting, etc.
2. Webmasters: If the site is timing out or showing errors like 500 or 502, then they could classify this as downtime.
3. Mediocre web host: In terms of their uptime guarantee, is the server actually down? If it’s up, then it’s not relevant to your site having issues; this isn’t “downtime”. If a technician can log into the server (usually via SSH), then the server is “up”; therefore, your host does not classify this as downtime.
4. Good web host: While from a legal standpoint, they’ll have the same written policy as the mediocre host, but if something else besides the server within the hosting companies control is preventing your site from being accessible, then this is “downtime”. But issues that end up being related to coding or DNS won’t fall into their uptime guarantee.

Intentionally putting your live site in maintenance mode is planned downtime. For some sites, like heavy traffic eCommerce, they’ll have no choice but to put the site in maintenance mode to prevent loss of orders during the migration. If you practice the migration a few times, you’ll be in a better position to complete it quickly during crunch time, thus minimizing the maintenance window to your visitors.

While all the above is mildly relevant to your migration, it’s good to have this knowledge when working with your web hosting’s tech support team. It’s also the perfect segue to the next topic: DNS Propagation! Ready for the pop quiz?

True or false: The moment you change your site’s DNS, the site goes down? If you have experienced that in the past, as it is very common to encounter, I don’t blame you for thinking this is true. But the answer is false!

When you change the DNS, you’re pointing it from the old working server that has a copy of your site running, to another server. If the other server is already properly configured with a copy of the site, then there is zero reason for downtime. Changing the DNS doesn’t bring the site down, it just routes your domains internet traffic to the new server.

The phenomena of DNS Propagation is that when users are visiting your site during that window, they’ll either be routed to the old server or the new server. Either way the site will be up on both servers (if you follow this guide.) Some of the key steps in this article will go over the proper configuring of your new hosting, prior to updating the DNS!

If you’d be interested in my personal explanation of what DNS propagation is without all the technical jargon, my next post will be on this subject. Stay tuned!

Alright! Let’s get started.

^{Revised on 2023-04-16 | Revision # 1}

From A2 hosting, to Hostzinger, there might just be a thousand places to host your WordPress site, like WP Engine, HostGator, SiteGround or DreamHost.

It’s likely you already picked a hosting provider, but if you’re looking for references, feel free to hit me up on Twitter and I’m happy to share what info I know about them.

Prepping your new server has a few components, including one that is very important (it’s a key configuration that prevents the downtime)!

Add your domain to your new hosting account

Adding your domain may have been done already when you signed up, but not always. It depends on your hosting provider. If you can’t tell it’s been added, then reach out to their support team.

Note that the simple act of adding the domain to your hosting account should not be confused with either a domain registration transfer, or changing the DNS. Adding the domain, put simply, is a server configuration at the host, that tells the server where to look for the website when your domains DNS routes traffic to the server. Because technically, you’re not pointing your domain to your website, you’re pointing it to the servers IP address. It’s up to the server to then pull up your site. So if your domain is not added to the server, then the server won’t know what to do, and will instead display an error.

Get an SSL installed on the new server

This step often times isn’t fun, which could be why it’s usually not considered during site migrations. Just note that most hosts that provide a free SSL aren’t able to process and install it until after the DNS is pointed to the new server. This pickle is what ultimately causes the downtime. There are a few ways to work around that!

• You can attempt to obtain a copy of the current SSL from your old host and have that installed at the new host. The old host support team would likely have to help with obtaining a copy of the existing SSL. It’s very important to get both the CRT and the KEY.

• You can purchase a new SSL from a third-party vendor and install that at the new host. Note that SSL ordering has many goofy steps that complicate the process, specifically the CSR, so I don’t want to get into that. But just make sure you have obtained the CRT and KEY, or at least ensure your host already has the KEY if you generated the CSR at your host instead of at the SSL vendor.

So adding the domain and preinstalling the SSL are the two basic configurations you need to set up at the new host sometime before performing the second migration. Once configured, you’re on your way to having a no downtime migration!

A third server configuration to check is the PHP Version! Does it match the same (or higher) than at your old host? Higher is better if possible; lower is not a good practice.

Technology gives us several ways to go about this step. There are WordPress plugins that can migrate it, some hosting providers have their own special migration plugin or will manually migrate it for you, or you can do it manually if you aren’t afraid of SFTP or SSH, or you can hire someone to do it. Just note that with WordPress sites, you usually only need three things.

1. A fresh empty “Hello World” WordPress installation, up and running at the new host.
2. The /wp-content/ directory from the old host. This should ideally be zipped up.
3. The raw SQL database from the old host. This doesn’t need to be zipped, but could be inserted into the /wp-content and zipped along with it.
4. I don’t recommend copying over the /wp-config.php file.

It’s possible you might have some custom apps/scripts that you’ve added in addition to your WordPress installation, this is rare so you would likely know if you’ve done this. If you have, be sure to migrate those too. If you’re unsure, then reach out to the person who developed your site, as they might know or can help you find out. As a last restore, you can look in the sites file system and see if there are any additional non-standard WordPress directories or files. WordPress only has three directories: /wp-admin, /wp-content and /wp-includes, and then a about a dozen or so other files.

As mentioned, most migration plugins would take care of steps 2 and 3. Once the files are copied over and put in the right place, then on to inspecting the preview. Fingers crossed! Let’s see how it looks.

It’s important to preview the copied site before going live, so you can test it thoroughly and ensure all the pages, forms, calendars and all other features of your site function as expected.

If you’re asking, “how can I see the copied site if I haven’t changed my DNS?”, there are actually several ways!

1. *Alternate/Temporary URL: Your new hosting service might provide you with an alternate URL to view the site. This usually might look something like johndoe.newhost.net. Check with your provider to confirm. It’s likely preconfigured and ready to use!
2. *Use a subdomain: You could actually use a subdomain of you main domain! Let’s say your main domain is example.com, then you could create test.example.com and configure that at your new host. To configure it, just repeat the same process in step 2 of this guide!
3. The hosts file trick: This is highly preferred by advanced developers. This one isn’t too tricky, and it helps eliminate the need for a search & replace (S&R) in the database. In summary, the hosts file trick is a configuration adjustment on your computer that tells your browser to bypass public DNS and route your domain to another server. Just don’t forget to unset this right before step 8 of this guide. If you know you’re going this route, then ensure your migration tool/process doesn’t perform a S&R to an alternate domain.

_{*Options one and two require a S&R in the database to update the WordPress URL’s from your primary domain to the preview domain. Depending on how the site was migrated, this may or may not have automatically been done.}

If you need to perform this search & replace manually, you’d have to do this with either SSH/wp-cli or some phpMyAdmin wizardry. Or, I’d recommend seeing if your hosting provider could perform this for you. Note that most hosts aren’t so friendly with this request, so be prepared for the alternatives. With options 1 and 2, you can’t use a WordPress S&R plugin for this, since you can’t access the WP Admin (unless you use the hosts file trick).

If you manually imported the database yourself, and the preview site shows a database connection error or shows the WordPress installation wizard, then there may be a misconfiguration somewhere in the /wp-config.php file, perhaps the database prefix may simply need an adjustment. If you can’t figure it out, try getting with your hosting provider’s support team to see if they can help troubleshoot that with you.

If the site is having strange errors on preview, the first thing I recommend checking is the PHP version, and make sure the new server matches the old server’s version (or higher, if possible). With each higher version of PHP, often times comes with improved site performance. Your site might not be compatible with it yet, likely due to an outdated theme or plugin, but it’s worth testing!

Some themes or plugins, especially some paid/licensed plugins or visual builders, don’t play nice after being copied and previewed on an alternate domain. If you can tell they are having trouble, be prepared to reach out to their support for advice on handling a migration/preview. Usually, previewing the site with the Hosts Files trick minimizes these occurrences.

But once you’ve confirmed the copied site is looking good, then you can move on to the next steps. Take note of any site specific configuration changes you had to make, as you might need to do those again after the second migration. Though any server side configurations you made will likely stay configured, so you won’t have to readjust those after the migration. In fact, consider performing the site copy a few more times, so you can practice and get the hang of it. Creating that muscle memory can help the final migration go smoothly and quicker!

Why is a second migration needed? If you aren’t overly concerned with downtime, or having to potentially do extensive troubleshooting after going live, then you can possibly skip that and several other steps.

An additional/final migration is mainly needed if new content has been added to the live site since the first migration was performed. This is especially true for eCommerce sites, highly active blog comments, user based content uploading, LMS student progress tracking, and on and on. If you don’t do the second migration then the site will lose all the new data added to it since the first migration completed.

You know your site best, and should know when new content is added to the site. If your site is simply informational based or static, and offers no user submitted content (including contact forms), then you can choose to skip the second migration.

But for those who need to ensure no loss of data, scheduling it for another time is the professional way to do it. You can add a banner to the live site days or weeks in advance, alerting your visitors of upcoming “maintenance”, with the specific date, time, time zone and estimated maintenance window. Perhaps encourage your visitors to subscribe to your social media pages so they can stay updated in case the migration goes longer than expected.

Now if you’re either a one-person show, or if you have a team of IT, Dev’s and Network Admins, coordination is important! When is the best time to schedule it? Typically during the site’s known lowest traffic times. For most sites, this is during the weekend or late in the evening.

Crunch time: Ready to do this?

We talked about this shortly above, when scheduling the time to migrate. If you’ve put a banner notification, then you should follow through and cut off access to the site.

This can be done in numerous ways, but here are two of the most common I’ve seen.

1. The most suggested way is to use one of dozen’s of “Coming soon” or “Maintenance Mode” plugins! Some typically let you customize the maintenance page, so you can use your desired wording and even match your sites theme.
2. Another quicker, though sloppy way, is to disable access by putting the site under password protection, such as BasicAuth. What this does is prompt any visitor to the site to enter a username and password before they are allowed to view any page on the site. When they enter the wrong credentials, or try to close the popup prompt, they will be shown a 403 Forbidden error.

But once you’ve got that configured, this is it and the clock is ticking! Time to start the final migration.

Note that with the site in maintenance mode, one could argue that the site is having downtime. Certainly a technicality, but this is necessary planned downtime, which is much more easier to swallow than unexpected downtime. It’s better to have brief planned downtime than extended downtime due to overlooking an important step in the migration process. With so many moving parts and possible points of failure, determining what went wrong can be time consuming to troubleshoot.

Hopefully you’ve got this process down packed, since you did it at least once. For WordPess sites, you only need the /wp-content/ directory and the raw SQL database. If you’re manually migrating the site, then put those files in the proper place!

Depending on how your first/test migration(s) went, you may or may not need to preview the site. If you’re that kind of risk taker, then ideally a search & replace (S&R) won’t be needed, as you should leave the raw database configured as-is; with your primary domain already set in the database. (If you’re using some sort of migration tool, don’t allow it to automatically S&R your primary domain to the preview domain, if possible.)

If you do need to preview your site (recommended), then it’s best to do it with the Hosts File trick, so that you don’t need to run a S&R. Test out the site as needed. If it’s looking good, we’re at the home stretch now!

Just remember, if you’re previewing the site via search & replace instead of the hosts file trick, then don’t forget to perform the S&R in the database back to your primary domain before flipping the DNS. Important Note: When doing the S&R, it’s extremely vital to ensure the primary domain matches exactly as before. Is your primary domain with or without www? If you set the wrong one, this has been known greatly impact SEO, negatively.

Before flipping the DNS, Leave a bread-crumb

Finally, leave a bread-crumb on the migrated copy of the site! This will help clear the confusion of which copy of the site you’re seeing during and after the DNS propagation. You can leave a bread-crumb in many ways, but here are a few suggestions. Just remember to add your bread-crumb(s) before flipping the DNS and only on the copied site at the new host.

1. (Best way) If you had put your live site in maintenance mode, then that setting may have came over during the migration. Disable that setting on the copied site!
2. Create a new draft post in the WP Admin on the copied site. This works well for your visual confirmation, but not easy to test on a proxy site since logging into WP Admin is necessary.
3. Or add a simple HTML file to the sites file system, only on the new host. Maybe name it /propagation-complete.html, or anything you’d like. This is more easy to test on a proxy site, since you don’t have to log into the WP Admin to view it.

Now it’s time for step 8: flipping the DNS! Excited yet?

Below in step 9, I’ll go over some DNS tests you can run to get a picture of how the propagation might be going.

It’s time to finish this! Now get ready to point your DNS from the old host to the new! There are two ways to go about this. Either you’re simply editing a few existing DNS records, or you’re changing the nameservers. So get your new DNS records from the new host and let’s go live! If you’ve been doing the hosts file trick to preview your site, this is the time to unset that.

When changing the DNS, it’s ideal to follow the advice and directions of your new hosting provider. Be sure you’ve had a conversation with either your new host or your IT team to ensure email won’t be impacted when the DNS is flipped.

1. If you’re keeping your existing DNS provider, meaning you are not changing the nameservers, then this usually has a lesser chance of impacting your email routing. However, cPanel hosts are exception, due to default DNS configurations, specifically with the MX Record.
2. If you’re changing your DNS provider, meaning you will be changing the nameservers, then this typically has a higher probability of impacting your email routing. Get with your new DNS provider to ensure your MX Records are preconfigured for your email host, before changing the nameservers. Though if you aren’t sure what your MX Record(s) should be, then reach out to your email provider first to confirm what they are.

But now that the DNS has been changed, the propagation begins. Are you holding your breath?

“If I migrate my site and there is zero downtime, then how would I know I’ve transitioned?” Unfortunately, there isn’t a magic notification that indicates DNS propagation has passed for you. You have to verify manually, but I’ve got several ways you can check this!

There are two categories of confirming DNS resolution: affirmative and supplemental. The difference between the two is that affirmative assures propagation has passed for you, while supplemental suggests it has passed for other regions of your country or the rest of the world.

Affirmative resolution

1. Did you leave a bread-crumb, as suggested earlier? If you can now see the bread-crumb on your live site, then propagation has passed for you! It’s almost time to celebrate!
   • With the bread-crumb(s) you left behind in step 7, you can test how the propagation is going for you. If you don’t see your new draft post, or if the new HTML file is showing a 404 Not Found, or if maintenance mode is still enabled, then your internet connection is still going to the old hosting server. Try one of the supplemental resolution checks below to ensure your DNS changes were pushed out properly by your DNS provider. If the DNS transition is looking good, then just wait it out! This is a classic symptom of DNS propagation. It’s come a long way in the past 10 years, and it’s gotten faster! However, even today there are still encounters of random hiccups that cause delays. This isn’t uncommon and no need to panic.
2. Use a browser extension, such as Website IP. It’s a simple script which displays the IP of the current website you’re visiting in the bottom right corner of the browser window. It’s very unintrusive and easy to disable when you don’t need it. If you still see your old server’s IP, then this is a good indication the propagation hasn’t passed for you yet.

Supplemental resolution

1. Perform a public DNS lookup of your domain! This is easy and there are tons of online tools that can run this check. These tools are useful to get an idea of how the propagation is trekking along, world wide! Here are just a few I like to use:
   • Use DNS Checker or What’s My DNS for a global visualization of Propagation. These are great tools!
   • Use Leaf DNS or intoDNS to see the detected Nameservers and a robust report of various other DNS records they check for.
2. Test your site in a proxy site! You can think of a proxy site as like a browser within a browser. What the proxy site does is uses its server to go lookup a site, and then it shows you what it sees! There are some decent free proxy sites out there to do a quick test. This is most useful by testing to see if your bread-crumb is detected.
   • kProxy
   • GeoPeeker

While proxy sites and DNS lookups help confirm what the rest of the world is likely seeing, those aren’t a true indication that propagation has passed for you or anyone else. The bread-crumb method is your sure fire way to know when propagation has passed for you. But doing both affirmative and supplemental checks are great to clear up any doubts that DNS is configured properly.

After propagation has passed for you, is it possible there are some site visitors still being routed to the old server? Absolutely! Is there anything you can do about that? No. It’s another classic phenomenon of DNS Propagation. It is out of anyone’s control, but eventually their ISP networks will start routing them to the new server. Could be 10 minutes or 10 hours.

But fingers crossed, you can see the site on the new server now. As a best practice, try to test out all the pages, form submissions, eCommerce purchases, and other custom functions on the site and confirm they are working. While this should have already been tested before flipping the DNS, it’s ideal to be extra sure if your livelihood depends on your site. But fingers crossed, you won’t see any unexpected issues.

Congrats on completing your downtime free migration!

Download the PDF file below, or go to the online JotForms file! Note that the PDF checklist may have a few things in a different order when comparing to this article. In the end, as long as certain tasks are done before the final migration starts, it’s perfectly fine that some of those tasks are done out of sequence.

---

I hope this information is clear and helpful. Please don’t hesitate to let me know if you have any questions, concerns or new info I should add to this post. Simply leave a comment below or hit me up on Twitter.

If you found this post was of use to you, check out another post of mine about a fairly new WordPress plugin that can diagnose your sites performance quickly, robustly and for free! I believe this new project will catch on soon!