OK, so you want to take the plunge and move your IT stack to the cloud. Good for you.
But, and it’s a big but, before you make that leap, look carefully at exactly what you’re doing.
For example, it’s true that moving to a cloud should–should–save you money. But, there’s no guarantee. Next, what kind of cloud do you need? Infrastructure-as-a-Service (IaaS) cloud? Maybe a Platform-as-a-Service cloud would serve your needs better?
Then, you need to worry with whether you want to go with a public, private, or hybrid cloud. Each have advantages and disadvantages. What might work for your rival, may not do you any good at all.
Next, you must decide on which cloud provider and/or partner you’ll work with to set up your cloud. You could run a cloud of your own with no help, but unless you’re already a cloud business that’s more trouble than it’s worth.
Those are basics. Let’s look at some questions that are a step beyond Cloud 101.
Can your new cloud deal with your organization’s specific requirements? For instance, say you use virtual desktops. Can your virtual CPUs handle the log-on morning storm? Sure, you specced out your cloud for your average load, but Monday mornings? Make sure it can before making the plunge.
And, what about licensing? Do you pay for your application by virtual machine, per core, by socket, or by total footprint? This matters a lot. For example, if you’re paying for your database management system (DBMS) per core, before you move to the cloud you must pound out exactly what will change lest you get a shocking surprise.
In fact, look carefully at all your server software licensing and make sure you understand exactly how much you’ll be paying once you’ve moved from your local servers to the cloud.
Also, how do your users currently access their applications? You’ll almost certainly need to change how this is done. On top of that, you’ll need to change your network topology to deal with new IP addresses and DNS entries.
Now, what about your applications? If your core server programs are monolithic systems, moving them will not be easy. Migrating them will likely turn into a long, arduous process.
Even if it’s not a monolith, do you really know how your application dependencies work? If you don’t, take the time to learn before you make the cloud jump. If you find out in mid-migration your line-of-work program really did depend on an obscure program running on a dusty, undocumented server, you’re in for trouble.
You also must decide if you want to migrate your business to the cloud in one big push or over time. The first is fast, but dangerous. The second can bog you down in running duplicate production systems.
The smart move is to to identify simple applications that can be migrated easily. Save the hard ones until you and your workers are comfortable with the changeover.
Yes, you’ll end up running your old systems longer, but this approach is much safer.
You’ll also need to train up your staff on how to support your software and users on the cloud. I can guarantee that your old helpdesk scripts aren’t going to cut the mustard. You can’t just lift and shift to the cloud. It’s an entirely different world.
Get the picture? “I’ll just move to the cloud,” sounds simple, but it never is. You really must examine every step of the road. You don’t jump into the cloud, you walk there, slowly and carefully.