We’ve recently completed some work migrating a few WordPress sites for clients. Having reached the limits of their shared hosting environment, they wanted the flexibility of their own dedicated virtual server. (Yes, I’m aware that “dedicated virtual” is an oxymoron.)
Now, this isn’t a polemic against WordPress. Their vast array of modules, templates and add-ons makes for some pretty good sites. But be honest: how many of you bought your company’s web packages through GoDaddy, or Crazy Domains, or some other one-stop-shop for all your internet needs? These service providers make for a good, easy place to start developing your internet presence, but they’re neither the most effective nor the cheapest solution.
Eventually, you may reach the point where you want to keep your WordPress site while divesting yourself of the rest of the associated baggage. However, picking up and moving your WordPress site to a whole new hosting server isn’t just a matter of snapping your fingers and calling it a day.
Here’s a short overview of some of the pitfalls, great and small, that you should be aware of if you decide to migrate your WordPress website (or other-CMS website) to your own server.
Why run your own server?
There are a few reasons you might want to migrate away from shared hosting. Let’s run down the big ones:
Cost
Nowadays, with cloud providers offering cheap and reliable virtual servers, it can be a no-brainer to switch – provided that you’re comfortable with the ins and outs of server administration. In one of our recent projects, the client wanted to move their data onto Amazon Lightsail, but there are many other cloud providers that you could use; Digital Ocean, Linode, Google Cloud and Azure all have similar offerings for virtual servers. In fact, your site is probably already running a virtual server, that’s shared with many other customers.
The reality is that your local mom-and-pop hosting provider can’t compete with these big companies on cost. On the flip-side, you’re unlikely to be able to just phone up Amazon and get an answer when your site goes down, unless you’re paying for that support.
On the other-other-flip-side (how many sides does this coin have?!), big providers are less likely to have network issues, and the standardisation of services makes it a lot easier to find a specialist third-party consultant that can fix problems on your standard-issue server.
You can even cut more costs by using LetsEncrypt for a free, zero-maintenance and perpetual SSL certificate.
Customisation
Aside from the cost savings, the customisation opportunities are endless. Shared hosting setups usually only allow for a small range of FTP users and databases, to keep things quick and simple for the uninitiated. With your own server, your options are virtually unlimited.
You can set up your own cron jobs to automatically make changes to your website, or use your server’s firewall to block access from specific countries. If there’s a new version of software that your shared hosting provider hasn’t installed, don’t worry; you can set it up yourself.
You also don’t have to worry about other customers’ bad coding choices affecting your site. And, there are plenty of options to monitor your own server so you’re notified if it’s getting slow – your shared hosting provider would be the last one to tell you about problems they’re experiencing.
Expansion
So what can you do if your server is starting to get slow? Once you’re on a cloud platform you can start leveraging their size and utilising other parts of their ecosystem. Need a bigger server? Just push some buttons and spin up a faster one.
Being hampered by your database using all the resources on the server? Try running it on your providers dedicated database service instead. Need load balancers, external caches or message queues? Chances are Amazon or Google’s offerings will scale beyond your wildest expectations.
Sounds great! What’s the downside?
It’s not always calm sailing when migrating; while the move itself is a one-time challenge that can be handled cleanly and professionally (that’s what we’re here for, after all!) there are lots of little details that need to be handled during or after the move, things that can go unnoticed if you don’t know what to look for.
Here’s some of the issues you should be prepared to handle when moving providers.
You’re responsible for your own security
Shared hosting providers (should) have the security of their sites at forefront. They will have countless clients running WordPress and know the settings that they’ll need to apply to secure the installations.
When you migrate the files across to your new server, you might not also copy across the correct permissions settings, which could mean that attackers have the ability to execute things that they shouldn’t. For example, PHP files inside the wp-uploads directory shouldn’t be allowed to be executed – but execution permissions are left on by default and need to be corrected manually.
The Apache web server also has directory listing turned on by default, which can let people browse things they shouldn’t.
If you’re not sure about the ins and outs of securing WordPress, you can have the Sucuri WordPress Plugin do most of the work for you. It will scan and audit your site, spotting malicious files and even changing server configurations with .htaccess files automatically.
Make sure securing your site on the new server is one of the first things you do.
Your outgoing email will break
If your WordPress website sends email, beware! To prevent spam, many cloud providers prevent SMTP connections except to their own email service. For example, AWS instances can only connect to Amazon’s own Simple Email Service (or SES).
In contrast, WordPress uses the PHP mail function by default, which sends email through your server’s MTA (Message Transfer Agent). If you transfer your WordPress site onto a new server without changing the default settings, your server will then attempt to deliver straight to the recipient – at which point it will be blocked by the new provider.
There are a few options to correct this:
Reconfigure the MTA on your server to use a relay host. Any message triggered by your server will then go through that SMTP relay (for example, the SES server for AWS). This is the most technically sophisticated method of correcting the issue, but guarantees the best results.
Set up a plugin like WP Mail SMTP which will let you configure WordPress to send through an arbitrary SMTP server. You’ll need to install and configure it on each WordPress site on your server. This is easier that setting up and running your own MTA but you have to remember to configure it for every site you migrate and it won’t help with other sites (PHP or otherwise) that need to send email.
Consider a non-SMTP method of sending email. Services like MailGun or SendGrid allow you to send email through them using their HTTP APIs, forgoing SMTP connections all together. They provide WordPress plugins for configuration.
It’s not a difficult problem to solve, but you should be aware of it before you make the transfer and suddenly find that none of your emails are sending!
You have to set up your own backups
Shared hosting providers usually have backups. Sometimes you have to turn them on and pay for the privilege. Even if you don’t though, sometimes you can get lucky and your provider will take pity on you and pull from their own backups for you.
But as we mentioned earlier, good luck getting Jeff Bezos on the phone to recover a deleted file! You’re on your own, but that’s OK. Since you have your own server there’s many ways you can set up backups. That being said, be aware of their limitations.
For example, with Lightsail, you can have an automatic snapshot of your server taken every day. This is as simple as clicking a checkbox to enable. But you can’t use that snapshot to restore individual files into your server, and you can’t just “roll back” to that snapshot. You’d need to set up a new Lightsail instance from a snapshot, then update your DNS settings to point to it. It’s easy to set up but hard to use for recovery.
Some other options to consider are:
automatically backing up your web server directory to a file storage service (like S3, or your provider’s equivalent). This would be for disaster recovery, in case your server were to get hacked, for example.
periodically make copies of the web root into another location on the server so you can quickly recover files that are accidentally deleted.
Since you have your own server, the possibilities are endless.
Database backups need to be done as well – dumping out to a SQL file and copying to the cloud file store is the most common way of doing this. If you’re using a managed database outside of your server, such as RDS, be aware of the snapshot process. As with Lightsail, you can’t just roll back to an RDS snapshot. You must create a new RDS instance from the snapshot then update your configuration to point to the new database.
Whichever method you choose, make sure you test the backups to make sure they work, before you need them!
Will there be downtime?
Executing a seamless migration is very much a “measure twice, cut once” prospect. If you plan and execute the migration correctly, you can indeed move your site with no effective downtime. This is dependent on the behaviour of your site, though. The better question is, will there be any visible downtime for your end-users?
It’s relatively easy to keep a site up and running while it’s being migrated, especially if your site is more “read-only”, but on other sites, some activity may go unrecorded. Here’s an example: if you have a lot of people making comments on your posts and your website stores them in your own database (instead of using a third party service like Disqus), then there’s a risk that comments made during the migration will go unrecorded. But with the appropriate provisions in place, you can set up the site to record those comments and upload them after the migration, in order to prevent that content being lost.
Again, planning and preparation can allow for a seamless migration.
Planning to make the move?
Do you like the sound of running your site on your own private server? At Tera Shift, we’re no strangers to site migrations. Whether big or small, we can plan and execute a migration plan to get your site moved over with no downtime, and even provide aftercare if you’re concerned about long-term issues or interested in expanding your site’s functionality. It may seem like a daunting prospect, but migrating your WordPress site can bring benefits to your company for years to come.