How to Migrate Magento Website from One Server to Another Server

Migrating Magento site is probably the most complicated pieces of web related software, and many times magento developers get happy when they come to a point where things start working. You can imagine the horror magento developer is up against, when a few weeks before the holiday season, Google Analytics gives an indication that current hardware infrastructure just won’t work. Additionally, you will be provided with some pointers regarding DNS changes required for pointing your domain to another IP address.

Preparation for transfer

The process of moving an e-commerce sites that can be easily expressed regarding lost revenue, and this is what all the developers must be aware of. With the course of moving any site to the new server, there is a process of downtime by changing IP address in the context of DNS change. This downtime is unavoidable and not directly under control, so, you must lower the amount of time taken during the transfer of code and database to another server. The core to achieving fast and effective Magento transfer is in the process.

Establishing connectivity

The first step to our goal is tweaking. Open SSH on source and destination server to allow the secure data transfers without the requirement of user account passwords. We will accomplish this using Public-Key Authentication. Target user accounts on both of your servers have private-public key pair generation. If the .ssh directory of a user account is empty or non-existent, you must generate private-public key pairs yourself. Creating password-less is something that isn’t recommended, but for the simplicity, this is what we will do here using the ssh-keygen command. The command should be executed on every server without any private and public key pair:

Ssh-keygen -q -t RSA -N ” -f ~/.ssh/id_rsa

The destination user accounts at the two servers must have .ssh directory under their home and inside two files named. The first file is the private key and the second file is the public key. To achieve password-less connectivity, you must install each server’s public key to every other remote machine’s authorized keys file.

If you can connect through ssh from your source to destination server and vice versa without asked for a password, you did the right thing, and you can proceed further. If this isn’t the case, then retrace your steps, especially the permissions part.

Configuration Server

This is one of the most time taking field that depends mainly on the Linux distribution, the web server of choices such as Apache and Nginx, and infrastructure configuration of the number of servers involved and this is something that should be done by your client’s.

Let’s talk about Hosting Company and thus cover the creation of Magento database on the destination server. Let us assume that you do not have access to phpMyAdmin on your target server, so let us see how to do this right from MySQL client console.

The first step, decide on the database name, the name of the user and password. After doing this, document the key pieces of information. Next thing to do is open MySQL client from your destination server as an administrative user and create a new user and associated database by assuming that you know how to start MySQL client.

Creating automation scripts

The general idea is to design and thoroughly test two shell scripts written in bash with the goal of automating key parts of the transfer and eliminating human error from the equation. The crucial thing to see is that these scripts should not be taken as they are, or use them as starting points for developing scripts tailored.

The first script has the purpose of doing the sync of codes between the servers and should be executed while the site is still up.

This script requires following data

• SSH data for source server. We do not need a password because we have configured Public-Key Authentication.
• This is the exact way for web server document on source web server and destination web server.

We will select sync over SCP due to the possibility of incremental sync used later on. The second script is much more complicated as it is intended to be executed after Magento store is placed in a maintenance mode. We will name this script magento-transfer-2.sh.

Does incremental resync of Magento code from the source server to account for file changes that occurred after you have executed magento-transfer-1.sh

Creates a list of additional tables to ignore and feeds this to MySQL dump to speed up the process. Remember that this list isn’t as restrictive as when doing developer database dumps as we’re talking about production database and customer quotes.

The database is Mysql deposited in two steps, first structure and then data. The main reason for this is to avoid a situation where table directives affect structure and data, which causes missing tables on the destination server. After MySQL dump, structure and data are united, compressed with gzip and sent through SSH tunnel. On receiving side data zipped, and trigger defines are fixed by replacing trigger set with name and values of the new Magento database. This is one of the fastest ways to transfer large database as we’re avoiding unnecessary disk writes involved when you first do MySQL dump then import, as well as manual labor.

• SSH data for source server. We do not need a password because we have configured Public-Key Authentication.
• The absolute path to web server document root on source web server.
• The main path to web server document root on destination web server.

MySQL database data for source server. In case you were using separate DB server in the past, you should adjust the SRC_MYSQLDUMP_HOST variable. MySQL database data for the destination server. If you are going to use different DB server in coming time, then you should adjust the DST_MYSQLDUMP_HOST variable.

Transfer

This chapter is all about what the previous section was. It’s time to place your store in maintenance mode. What you have to do is update Magento configuration and update DNS records with our destination server IP address.

Using automation scripts

The first thing we need to do is to take our automation scripts to the target server. To complete this task, you can use SCP. As far as location on the target server is concerned, it is recommended to create a directory named bin inside the home directory for your user account. The reason behind this is that all Linux distributions such as home and USER bin directory are automatically added to system PATH. This makes it an ideal place for dumping shell scripts.

Adjusting Magento environment

After you have transferred your Magento code, files, and database to the destination server, you must do two things. The first thing you need to do is edit your app with the new database name, user, password and new DBMS host in case you are using dedicated DB server.

The second thing is to configure crontab on your new server’s user account so as to trigger Magento cron. To avoid file permission issues, you are advised to run Magento cron from crontab belonging to the user that your Apache or PHP-fpm instances are being started, but this is outside of scope. Transfer all crontab entries from the source server and the changing crontab is done using “crontab -e” command that is the account for possible changes in document root on the new environment is viewed using “crontab -l” command. Crontab editor is Vim so if you are not that good with its insert, save and quit controls, additional instructions are so easy to get on Google. And, now is the time to configure things like Solr search, APC, Redis, Memcached which is outside of scope for this article.

Final testing

Here at the point of final testing, your destination server should have both files and database and have its configuration adjusted to host your Magento installation. This means you should do some testing to check that everything is in order before instructing your registrar to point the domain to new server IP. For you to be able to do any testing, you need the assistance of your development system hosts file to point your domain to a new IP address for the purpose of texting. Example of data entry to instruct the development system for look up example.com at X.X.X.X IP address would be: X.X.X.X example.com

Now you can navigate back to your store from your development machine and browse around. Try logging into admin and other such things. If the site isn’t loading, inspect the Magento exception, system log, system reports and finally your web server software file will open. Once you get everything in order, it’s time for you to proceed to change DNS records.