Your final sync has been finished, DNS has been updated, and you are live and kicking on your new server. Congratulations!
But you aren’t done!
There’s a host (pun intended) of important considerations for your new servers that you should attend to as part of your migration, since they are time sensitive. I have seen many people disregard these critical facets of server ownership, either because these topics don’t make any advantages to the way the client’s applications work, or the subjects aren’t directly in front of the client all the time.
Security
Arguably the most important consideration for your server, after its core functionality of serving sites, is its security. You should ensure your firewall is functioning and catching brute force access attempts, as well as blocking malicious scripts or scrapers.
For cPanel and Plesk machines,
ConfigServer Security & Firewall is the firewall and plugin of administrators around the world, and it also includes a brute force detection daemon, LFD. Management is simple through the WHM plugin.
You should also switch up your SSH port, set up a sudo user, and turn off direct root SSH access. These few quick steps, along with using good long passwords and keeping your system and applications up to date, will avoid most attacks. Hackers see a lock on a door (your server), and unless they have a very good reason to get in, they move on to a door with a simpler lock, or no lock at all.
Backups
In my opinion, security is second fiddle to backups. If you have great security but get hacked anyway, and have no backups, then sorry about your entire business.
There should be two types of backups you keep: the ones you use to restore files you accidentally overwrite, and the ones you use to restore the full server in case of catastrophic failures or system upgrades gone awry.
cPanel and
Plesk both have local and remote file backups of the first variety built-in to their parent panels, with adjustable retention as well! Make sure you
turn these on, since its basically free insurance, other than the disk space you use for the backups.
For the second type of backups, the full server kind, you’ll probably want to check with your host about server backup services they offer.
If you are spinning your own full server backup solutions, I’ve used
Idera/r1soft,
Bacula,
Burp, and a plain old
rsync script with good success for full server backup and restoration. Each solution has its advantages for setup difficulty, overhead, price, versioning and retention, and detail of backups. Many also allow you to dial down to a single file or database restore.
Consider local and remote disk space for your backups as part of your initial plan. You want enough free space to keep several versions, in case it takes time for you to realize a mistake or hack.
Monitor your backup solution, and TEST it a few times a year. Many people run backups successfully, but don’t realize that they aren’t actually successful until they need them, and find out they were invalid the whole time. Try a restore of a single file or database to an alternate location to make sure the system can recall data, or if you can, a full server restoration to an alternate host or server to make sure the restored OS boots and functions.
Can you tell I used to work in restoration?
Old Host Termination
Unless someone is driving you out of your old server with a ticking time bomb, no one is going to approach you to destroy the old server. Your host has no idea if you have sites resolving to it or not unless you tell them; many servers have no public sites whatsoever and have alternate roles in the web structure. Make sure you unrack, reclaim, decommission, spin down, whatever you have to do to the old machine, because servers are expensive, and you don’t want to have to pay for a server that isn’t doing any work.
