Magento store migration procedure

So you’ve made the decision to move your Magento store? But there is one large caveat, the store is currently trading and downtime isn’t an issue you want to run in to.

We try to make migration painless and ensure downtime is at an absolute minimum, this isn’t an overnight process however and we always reccomend starting this process around 1 week prior to the “big move”.

We can also conduction a downtime-free migration (bypassing DNS propagation times) if we can gain root access to your existing server.

Eg. We are going to move

Stage 1

You will need to make your first change at the name server level, this can be found by “dig” ing the URL

dig ns

This will give us a result

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7403
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0


;; ANSWER SECTION: 171994 IN NS 171994 IN NS 171994 IN NS

;; Query time: 7 msec
;; WHEN: Tue Oct 26 10:42:16 2010
;; MSG SIZE rcvd: 77

Now we know that the DNS servers in control of the Zone File for this domain is

Stage 2

At this point, we’ll enter the control panel for the DNS and change all of the TTL (time to live) values to be an obscenely low value. This value defines how long the record is “valid” for, before a caching DNS server should update its records. The value is in seconds and by default, will be 24 hours or 86400 seconds.

We plan on lowering this to be 600 seconds, which is 10 minutes. Which means, in an ideal world, the DNS records will be updated every 10 minutes.

But because the current TTL’s are 86400, we know it is going to take at least 24hrs for any caching DNS servers to update their records. But not all DNS servers pay hard and fast attention to the TTL’s set, nor do they update their records – so unless a user has requested your domain through their ISP’s DNS server, it is likely that the ISP’s DNS server won’t update its records from that of the root servers. This can mean that propagation can take longer, usually, 72 hours.

After lowering the TTLs, the aim is to reduce that 72 hour update window to 10 minutes, but we have to wait at least 3 days before we can carry out the next step.

Stage 3

If you are moving your nameserver control to Sonassi Hosting, then you will need to carry out this step, otherwise it can be ignored.

You now need to replicate the contents of your current zone file to Sonassi hosting. This involves re-creating all A, NS, CNAME, Wildcard, PTR, TXT and MX records to match what the current nameserver’s have.

Once this has been completed, you will need to log into where the domain itself has been registered, then change the nameserver’s to Sonassi Hosting’s nameservers.

After making this change, we wait 3 more days to ensure the new records have correctly propagated.

Stage 4

By this point, either 3 or 6 days should have passed, depending on whether you were moving the nameservers. It is time to make a copy of the code on your new hosting account/server with the latest database dump (merely for testing purposes).

Creating a TAR file is the best means of migrating the initial data set. In our case, our files are kept at /domains/, so we would run

cd /domains/
tar cvfz ../http.tgz ../http --exclude=var/log --exclude=var/session --exclude=var/cache --exclude=var/report --exclude=media --exclude=*.gz --exclude=*.zip --exclude=*.tgz --exclude=*.tar --exclude=var/import --exclude=var/export

The resulting file http.tgz would then be transferred by FTP or SCP to the new destination. We always use SCP if it is available, as the bandwidth of a web server will generally far exceed that of your local connection. Running the following for SCP will move the file to the new destination (in this example, is our new server’s IP)

From the old server

scp http.tgz exampleuser@

From the new server (after the file has been sent)

cd /domains/
tar xvfz http.tgz
cd http
nano app/etc/local.xml <-- we edit the DB details to suit the new DB
bash mage-dbdump --restore

When visiting the new URL, for testing purposes we override our local HOSTS file with the new IP and domain.

Stage 5

Now we have the files in place at the new server and we know the site works, it is time to be making regular updates to the files themselves, to ensure they do not end up out of date. Setting up a cron job every hour prior to the move will help keep the final sync as quick as possible.

On the “old” server

which rsync crontab -e

Then add

1 /1 /usr/bin/rsync -par /domains/ exampleuser@ --delete --exclude=var/log --exclude=var/session --exclude=var/cache --exclude=var/report --exclude=app/etc/local.xml

This will sync the files every 1 hour, up to the point where we move the site.

Stage 6

Now take down the old site and start the move. First, delete the cron job that is running on the old server. Then place a temporary maintenance page in place of the store itself whilst we perform the migration.

Create ./holding.html and put a message in there informing your clients of the downtime. Then open ./.htaccess and add

RewriteCond %{REQUEST_URI} !/holding.html RewriteRule .* /holding.html [L,R=507]

Now, no-one will be able to order from the site, meaning that is the last time the DB should have been modified (ignoring 3rd party scripts/external applications).

We know take a final database dump, again with the same command as before, then Rsync all the latest files to the new destination.

On the “old” server

cd /domains/
rsync -par /domains/ exampleuser@ --delete --exclude=var/log --exclude=var/session --exclude=var/cache --exclude=var/report --exclude=app/etc/local.xml --exclude=.htaccess --exclude=holding.html

On the “new” server

cd /domains/ bash --restore

Finally, log in to your DNS control panel at wherever the nameservers are held, and change all relevant records from the old to new IP.

No orders can be taken via the old site, any visitors with out-of-date DNS will see a temporary holding page, until their DNS has refreshed, after their DNS is up to date, they will see the new site, ensuring no race conditions with the orders/data held in Magento.

Stage 7

Finally, after 3 more days (this will be about 6-9 days from when you first started), change all the TTLs back to a sensible figure, 86400.

Your site migration should have gone without a hitch and you will have lost as few sales as possible during the migration. We would obviously only recommend doing this during your quietest trading period in the week, so that total revenue isn’t affected by any noticeable measure.