P2V Migration Thoughts


I had a project where I had to do a decent sized data center conversion without a lot formal planning.  We had a SaaS product offering built on a VMware infrastructure that was bigger than the demand for the product.  So we decided to leverage the extra capacity by doing a data center consolidation.

We had two additional Datacenters with about 70 Windows Servers.  It was pretty much a no brainer.  Our new hosted DC facilities were more secure, had more bandwidth and more redundancy with the SAN and the VMware server cluster.  We would end up saving the company a good deal of money on hosting services and building leases.

The legacy DC’s weren’t being actively managed so the inventory wasn’t that great and a lot of the institutional knowledge had been lost over the years.  Since we didn’t originally plan the VMware infrastructure for these specific services we had a bit of retro fitting to do.

We had some of the following tasks to consider or re-architect prior to conversion – just to name a few.

  1. Network Design
  2. New Disk Layout and Service Levels
  3. Backup Schemes
  4. vCenter Security
  5. Migration Schedule
  6. Application Inventory

You can imagine the complexity of each task.  The migration schedule alone had several logistic concerns ranging from user notification to the physical migration of data.

What’s interesting was some of the stuff we discovered as the project got underway.  One of the biggest is that a server that behaves badly on physical hardware will not behave any better on virtual hardware.  This wasn’t a surprise.  What was a surprise was the amount of resources we had to dedicate to fixing the existing environment before we migrated services.

Some of this stuff was really old.  I had one box that was running Windows NT 4.0 with a whopping 128MB of RAM.  It was by far the hardest box to migrate.  The system partition was only 4GB with 10MB (that’s right MB) of free disk space.  I remember those days.  It was a pain 10 years ago and it’s a pain for stuff still in production today.

One great advantage was that it was relatively easy to fix some of these performance issues.  If a box didn’t have enough physical memory – no problem just add more in the virtual environment, the same solution for disk and processor.

I made the mistake of thinking in terms of how long it would take to migrate physical machines with no performance problems.  Since we didn’t have a good since of the complexity of the applications and the challenges of the existing environment we under estimated the project by 2 months.

One thing I’m happy we did was not bite off more than we could chew in the project scope.  We were tempted to do some Active Directory consolidation and other application streamlining.  We decided to make them completely separate projects which saved us a ton of grief.

What are some of your post Migration thoughts?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s