Redirect Traffic from old to new server when you change hosting service

How do you redirect your users when you change hosting service?
Currently your domain maps to the IP which is with the current
hosting provider. When you change to a new hosting provider, you
get a new IP range for your new servers. So, even if you change the
DNS mapping, it will take at least 4 days to get refreshed all over
the world. So, during these 4 days, some user will go to new IP and
some will go to old IP.

The problem here is redirecting all users to the new IP without
letting themknow anything.

At Pageflakes, We have
done this many times. We had all sorts of problem with our hosting
providers and have changed servers almost once every month. So, we
had to come up with a solution which works transparently and
without any downtime.

Here’s what we do. First we map a new subdomain like
new.pageflakes.com to the new server IP. Then we create a new web
site (not virtual directory) on old web server called
“Redirectors”. It maps to a folder which has nothing but a
global.asax and web.config. Then we go to Web site Properties ->
Home Directory -> Configuration and map ASP.net to receive all
web requests. This includes all URLs including .html, .gif, .css.
Js etc.



Next, we write the following code in Global.asax which redirects
all traffic to the new server.


protected
void Application_BeginRequest(Object
sender, EventArgs e)
    {


string url =
HttpContext.Current.Request.Url.AbsolutePath;

string QueryParams =
HttpContext.Current.Request.QueryString.ToString();

if (QueryParams !=
"") {
          Response.Redirect(
"http://new.pageflakes.com" + url +
"?"+ QueryParams);
   }
else {
          Response.Redirect(
"http://new.pageflakes.com" + url );
   }
    }

So, anyone trying to go to www.pageflakes.com/aboutus.html
gets redirected to new.pageflakes.com/aboutus.html. The redirector
keeps the query string and logical path intact. So, complicated
URLs like
www.pageflakes.com/flakes/amit/notepad/notepad.html?haha=huhu&hehe=hoho

gets converted nicely.

After doing this, we stop the default web site which is
listening to port 80 and turn on the redirector. By this time, new
server is already up and running on the new subdomain.

Now we do the DNS change and map the new server’s IP to www.

So, those users who still have the old IP in their DNS cache
goes to the old server and then gets redirected to the new server.
But after a while when their DNS cache gets refreshed and they get
the new IP, all their requests go to the new server, so we have
nothing to do here. After 4 or 5 days, we can safely wipe out the
old server and start kicking old hosting providers backend.

Anyone has a better idea?

8 thoughts on “Redirect Traffic from old to new server when you change hosting service”

  1. Any suggestions on how to do this using PHP?

    I am trying to accomplish the same thing, but using Apache and PHP. Thanks!

  2. Thanks for this article:

    However, you missed a few steps:

    1. If the site you are redirecting from is not your default site, you have to specify the same host header on the redirector site. Then when you switch off the old site, the redirector will handle requests.

    2. When you add the ISAPI filter in the configuration, there is a checkbox to 'Verify that file exists'. YOU MUST UNCHECK THIS. If you don't, the browser will search for the file in the redirector website and return a 404 error before the server can do the redirect.

  3. Is there a way of doing this without hurting SEO rankings. I.e. if a search engine crawls the old web site and sees a load of redirects (search engines hate redirects) will it have a detrimental affect on SEO?

  4. We are looking at solving the exact same problem. Our solution is a bit different.

    In our new environment, we have setup a load balancer (Nginx) and have setup the upstream servers (server pools) with our new web servers. By default, the load balancing algorithm is round robin. While this will dramatically improve our uptime, we were still stuck with an approach to updating our DNS records without affecting our users. Of course, there will always be some downtime as you physically move the database but this is tenable. 2-3 days for DNS resolution is not. What I came up with is described below. Note, we have not done this yet, but I don’t see any reason why it would not work.

    Setup
    ——————
    – A. Existing server (DNS currently points here)
    – B. New server (Nginx server. This server proxys requests to C, D, E which are the new web servers).

    Migration
    ——————
    Step 1. Update the Nginx configuration (Server B) in our new setup such that the upstream servers were set to A (not the new webservers C,D an E)
    Step 2. Update the DNS record to point to B.
    Step 3. Wait 2 days while DNS resolves to B.
    Step 4. Take our app down and install the systems to C, D and E. (presumably there is also a DB server).
    Step 5. Update Nginx configuration such that the upstream servers are set back to C, D, E.
    Step 6. Bring our app back online

    Notes:
    —————-
    1. Parts of Step 4 could be achieved before you even start the process. With the exception of the database, the rest of the application could be deployed and tested in the new environment to minimise downtime (only the database needs to be backed up and restored in the final step).
    2. During the two days while the DNS is resolving, all requests to B will be proxied to A which means the latency between server B and A will be added on to every request. This shouldn’t be a big problem depending on what the latency between your hosts are.

    That’s it. Any thoughts?

  5. This is what have done several times when moving servers.

    1 – change the TTL in DNS to 5 minutes or so 1 week before the move so users will get the change of ip in 5 minutes when the switch is done.

    2 – install and prepare a TCP port forwarder (will work for http, not https)

    3 – make the switch of DNS/database etc.

    4 – activate the TCP port forwarder so port 80 on the old ip’s are forwarded to port 80 on the new ip’s

    5 – but back the TTL in DNS to your normal value

    6 – after 1 month or so remove the old server

    Check the web site log files on the old and new servers and when the main search engines have started visiting your new ip addresses then you can turn off the old server, I have seen that some search engines keep coming to the old ip for month, I think Google took 1 week, most search engines seems to ignore DNS TTL’s and caches the ip for a long time.

    One time I moved 10 servers from one office to an other and setup a Linux box in the old office and assigned all old ip’s to this box while physically driving the servers to the new office… While the servers were down the Linux box showed “maintenence, please come back later” web page. When the servers were ready in the new office I started the TCP port forwarder on the Linux box.

Leave a Reply