What are the key problems to be addressed when moving between different hosting providers?

Question

We have between 100 - 200 servers at two sites located in a 3rd party hosting provider.
(Not a company anyone would recognise.)

Various technical staff are proposing moving to another hosting providor (like Amazon).

The main reasons for this are:

• Improved service
• More reliable and consistent networks
• A more flexible service
• A cheaper service.

What are the key issues to be addressed in moving all servers from 1 provider to another.

The servers come in all sorts, with multiple OS's, a complex zoned network, and multiple virtualization software types used.

Updates:

They're all dedicated hosts, which are rented from the provider over a fixed period. (That's one of the problems, the inflexibility of the current arrangement.)

During the move, limited downtime is fine. (Weekends, late at night etc.)

Answer 1

A lot of this really depends on what you are using the servers for. This is a general answer assuming a high targeted up time SLA.

If you need to maintain up-time during the move then you would need to setup new servers with the new host and then setup replication between the two servers. Once you have replication then you might consider using load balancing to bring the new servers into operation slowly. This way if there is a failure it will be isolated to only a few users (maybe even migrate a beta group first).

If the gradual roll over continues to work then eventually you can just shift it to 100% usage of the new servers. Once you have done that you can shutdown the replication and decommission the old servers.

Of course if your up-time goal is high you might consider keeping some of the old servers on replication and load balancing as backup.

Answer 2

One of the first things you should think about and examine closely is whether or not the new provider can truly provide you with the setup and service you need (uptime, access, support, etc). Assuming they can the next step is do thoroughly document any changes that will need to be made to your existing setup once you move. It is very unlikely that things will work identically in the two different environments, some modifications will have to be made.

After that, a gradual roll-over as Jim McKeeth described is in order with as much testing as you can handle on the initial small system to make sure you didn't miss anything.

Answer 3

I think based on the new information that has come out I would recommend using VMWare's tools to migrate to a virtual infrastructure. Then migrate that infrastructure. You will still need to deal with any hard coded IP addresses needing to be changed and the inevitable DNS caching issues when you actually switch over.

One huge advantage of that is VMWare has a lot of experience with those two steps and will be able to help you with it. Additionally when you are done you will have a virtualized infrastructure that will be a lot more flexible and resilient.

Answer 4

What are the key issues to be addressed in moving all servers from 1 provider to another.

A few notes...

• Timing the move (100 servers - that's a lot to move in a matter of hours)
• Overlap
  • May want to consider keeping both running while DNS updates
  • Stop updating, or transfer updates in real time, or at later time
• IP allocation
• Network configuration
• Network management
  • Each provider provides a different level and type of service
  • The way you're dealing with the current provider may negatively impact the relationship with the new provider, so don't take your assumptions and processes with you without knowing this
• Uptime, SLA, TOS, other contract issues
• Software versions, especially if they do any management for you
• Machine configuration
  • How much of the machine do you control?
• Emergency procedures
  • They available 24/7?
  • Onsite backup, restore?
  • Response time
• Firewall configuration
• Who are their service providers (and peers if applicable)
• What is your process
  • For backing everything up
  • Restoring it on the new machines
  • Testing it
  • Moving new data over since the backup (sync databases)
  • Bringing it online
• What is the backup plan when (not if) something goes wrong
  • Set up milestones
  • If a certain milestone misses the deadline, what is the process - skip, roll back, or stay put until it's resolved (especially for the actual server switch over)
• Setting up caches in advance (http headers, meta information, etc) so they don't cache things that might change with the switch.

-Adam

Answer 5

You could colocate some servers in the same facility as the existing ones, and then every weekend take a few servers off line to backup the old server and restore it to a new colocated server that you actually own. Once you have moved from dedicated servers to colocated servers that you own, then you can actually physically load all the servers onto a truck and move them to the new location. I worked at a company that did something very similar to this (they started with colocated servers).

If you can segment it into a few smaller moves that would be better, but it depends on the interdependences between the servers

The obvious downside is it requires you move from dedicated hosting to colocated hosting, which may not fit into your plan.

A variation on this would be to take some servers off line on Friday night, back them up, and then move the backup and reinstall it on the other machine. Sounds like a nightmare. I still recommend the VMWare option.