Panel less migrations
As we all know, server migration is the process of moving websites hosted on legacy systems to more robust and feature-rich systems. In most cases both the source and destination servers are installed with some control panels and many of these control panels provide tools in order to do this migration automatically. But there are times when we come across situations where both the source and destination servers are not installed with any control panels. Hmm, getting worried? No fear. I’ll guide you through this process and it will be as easy as breeze (well, literally!).
# Configure destination server prior to migration. We need to manually install all the required software on the destination server (Either using rpm or from source).
# Install PHP/PHP modules. Compare PHP modules in source and destination servers using an info.php page and make sure that the source and destination contains same version.
# Compare the Perl versions on source and destination server and install the required Perl modules on the destination server.
# If there is a private network configured in the servers, that would be the best to use for the migration. This is because the migration process will be faster and the data transfer between the source and destination servers will not come in the bandwidth utilization of your account.
# For a fast DNS propagation, change the TTL value to 10 minutes at least two days before the migration.
# Do Migration (You can use the rsync command in order to migrate data) and monitor the destination server for a week.
What to migrate
1) Apache configuration
2) Migrate users and user Home directories
3) BIND configuration
4) MySQL data. (You can use the ‘mysqldump’ command in order to take the backup of databases), also the database permissions.
5) SSL certificates
6) User crontabs (Located within the directory ‘/var/spool/cron’)
7) Other Configurations files inside /etc/
-> Make sure that a backup of the current users and passwords on the destination server is taken before proceeding with the migration.
-> Take a backup of the important files in ‘/etc’ on the destination server so that even if something goes wrong, one would be able to revert the changes.
-> If possible get a KVM (Contact your DC or Hosting provider for this) connected to the destination server so that even if SSH connection brakes, we can access the server to make the necessary changes and bring it back online.
-> Never migrate until you have changed the TTL to a smaller value (say 10 Mins) at least two days before the migration.
-> After migration monitor the destination server for a week. Do not take the source server down for this period.
Hope this article makes the ever daunting task of migration a lot easier for you.
About the Author :
Unnikrishnan works as a Senior Software Engineer in Bobcares. He joined Bobcares back in Oct 2008. During his free time, he watches movies, and listens to music
Co-Authored by Sankar.H