Yes, your migration is going to be easier if its already a virtual machine. A V2C (Virtual to Cloud) is going to be a simpler transition that an P2C (Physical to Cloud). The figures vary, but a recent Gartner report (Oct 2009) indicated that only 16% of workloads are running as a virtual machine today. How is work on your virtual first policy going? What is your current virtualisation level and when will you be at the 90% level?

What is the dispersion of your current workloads? Do you have a ROBO (Remote Office / Branch Office) or a centralised model? Are all of your workloads in close proximity to the accessing users or systems? How many data centres do you have? Once you start to move to a Cloud model your workloads are going to be access via a network, whether that be your own, a private network with your service provider or the Internet. The proximity of the applications is going to change and this may have unexpected effects.

The more work you can do beforehand it educating and training your yours the less you will be taking on as you move to a Cloud model. Likewise any associated application issues can be dealt with in preparation. Do you need to change some of your printing environment given a more centralised architecture?

Centralising is a good pre-emptive strike to needle out any application issues before you start moving workloads to the Cloud.

How tidy and efficient is your wide area and local area networking? Is your IP address register up to date? Would you easily be able to break down your subnets based on associated workloads or are the servers intermixed with the addressing for of your other infrastructure such as networking devices, printers or even desktops. Do you fear changing an IP address on a server because you know it will probably bring down your core application, or who knows what? Is your WAN routing a mess with lots of old entries, a convoluted mix of static routes with no dynamic routing protocols? Have you implemented Quality of Service (QoS) to ensure that important traffic is protected and given priority. How long will it take for you adjust the bandwidth around your network if needed?

A key element to Cloud is that it is connecting to remote services over a network and to be prepared for Cloud you want to ensure that you network is going to be up to the task.

How much of the configuration and operation of your workloads is automated? Is everything efficient or are people always running into the server room to remediate and repair? Are new machines deployed from a number of templates or is everything built from scratching by popping a CD into a tray or mounting the ISO? The more automation you can achieve the better for continuing the same practices once you have moved to a Cloud service. It will be easier to add a few additional orchestration features (such as some vCloud API calls) to your deployment method rather than scratching your head whilst waiting to transfer new images to the Cloud every time you need a new machine. How is your server and application patching, patchy at best?

A good activity here is to start to utilise the vApp features of vSphere. Packaging workloads into containers that contain one or more virtual machines. Can you extend the networking of your vApps to be more automated through the use of IP pools?

What does it cost in terms of dollars and kilowatts to run a workload in your environment today? Not how much did a physical server which runs ESX cost you when you purchase it last year, but how much to run a workload? If you do not know your internal costs, regardless of whether you are passing those costs back to internal departments, its going to be much harder for you to do a business case for moving some workloads into a Cloud. When the Cloud provider quotes you a dollar per Gb for storage what does it cost you to operate and maintain storage per Gb now? Simply taking the purchase price of your SAN and dividing it by the total capacity of the raw disks is not an acceptable model. How much do you pay for electricity and how much does that SAN consume?

Understanding your current internal costs is important to prepare for moving to Cloud.