Website Migration Process

This page is used to document some of the processes used to migrate sites from other web hosts to web hosting or dedicated servers with Anchor.

The aim is to make the migration as seamless as possible from the customers prospective as well as provide a systematic approach and make life easier for us.

It is important that anyone involved in this process strictly follows this to ensure consistency. Summary of process:

  1. Make sure you have all necessary information
  2. Set up hosting account
  3. Replicate DNS
  4. Re-delegate the domain
  5. Have site tested on temporary domain by customer and/or developer
  6. Change DNS records.

Before you begin make sure you have everything you will need to complete the migration. This includes, among other things:

  • Domain password or registry keys
  • Access to the hosting account on the existing host
  • Ability to perform database dumps
  • All SSL certificate files
  • Checked that the hosting platform is compatible (i.e. versions of applications, Linux not windows).
  • List of all existing email addresses

Setup Hosting Account

The web hosting account should be created using the virtual hosting configuration process.

DNS Configuration

DNS needs to be configured within our nameservers.

At this point the aim is to add all the existing DNS records that are presently on the Internet to our nameservers with a small TTL (say 10 minutes). This is done so we can redelegate the domain name to ns1|ns2.anchor.net.au importantly without breaking email servers.

To obtain these records the following dig commands can be used:

dig example.com axfr 

This command is likely to fail, as we are trying to complete an entire zone transfer, many DNS servers have ACLs in place to prevent this from happening. If no joy try:

dig example.com ANY 

If still no joy then a little bit of guess work is required, however you can generally have fairly accurate results if you make sure that all the following records are listed within our nameservers:

  • A record for the domain
  • either CNAME or A record for www
  • All MX records for the domain
  • either CNAME or A records for the following sub-domains: mail pop smtp pop3

It is also important to check with the customer to ensure they do not have any other sub-domains in use which need to be added.

Once all these are added, check to make sure that a small TTL is in place (10 minutes) and then check what is configured in the name server against where the domain is currently delegated to.

For example, if the domain is currently delegated to netregistry (ns.au.com), then both of these commands should return identical results.

dig example.com @ns1.anchor.net.au  
dig example.com @ns.au.com

If they don't return identical values, chances are something is broken so make sure you go back and fix before continuing.

Once you are 110% certain that it is correct then have the domain redelegated to ns1|ns2.anchor.net.au.

Whilst we are maintaining all the current, existing records the important changes are:

  1. Anchor has full control over the DNS. This means that we control all aspects of the domain and can make changes at our discretion (lets us make sure we know the right thing is being done) and;
  2. There is a short TTL (time to live). This is good because we can make changes to the DNS records and they will quickly propagate around the Internet. For instance, if the TTL is set to 10 minutes we can change the A record for the website and this change will be seen throughout the Internet within 10 minutes.

This means that within a 10 minute period the migration is completed (compared with the usual 24-48 hours).

Site Copying

Once this has been done we have approximately 24-48 hours before the domain can be redelegate to our name servers. This will give us ample time to move the content across to our servers. There are essentially two ways this can be completed depending on what information we have. If we have FTP/SSH details then we will be able to log in and copy the files across. Important things to note:

  • Databases? Make sure a dump is taken and saved in the home directory
  • Provided you have ssh access, the easiest way to copy the content across is to tar up the entire home directory and then SCP it across.

A dead simple way of copying an entire website if you have FTP access is using LFTP. Login to the server the account is on as root and:

$ su - <username>
$ cd public_html
$ lftp <ftp host>

lftp :~> user <ftp username>
Password: <hmm what goes here?>

lftp :/> ls (just to make sure you're in the correct folder, otherwise cd to the folder containing the website)
lftp :/> mirror

With any luck, this will mirror the entire contents of the website into your current folder (you did change into their public_html folder first right?) You still need to manually copy any databases across etc. Without SSH/FTP access:

A few caveats:

  • wget will only work when there is static content on the webpage, no dynamic pages (eg php, python, ruby), no databases.
  • Your mileage may vary when it comes to flash/javascript.

Site Testing

Once the website has been copied test it on the temp URL and compare against original website to ensure everything is working correctly. If anything is not working, make sure it is fixed at this stage.

Once this has been done and you are happy with the work, supply the temporary URL to the customer and have them check the content to make sure it is working as expected.

It is important that we get confirmation before continuing past this point. When confirmation has been received, we are ready to go with the website migration.

Email Configuration

At this point we need to configure all the email addresses that the end customer uses on their domain. It is necessary to speak with the customer and ensure that all are covered as if any are missed once we change the DNS records all email will start bouncing. Once they have been configured the following needs to be effectively communicated to the customer:

  • New Username / Passwords
  • Any changes in mail settings from their prior web hosting account
  • The specific time when the DNS records are going to be changed.
  • Optionally get the client to configure two mail profiles, existing one + one pointing to the new mail servers.

Finalise Migration

Once everything has been checked and rechecked we can change the DNS records to point to our servers for web and email hosting. It should only take 10 minutes for the DNS changes to propagate, due to the reduced TTL.