Seamlessly moving to a new webhost.

[ej120]

Hey folks,

Here's our situation.

Our current website has outgrown the capabilities of a single dedicated server, so we're moving to a clustered solution with a different company. The problem is, we can't really afford any downtime while waiting for propagation.

Currently, we have 2 identical copies of the site hosted on different dedicated servers, one .net and one .com

Basically, I want to redirect our main .com site to point to the .net version while the DNS of the .com is propagating to the new cluster.

Both current and new hosts are dedicated servers in which I have full root access. Both are running Linux/CentOS 4.5. All the domains are registered via Godaddy.

What would be the simplest way of forwarding our main .com domain to the .net domain? I tried just redirecting the domain via godaddy's domain forwarding tool, but after two days the domain still isn't forwarding properly.

Any tips would be greatly appreciated. My apologies if I missed the answer via search.

Thanks!

[gpmgroup]

Change to 3rd party DNS before the move (ZoneEdit or Granite Canyon etc.)
Allow the DNS to propagate.
Once done set up your new server.
Then its a simple 2 second job to change the IP address(es) of your new server(s).
Switch off old server(s).

[ej120]

No way to get around the propagation period downtime though? Basically, I'm trying to make the change as transparent as possible to our customers.

I'm starting to think it's not viable since the main .com domain is running nameservers through our primary dedicated server, i.e., the one we want to switch away from. Feel free to correct me on that.

Thanks!

[encyclo]

Welcome to WebmasterWorld ej120. If you are running your own DNS, then you should change the TTL (time to live) down to five minutes. Once that change has propagated (ie. if your previous TTL was 24 hours wait 24 hours), then you can switch to 60 seconds TTL, and then five minutes later you can start the transition. The low TTL means that your potential downtime will be very small. However, a low TTL will also mean more load on your DNS server, so you should reset it to a higher value once the move is made.

[ej120]

Hi encyclo,

Thanks for the welcome! So if I understand properly, once I change/propagate the TTL down to 5 minutes on the zone file, I can go ahead and switch to the nameservers I configured with the new host, and then it should propagate within the designated TTL?

Thanks for the help!

[ej120]

or rather, where 5 minutes = 60s. Typo on my part. Sorry for the second post - lack of edit ability.

[encyclo]

That's the theory, at least. :) It doesn't quite work 100%, sometimes the TTL is ignored or extended, so there is always a risk of downtime for some users. It can mess up things on a transactional website if the user gets switched to the new server whilst making an order. Don't forget MX records too for your emails. So you will probably have some minor hiccups, but mostly it should work well assuming your new server is ready and functional.

All in all, you need to keep the old server running for a short duration to ensure the transition.

you can click the "owner edit" button under your member name to edit :)

[gpmgroup]

If you use 3rd party DNS there is no DNS downtime at all because you can leave the old server running while the propagation takes place.

After the propagation is done then you can change the IP address and it will be instantaneous. The users will not know.

[ej120]

Yeah, we're gona leave the old one running for at least a couple of weeks initially. Email wise, I was just going to setup the MX records on the new server, but create an account in outlook that points to the IP of the old one and check both periodically during the switchover so we don't miss anything, etc.

Thankfully, all our transaction processing is on a completely separate DB server, so we shouldn't really have any issues there, since all that we're transferring is front-end essentially.

Thanks very much for the help; very much appreciated. Going to give a shot once the TTL's down to spec.

Thanks again!