Six Steps to Moving Your Network to the Cloud

4.) Decide on Testing

The other interesting thing I think end users should look at when analyzing different cloud providers is how to slowly dip their toe into the water to test it. It shouldn’t be an all or nothing migration – you should be able to gradually break off pieces of your infrastructure and migrate over. For example, maybe move your emails over first. People think emails have to be on premise and near them, but if you think about how email works, they’re flying all over the internet and dependent on connectivity anyway; even if you have your email server onsite, you can’t send or receive email if your internet is down. So why not put it up into the cloud? It’s much more cost effective, and it gets you out of the business of buying, owning, running, and managing that server and infrastructure for just email.

5.) Make the Move with Your MSP

Every provider has its own roadmap. However, some general steps to making the move include:

Building a decision tree

In the case where you have an existing server, have an infrastructure running and want to convert, the first question is going to be, “do we do it all at once, or in little pieces and connect the environments together?” There’s going to be a decision tree that happens there; for example, some may ask, “can I take my services and loop them in the cloud, or do I want to move everything in one big push over the weekend? Do we do it in stages?” Assuming we’re going to do it all at once, the first step is going to be spending time understanding all the critical business applications that the company needs to run. What does every end user use in every application? Frequently, things get missed, not all of the departments are surveyed, and when you go live, somebody makes a cutover and says they missed application X, and now they can’t work.

Understanding how these applications can be run in a virtual environment

Scaling with these cloud services are dynamic, and happen quickly. You don’t have to over-provision things, especially in large scales or in large amounts; understand how you can scale these back. The tradeoff is, the more you over-provision, the more you’re going to pay for it. So, we want to get it to 70 to 80 percent utilization when it’s being used.

Getting the cost estimate

All cloud providers bill on demand, or bill you for what you use, so it’s important to understand what the scale is, what the configuration is that we’re building out, and how much the cost per month is going to be. There’s no real guarantee that the price is going to be X for a year, unless you make a configuration change. For example, prices for cloud providers change all the time. You add and remove users; every time you add or remove a user, the price is going to change. The customer has more control over that – the customer can provision a new server overnight, and the bill is going to be what the bill is, so that model is important to understand.

Building out a proof of concept environment

It doesn’t need to be an environment you’re going to destroy necessarily; you can have a clone of an environment you’ve got running already, where we would scan all the same servers, provision them the way they’re supposed to be provisioned, install all of the apps, give the end user remote access to the environment, and let the end user poke around on it for a couple of days. The customer is the only one who can truly say if this meets their needs, has the right apps, performs how they need it to do, etc.

Setting a deadline to go live

When the full production environment is up and running, we draw a line in the sand and say, “as of this day and time, we’re going to turn off the old environments, copy the data over to the new environment, refresh the data, and turn it on.” Then there should be a go live day the next morning where the providing staff handles password problems, application issues, etc.

Getting ongoing support

You should have ongoing support from that day on. From being there that day supporting the end user, you go into a support role, where you’re monitoring the events with a monitoring tool, backing it up with some sort of offsite back up tool, controlling antivirus, etc.

6.) Sticking to the Contract Years Down the Road

Historically, we saw MSPs were also the infrastructure providers that may have had their own data, their own service providers; they’d sign on to a multiyear contract with an MSP providing you the server, the infrastructure, operating system etc. That’s definitely changing with these public cloud providers where the MSPs are not the provider anymore.

Contracts fall into two separate buckets:

A contract with the MSP or CSP to manage infrastructure.

This is going to have some sort of term on it; typically we see three year terms. That’s going to have an agreement around managing your environment.

A big misconception a lot of customers think is “I’m going to go to the cloud, now it’s going to be maintained by itself,” but the cloud isn’t necessarily self-maintaining; if you set up a Windows server, and you create a username and password, it’s probably not only going to get patched, it’s going to get broken into. So you still need to have good common sense when you’re setting up servers. The MSP should be helping with that – patching the windows over, keeping it up to date, making sure it’s secure, etc.

A contract with a cloud provider.

On this side, we see a mix of those pricey models evolving; however, generally across all providers it’s pay-as-you-go on demand, which is usually where every customer starts. Then, after a couple of months, we go back to end users and ask, “does it make sense to pre-buy some of these servers?” All of the major public infrastructure providers have options where you can pre-pay a year, three years, etc. for the servers.

One of the gotchas we’ve seen end users run into is, they buy the three-year model because they think they’re going to save the most money. But – historically, when you bought a server of a specific type – meaning number of CPUS, how much RAM it has, etc. – and you prepaid it for three years, that’s exactly what you got for three years. You couldn’t upgrade or downgrade it – you were locked into it for three years. End users would get into it and then say, “well Microsoft lowered their prices,” or “Amazon has a more powerful virtual machine for a lower price.” We’re starting to see less and less of customers buying these long term prepaid servers in the infrastructure providers. Lots of people are staying month to month. The MSP should help you decide some of the following: what should we do when we’re pre-buying? Should we do a one-year contract? Should we prepay now? My sense is that customers like the idea of not being tied into the long contracts, and paying month to month, to have that flexibility and freedom to move providers.

One of the things that we’re finding interesting in this realm is, as departments go to their executives and say, hey, we want to go to the cloud, they like the idea that someone else will maintain the infrastructure, and that it will be secure. However, this change from a capital expenditure to an operating expense has seen a push back. This is surprising because a lot of the executive compensation bonuses are tied to them keeping operating expenses down. It becomes more of a financial conversation than a technology one these days.