At face value, moving a site from one host to another may seem pretty straightforward. Depending on what kind of site you’re talking about, this could be a bigger task than you’d expect. I just recently moved a site to a new host and ended up learning a few tricks that could hopefully help you down the road. To begin you’re going to need some basic access to the site in question. In my example, I’ll just be focusing on a WordPress site. A lot of these concepts and ideas can be carried over and applied to different sites of course, but there are some WordPress specific things to keep in mind when it comes to migration. WordPress can be a little, shall we say… “WordPressy”.
Step 1: Buy Hosting
This one may seem pretty obvious, but you’re going to want to secure some hosting in order to transfer your site to… well, somewhere. There are a few things to consider when going for hosting, and the type of site you’re migrating is going to have everything to do with the type of hosting you choose. If you’re migrating a WordPress site, then it would definitely make sense to go with a host that specializes in WordPress hosting. If you’re moving a site that is absolutely mission-critical and cannot afford any downtime whatsoever, then you’ll probably want to consider some dedicated hosting. Dedicated meaning you’re the only one on that server. If it’s more of a lightweight site that doesn’t demand a lot of resources, or if it’s more of a recreational site that’s just for fun, or if it’s just an experiment or something, then shared hosting makes more sense. Point being, get some hosting for your site, so you’ll be ready to start the migration.
Step 2: Consider the Site’s Needs
This kinda goes hand-in-hand with considering the type of hosting your site needs, but this step will focus more on what exactly the site in question is doing. What purpose does this site serve? Is it a blog? Is it a portfolio? Is it an e-commerce shop? Those questions will determine your next steps and how you should move forward.
Once you’ve answered that first question, you’ll need to think about this: What is currently happening on the site that will need to continue happening? For example, if this is an e-commerce shop, are there active customers with a purchase history? Are there active subscriptions with a regular, automated renewal date? Think about all the stuff that will continue to happen on that site as time goes on.
Step 3: Make a Full Copy of the Site
There are quite a few variations and sub-steps associated with this step, but the main objective is to make a full copy of the entire folder structure of the site all the way to the root directory, as well as exporting a full copy of the database. Those steps look different for different websites, but those main concepts remain the same.
For this example, we’ll focus on a WordPress shop. If you’re migrating to WPEngine, they make a great little plugin that does all the heavy lifting for you. Else, if you’re migrating to another host, doing a manual migration isn’t awful, but there are some critical things you’ll need to keep in mind to keep everything working and minimize downtime. However, just keep in mind, as a general rule, any migration of any kind will absolutely result in some downtime at the very least. The trick is to minimize that downtime and perform the migration at an off-hour when traffic is at the lowest.
Step 3a: Export Your Database(s)
If your current hosting provider gives you access to a cPanel, then you’re in business. From cPanel, navigate to PHPmyadmin, select your database(s), and export. If you’re working with MongoDB or another database, I’m not gonna lie, I’ve not exported databases from MongoDB before, but I’m sure it’s nothing StackOverflow can’t handle.
Step 3b: Download Your Folder Structure
Next, log into your backend via your favorite FTP client, and download your entire folder structure.
Step 4: Create an Empty Database and Assign User
If your new hosting provider gives you access to a cPanel, then awesome. From there, you should be able to easily create a new SQL database, create a new database user and password, and assign that user all privileges. If you have a password manager, you’ll want to use it to store these database credentials. You’ll need them for later.
Step 5: Upload Your Folder Structure
Once you’ve purchased a hosting plan with your preferred provider, you’ll have access to the server via some protocol (likely FTP or SFTP). Once you have a username and password for your FTP connection, go ahead and log in, and begin uploading the folder structure you just downloaded. Depending on the size of your site, this may or may not take quite a long time.
Step 7: Edit Your wp-config File
Now, dive into your wp-config file and modify the lines that define your database name, the database user, and the database password.
define( 'DB_NAME', 'your-database-name-goes-here' );define( 'DB_USER', 'your-database-username-goes-here' );define( 'DB_PASSWORD', 'your-database-password-goes-here' );
Step 6: Import Database
At this point, you’ll need to log into your freshly created database and choose “import”. Feed it the .sql file you received when you completed Step 3a.
Side note: if you have issues at this step, double check your PHP settings. Sometimes, if your database is massive and/or your max_post_size, upload_max_filesize, max_execution_time settings don’t allow enough memory or time to complete the import, the import will fail. These settings can be changed in several places, one being your wp-config file, (since you’re probably already in there)
Step 8: Update Your DNS
Now that you have two working copies of your site on two separate servers, the next step is updating your DNS. This will point your URL to the new server. Depending on your DNS provider, this could take anywhere from 10 minutes to 24 hours. Once the DNS updates and propogates across the internet, you’re ready for the next step.
Step 9: Assess The Situation
At this point, you should have two working copies of the same site on two separate servers. If you’re running WordPress, there are a number of plugins (like Jetpack and WooCommerce Subscriptions) that will recognize when they are on a duplicate site. A really cool feature of a lot of these plugins is that if they detect a duplicate site, they will disable themselves on duplicate sites. This will help mitigate the risk of duplicate sites running in parallel and doing everything twice (like automatically charging subscribers when their subscription is up for renewal)
Depending on what your site is doing (especially automated tasks), it might be a good idea to shut it down ASAP before the old server has a chance to run automated tasks in parallel with the new server.
Step 10: Make Sure You Have a Local Copy
Depending on how you completed Step 3a and 3b, you may already have a local copy of your site. Some site migrations can happen directly between two remote servers (for example, if you use the WPEngine plugin, you won’t have a local copy). This goes for your database as well, don’t forget your database!
Step 11: Cleanup
Now that you have a local copy of your site, you can safely delete the site from the old server. This will prevent any potential issues with running duplicate sites on the internet, regardless of DNS.