I am changing servers of my website. The IP of old server cannot be moved to the new one. To have no downtime I am planing to do the following, please someone confirm it will work:

  1. Setup the new server and listen on the new IP
  2. Old server redirect all traffic to the new IP
  3. Change DNS records to point to the new IP

My logic tells me that when I redirect to the new IP from my old box, the user will not see the domain name in the browser but will see the new IP. Is there a way to redirect to the new IP and send along the HOSTNAME with it so that the user will see the domain name in the browser?

Im doing this because the site is in constant use and simply changing DNS settings won't do as database won't be synced between the new and old servers during propagation.

  • 3
    You've probably thought of it but haven't mentioned it: don't forget to reduce the TTL of the relevant DNS entries.
    – cjc
    Mar 21, 2012 at 10:24
  • Is this website used only by humans or are there applications that might connect to it? E.g. consume web services? If that is the case you may have downtime nonetheless. Java caches DNS results and may not respect the new DNS entry until they are restarted. Unless you can keep the forwarding online for a long time. Also if you use encryption redirecting wil involve some additional steps.
    – Bram
    Oct 17, 2015 at 10:54
  • What kind of databases are you using? You are correct in that changing DNS will not solve the problem of downtime, I do this all the time in my job and can give you detailed steps however if you database in on the same server it does throw a minor problem that is usually easily over come. Dec 14, 2016 at 18:10
  • Also what kind of server do you have windows or linux, After reading some of the answer they all point to linux but I really dont see anything in your question that you are using IIS vs linux flavor Dec 14, 2016 at 18:12

7 Answers 7


Here's the method that worked for me:

  1. Sync the files and databases with the new server.
  2. Perform a re-sync just before cut-off.
  3. Change the DNS to point to the new server.
  4. Forward the request coming to the old ip to the new server until DNS propagation completes.

Here's how I would do the step 4:

We will configure IPTables on a Linux server to redirect all the traffic coming on port 80, (which is the default web server port), to a server with the IP The first step is to set your Linux box to allow this kind of forwarding to take place. Open a terminal window, log in as root user and run the following command:

# echo 1 >/proc/sys/net/ipv4/ip_forward

The next step is to tell IPTables to redirect the traffic to the new server:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination

Here’s where the IPTables magic happens. With the third and final step, we tell IPTables to rewrite the origin of connections to the new server’s port 80 to appear to come from the old server.

# iptables -t nat -A POSTROUTING -p tcp -d --dport 80 -j MASQUERADE

The final step is required because if we don’t tell the web server of the new server that the connections are coming from the client machines, it would think that they are originating from the old server.

You may want to repeat this for the databases and email server port as well.

  • did you mean -A instead of -D ?? -D is to delete a rule, isn't it? Anyway, after I've done that the old box is definitely trying to redirect because it's not loading the web anymore, but it fails because the new web is not showing either, just says connection timed out. Are there any other settings I have to do? Maybe something on my new box? Mar 21, 2012 at 22:49
  • Never mind, I fixed it! Turns out my shorewall was blocking the redirect. I had allow it in the rules. Mar 21, 2012 at 23:26
  • I'm sorry about that. You are right, It was -A and not -D. I have updated the post. Mar 25, 2012 at 10:29
  • 1
    Just a warning - the approach using iptables will forward all traffic to the new site, but when it arrives there, it will appear to have originated from your old server and not from the actual IP address of the original browser. This will break things like geographical analysis. In particular, never be tempted to forward port 25 this way for email or you may accidentally create an open relay because mail from a spammer via the old server will be treated by your new server as though it were from one of your own machines which may well be trusted and allowed to relay. Oct 17, 2015 at 10:10
  • @ShainPadmajan, though late, thank you very much, this worked like charm even in 2015. Nov 12, 2015 at 8:41

You can also look into adding multiple A-records. For example, Google uses this, check their nslookup output:

Name:       google.com

If you add multiple A-records to a domain, visitors will receive multiple IP's and try them in that order. If one fails, the client moves to the next one to try.

Setup the new IP as an extra A-record 24 hours up front, start new server, shutdown the old, remove IP.

  • Except, don't add the A record until the new server has been started. :) Mar 21, 2012 at 18:06
  • @Aaron: why not? Adding an A record takes multiple hours (up to 24 hours to fully be active), and as long as the 2nd server is not up, clients will pick the first one.
    – JapyDooge
    Mar 22, 2012 at 7:57
  • When TTL for a zone expires your nameserver is queried again for the resource and it will get both answers. If you add the new A record and wait some arbitrary amount of time to start the server, folks will likely already be resolving to a host that's not yet available. If the new server is already up, you don't have to worry about it. Mar 22, 2012 at 18:13

Another option is to use a VIP (virtual IP). So, your steps will be:

  1. Setup the new server and listen on the new IP.
  2. Add a VIP to the old server.
  3. Change DNS records to point to the VIP IP. Till now all traffic will still be sent to the old server but using the VIP.
  4. When ready to go, move the VIP to the new server.
  5. Optionally, you can change the DNS to the new server IP and remove the VIP (after some time) from DNS.
  • I like your solution. But I am not familiar with VIP and how to get one. Could you point in the right direction? Mar 22, 2012 at 0:40
  • It is really simple. A command like ifconfig eth0:0 <ip> <mask> up will create a sub-interface configured with the IP, and ifconfig eth0:0 down is enough to deactivate it.
    – Khaled
    Mar 22, 2012 at 8:01

Ok, since you mentioned about Database replication, you have to do the following.

  1. Setup replication between databases in the two servers.
  2. During cutover, make the new server's DB as the primary and the old server as readonly.
  3. Point the Application's Database Connection String to the New server on both old and new server. If your site uses Sessions, make sure session is persisted in DB.
  4. Change the IP address in DNS to the new server.
  5. Keep running both the servers for atleast 48 hrs.
  1. Setup the new server and listen on the new IP
  2. Then configure transparent redirection. On old server install rinetd.

In rinetd.conf:

  1. Change DNS records to point to the new IP
  • I did apt-get install rinetd, changed /etc/rinetd.conf to the new settings, restarted with /etc/init.d/rinetd restart but it doesnt redirect. also nothing show in the log /var/run/rinetd.log Mar 21, 2012 at 22:43
  • Show your iptables-save and cat /etc/sysctl.conf | grep ip_forward please.
    – yadaya
    Mar 22, 2012 at 7:25

you can use HA-Proxy in front your web servers, when one of them is going to maintenance mode secondary server will take over.


Your list of what to do looks quite sensible.

As an example, assuming you use apache, when you do something like this in apache on the old server:

redirect permanent / http://newserver.example.com

The user will see the new domain in the browser when they browse to the old site. In this case the redirect also is permanent for as long as the browser is running.

So as long as you implement some kind of redirect in your web server in addition to your other changes you should be fine.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .