Cloud migrations can be tricky when looking at the multitude of options for moving workloads from point A to point B. I don’t think there is such a thing as a “typical” environment or technical setup, if there was, it would be easy right? However, before you migrate your IT crown jewels (data and VM’s) to someone else’s IT infrastructure, there are 4 points to consider back at the planning stage that will affect your overall decision.
- Security
When moving your data, it’s worth considering the security of the mechanisms which you use to migrate. In the days before security was taken seriously, USB drives were used extensively (some still use them now), but the security is very lax. These days, VPNs and encryption can solve security for data in flight over a network. However, if using an agent-based system for migration, security holes can be created when antivirus must be disabled or ports must be opened.
- Testing
In an ideal world, you would scope out your requirements and test with a new provider (or even several of them) before you make the leap. Will your new provider give you access to a sandbox environment to test on prior to migration? Will they also give you the appropriate time and resources to assist? Testing can be very resourced intense to complete, and it’s usually associated with additional costs. Further, replication of data must happen before testing can begin, making it impractical to do real-world testing of any production applications – especially those with a lot of data.
- Deployment
If you are replicating VM’s to the cloud (who wouldn’t?), you can deploy the client agent remotely using a handful of different methods, but this is always a cumbersome task. Having been in that situation many times, I always find myself wondering, “Will it? Won’t it, maybe?” and then find that I’d have to start the data copy again due to corruption. If you’re an organisation that wants to move hundreds of applications to the cloud, consider the scalability of your migration solution.
[easy-tweet tweet=”Internal resources can easily equate to the same price as using an outside firm.” hashtags=”Security, Resources”]
- Time
It’s hard to put a value on the time cloud migrations take (except when an external consultant or firm gives you a bill). However, organisations with internal chargeback mechanisms in place are finding that internal resources can easily equate to the same price as using an outside firm. As you plan your migration timeline, compare how much time each migration solution you are considering takes ‘per server’. If you multiply your ‘per server’ time by the number of machines you need to move, you can figure out how many human resources you’ll need, and an overall cost based on their per hour time.
All in all, migrating your virtual environment to the public cloud (with an infrastructure that is likely different than that in your data centre or colo facility), requires significant planning and coordination – even before you get to the actual process of moving workloads. From there, do what you can to make your life easier. Installing “stuff” to get the replication started/completed is a headache. This coupled with the additional skills and resources you’ll need will add cost (let alone the challenges when you try and migrate back if you find that the provider of choice isn’t right for you). When reviewing Velostrata and their agentless migration approach, it seemed to tick every box to hurdle over these 4 main points. Their migration toolset is agentless, a big tick in my box. They provide an easy way to ‘test before you migrate’ without having to move all the data first, which allows you to ensure you scale correctly before you push the magic button to migrate. But don’t just take my word for it, Gartner awarded them a “cool vendor” rating in 2016 and I can see why. Take a look at their 3minute video that explains in simple terms how their software works, probably better than I can within this blog.