Migrating a subdomain to a new server 
Moving to a new web server
Maybe I have been living this situation. I have learned from it. Sharing this information as there was no complete resource to explain that.
You have a main domain and a number of subdomains.
A new webhosting provider came with unbeatable prices. Or is it your old webhost who has a crappy service ?
Whatever the reason for a move, this can be a daunting task. Well, not everytime, if you understand what is happening, it can be easier !
This article applies mainly to Shared Webhosting providers. The same logic could apply to VPS and Dedicated servers.
Shared Webhosting Providers
Companies go for shared webhosting providers saying implementation is easier. Within a matter of clicks, you can get everything up and running. From my point of view, this may be true to a certain degree.
The huge issue with shared webhosts is the lack of visibility. And this is done on purpose. As a person who worked mainly on Dedicated and VPS, this was hell. Everything is already set-up in a crappy way. The logs are limited or non-existant.
The process of Migrating a Subdomain
You need a plan. First of all, you have to assess the number of subdomains you have. The applications that are running on the subdomains etc..
- Migrate one subdomain
- Make sure everything is working correctly.
- Go ahead and migrate all subdomains.
1. Moving your Data
The most widely used CMS are easy to migrate. (drupal, wordpress, etc…)
- First you move all your files from hostA to hostB
- You proceed with making a dump of your Database and migrate it.
- You test your application thoroughly.
2. Subdomain migration
Your files are already on your new webhost. But your subdomain more.supermain.com is still on your old webhost.
You need to point the domain to the IP of the new host.
- Assuming you are keeping your DNSs at your old host. Go to the CPANEL of your OLD host
- Go to the Domains section
- If you are using the advanced zone editor, you need to locate your subdomain records. Say it is a CNAME that is pointing to a certain name.
- You need to delete the old CNAME, after making a backup of course.
- Then, you create an A record that needs to be pointed to our new webhost, say 188.8.131.52.
- Now, the DNS records say clearly that your subdomain has moved.
- We can proceed to our new webhost.
- On your new webhost, you need to create a subdomain, assuming that your main domain is the same as what you had before.
- Create a subdomain by typing it’s name : more (as in our example( and selecting your main domain.
- Your webhost will then ask you to point your subdomain to the ‘document root’. This is where your application and files reside. One DocumentRoot = 1 application.
- You may have to wait a little before DNS propagation.
- DNS propagation can be checked on this site: dnschecker
- We want to type in the subdomain name and check the A record.
- It should point to the IP of our new webhost.
3. Mails not working nightmare
Your application is working perfectly? Almost. Mails are not working. This can become a real deal-breaker if you don’t understand what is happening.
- You are able to send mail from subdomain to the domain.
- But you never receive that mail in your domain mailbox !
- We are able to send mails to third party mail providers: gmail, yahoo, live, etc..
There can be a number of causes for that. But if your web application is not giving any error logs (saying that mails are being sent properly). Forget about your webhost’s logs, they most probably don’t have any !
Tried everything still not working
In that case, that solution may work for you. It may be because our subdomain uses the name of the main domain. When you are trying to send a mail your webhost is ‘intelligently’ routing the mail internally to skip the overhead of the ‘internet’.
There are 2 configurations that must be done from your webhost. You can do it via cpanel of our NEW host!
- Email Routing – Look for that option on your cpanel. Look for your domain name. You will see 3 options: Local, Remote and Backup. We want to choose Remote, and let our main host continue to deal with emails.
- DNS – Having set our email server to remote, we need to tell our webhost where to route the mails. We need to locate any existing MX(Mail exchanger) records. Once located, we remove it (make a backup before or a mind map if your memory is good!). We then add exactly the same MX as your main domain.
- SPF (optional)- Your MX might not be that strict but it could also be the issue. On your old webhost, you may have to add the ip of the new host to the spf record. Just add ip4:184.108.40.206 to the existing record right after “v=spf1 “(where the IP should be that of your new host)
- Try to send a mail after about 30 – 1 hour just to be sure!
You can now rest, mails are being routed correctly!
codarren at hackers dot mu