Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm a very newbie server admin. I am running a pretty basic cloud server (Windows 2008 R2), which is hosting a couple of different public web sites. The services and database have now grown a lot, and my server is dying under the load. So I contacted the cloud hosting company and apparently the type of server I took out, being the cheapest I could find at the time, cannot be upgraded - not even the memory! - and I now need to get a new server.

So now I have a couple of issues:

  1. Several DNS records are pointing to the old server.
  2. The web sites are interacting with a SQL Server instance on that server, so I need to freeze the web sites before I can backup and restore the DB on the other server.

I want to migrate my SQL Server and DNS records to the new server, with minimum downtime and disruption to the website users.

I know I'm not the first person in the world to have to go through this exercise, so I'm hoping some more experienced people out there can give me some tips how to minimize the pain.


share|improve this question
up vote 2 down vote accepted

With DNS you'd need to set the TTL low so the transfer will take effect faster when you change them over.

I'd get a new hosting company and begin replicating the software configuration on the new system as much as possible. Static content would be the simple to move.

Hard part is the dynamic content, like what's in the database server. Get a dump of the data from the SQL server then import it into the new servers. This should give you a fairly up-to-date version of the website to get running in parallel with the production system.

Once you've confirmed that everything is working in the new site, "lock" the old one by disabling access and dumping the database, then re-import data to the new site, re-point the DNS, and go live.

Of course you'll need to work with the site owners of the sites you're hosting so you can place announcements about the move for their users. You can even put in a redirect page on the old site to redirect to the new site once you have it up and running until the DNS migration takes effect.

Once the DNS is fully migrated shut down the old server. Wait a couple of days, then shut down permanently with the old provider.

For large sites you would look at strategies for running in parallel for awhile; replicating SQL servers across network connections and blah until you can shut down the alpha site and bring up the beta (secondary) site, kind of like disaster planning with two data centers and simulating a shutdown of your primary site. If you're a small operation as it sounds like you are, you're going to end up having to create a parallel install, then when the kinks are worked out you take down the primary and bring up the secondary and wait for DNS to work its magic, helping it with an automatic redirect of your old site. You'll want to warn that there could be a day of maintenance/outage, although the cutover itself should only take a few hours if you set the TTL low ahead of time. Just factor in some fudge factor-uh-oh time.

And check your logs to tell you when the best time to cut over is, with minimal use. Even my bank warns that their service will be unavailable during hours in the middle of the night into Sundays...even though I have yet to see it actually completely dead from access.

share|improve this answer
+1 - thanks - Where do you set the TTL? – Shaul Behr Mar 6 '12 at 15:29

Couple of steps

  • DNS Records - reduce the TTL first, let that propagate at least 12 hours. IF you have a good DNS provider, they will happily assist. This way if you change records which you intend to, it will update according to TTL. BUT remember it can take up to 48 hours for global DNS servers to update.

  • You really should be separating database services and File Services/printing/AD. Consider virtualisation or separate servers if feasible.

  • You may take backup even when the website is 'live'. But obviously you want the latest backup to restore. Therefore i suggest you do a 'test' to ensure the restore works, and a live at the time of going 'live'. You may consider a 'locking mechanism' to prevent any writes occurring but you'd want to do this at the least busiest time (unfortunately that is usually out of standard working hours).

  • As for the website, you need to be running side by side, ensure the website is accessible locally with the test database. Otherwise you may find that you run out of time to troubleshoot any 'potential' issues that could/have easily occur. For testing you do not need to change DNS but rather go on IP addresses.

share|improve this answer
+1 thanks - where do you set the TTL? – Shaul Behr Mar 6 '12 at 15:30
I think the OP is already virtualized. He's hosting in another company that won't upgrade his package to a larger VM. – Bart Silverstrim Mar 6 '12 at 15:30
@Shual - The TTL is usually set by within the DNS control panel provided by your web hosting provider (for example there would be an icon for DNS Management within your CPANEL). It can also be a 3rd party provider other then the guys that provide your website. Softlayer are pretty good, if they provide a control panel for DNS, they will happy to help. – Cold T Mar 6 '12 at 15:44

Timing I need to freeze the web sites...

Is that actually an option? If so, you're a lucky duckling! If it's not truly an option, you're going to want to figure out when your websites are least frequently used, and perform your migration then. For me, this is usually a Saturday night (what some people call a "change window") and running into Sunday morning.

Techno Babble


Who did you purchase your domain through? Who is doing managing the DNS records for you? Updating the DNS for your site should be pretty painless. Just use the tools (most likely some webpage) that your provider has for updating the record. But, beware, it may take a few minutes or a few hours for the entry to full propagate. To help alleviate this time, you can lower the TTL.


Backing up your SQL Server database should also be fairly painless. Inside of SQL Server Management Studio there are tools that will backup the database for you.

SQL Server Backup


Separate your database server from your web server. Either through different physical boxes, or virtualization. Anytime you need to move a server, you don't want to have to move everything.

share|improve this answer
I'm hosting with In general I'm pretty happy with them... just wish they would have been clearer when I originally ordered the "Bare Metal" server that it would not be upgradable. I know how to update DNS records; just not sure how long it'll take before client browsers redirect to the correct server. – Shaul Behr Mar 6 '12 at 15:10
@Shaul - You won't be able to know for certain, but minimizing the TTL should help aid the time. – Ek0nomik Mar 6 '12 at 15:27
+1 thanks - where do you set the TTL? – Shaul Behr Mar 6 '12 at 15:30
@Shaul - that's what ttl is for, and there isn't a quick fix for migrating settings. DNS is more of a "ripple" as the records migrate. The TTL tells servers how long they should hold the record before re-checking for updates. If you're lucky, the DNS servers out there will honor it...some don't. Others are cached. Thats' why it's a variable, and I advised in the move to throw up pages on your old site that redirect to the new until DNS migrates properly. – Bart Silverstrim Mar 6 '12 at 15:32
Also set your TTL back once the DNS records have migrated properly. As for where you set the TTL it depends on your DNS host. Look in whatever interface your provider has for setting it or contact their support. Unless you host DNS yourself. – Bart Silverstrim Mar 6 '12 at 15:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.