Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

Our new client requires us to migrate their 37 servers (Windows 2003, SQL Clusters, Sharepoint Boxes, WebTrends, Domain Controller, Google Appliances etc) across to a new hosting service.

Has anyone got any tips and tricks for how to even get started with such a monster migration.

I'm only a C# programmer and way out of my depth here!

EDIT: Not physically moving the machines, building a new environment and then doing a "soft" move. We are "switching managed hosting providers".

share|improve this question
Are you talking a move between colo providers i.e. moving the physical servers or are they looking to switch managed hosting providers? The latter in particular is big job - if you're not comfortable with administering domains & clusters etc you should definitely get some experienced help in with this to plan it out for you. The new hosting co should have someone available to help project manage a migration of this size. – Chris W Jul 23 '09 at 14:43

Very general (perhaps obvious) tips:

  1. Never attempt anything you're not technically competent with and uncomfortable doing. If in doubt, defer to an expert

  2. Make a list of potential problems and speculative solutions before doing anything - this is useful to refer to when you're pulling your hair out

  3. Configure all new servers with the exact same software versions - don't be tempted to perform a dual migration/upgrade as identifying problems becomes more difficult with more unknowns

  4. Ensure you copy all config files verbatim, and if possible use the same local host names and IPs for new servers. If config files refer to servers, make a list of them (lists are your friend!) and if you change server names/IPs search for all instances of the original names on the original servers ready to edit the config on the new hardware

  5. Allow double the anticipated time for testing - take snapshots of filesystems and databases and load them onto the new servers, then duplicate integrity/functionality tests on the current and new servers. If hardware differs, take this into account (where possible)

  6. If relevant, lower the TTL for all domains to 300 seconds a couple of days prior to actual migration

  7. Clusters can be fickle beasts, if you have redundancy and load balancing don't test them both at the same time! Configure the failover/redundancy software/parameters first and test this, load balancing can wait until the underlying functionality is solid.

  8. Beware of benchmarking throughput just for the sake of it, it should be the final step

  9. Ensure your new servers have the same level of security as the old, including firewall settings and application specifics. If required, a 3rd party pen test may help

  10. Schedule downtime for data migration

  11. If your managed hosting provider will help, hit them for everything they can offer as they will have plenty of experience on hand

Microsoft File Server Migration Toolkit may be handy's Server Migration Strategies Made Easy

HTH, don't forget to defer if uncertain :)

share|improve this answer
Maybe obvious to you, but very useful to me thanks – in.spite Jul 24 '09 at 7:21

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.