Periodic DNS Switching for Major Website Updates - Any Downsides?

[Motava]

A company is performing some major updates to a website and the proposal to go live with the updates was explained as follows:

Once the updates are done on the testing environment and the site is ready to go live, we switch the DNS to the testing environment and then this testing environment becomes the production site. And the old production site becomes the new testing environment.

Are there any potential negatives to this?

Is there a name for this technique?

Of course, we've already considered :

• additional hosting cost
• potential performance differences- reinstalling and setting up server settings - SSL, etc.

[donford]

Switching DNS is not an optimal solution in most cases. When you switch DNS you are at the mercy of the how fast the DNS propagates through the inter web. Larger sites that see a lot of traffic daily are likely indexed more frequently and would thus suffer less traffic loss.

If your domain is performing major updates switching the DNS at the same time is even more so ill advised. Would you not want to see how these major updates affect your website first? If you switch the DNS and see a huge traffic loss then you now are left with trying to figure out "did our updates hurt" or "is this just a DNS propagation issue" or combinations thereof?

My advice, take a two tier approach if the ultimate goal is to move DNS.
Step 1: Update Site On Same DNS
Step 2: Update DNS after updates are proven to be valuable to the users.

If not then why switch DNS if you don't have to?

[Motava]

When you switch DNS you are at the mercy of the how fast the DNS propagates through the inter web.

how fast this propagates isn't really an issue for us.

Larger sites that see a lot of traffic daily are likely indexed more frequently and would thus suffer less traffic loss.

I don't understand how we'd lose traffic...some visitors would see old site and some would see new site until fully propagated, right?

If not then why switch DNS if you don't have to?

The point is the test environment works perfectly right now. If the files are migrated over to the live environment, then we could have issues. But if we simply switch the DNS to the test environment, we know that it will work fine.

[donford]

I don't understand how we'd lose traffic...some visitors would see old site and some would see new site until fully propagated, right?

The problem with changing DNS is an initial traffic drop as routers/hubs/ gets the update.

Quote REF: http://www.mattcutts.com/blog/moving-to-a-new-web-host/

Step 3: Change DNS to point to your new web host.

This is the actual crux of the matter. First, some DNS background. When Googlebot(s) or anyone else tries to reach or crawl your site, they look up the IP address, so mattcutts.com would map to an IP like 63.111.26.154. Googlebot tries to do reasonable things like re-check the IP address every 500 fetches or so, or re-check if more than N hours have passed. Regular people who use DNS in their browser are affected by a setting called TTL, or Time To Live. TTL is measured in seconds and it says “this IP address that you fetched will be safe for this many seconds; you can cache this IP address and not bother to look it up again for that many seconds.” After all, if you looked up the IP address for each site with every single webpage, image, JavaScript, or style sheet that you loaded, your browser would trundle along like a very slow turtle.

If you read this page you'll see Matt Cutts tested mattcutts.com  himself and did not see any major impact. However, Matt Cutts has a high profile domain since he is well known for talking about his experience within Google.

The point is the test environment works perfectly right now. If the files are migrated over to the live environment, then we could have issues. But if we simply switch the DNS to the test environment, we know that it will work fine.

I would concede this point if the major updates are operating in a different test environment then the live environment. By environment I mean different server architecture, like different php / asp versions or database types/versions that the current live server can not or will not be updated to. When you create a test environment you generally want to duplicate the live environment so you can simply push the test elements live once complete.If the server architecture is part of the test then I can't argue with the logic.