What Should You Move to the Cloud First?

Talking about the cloud and moving to the cloud are two different things. Most people like the idea of moving to the cloud but aren’t sure where to start. It is also key to realize you don’t have to move everything to the cloud. For example, if you want to start by just moving a few apps or spinning up a few remote desktops, you can start there. You can continue to grow, and scale as needed. You can learn more by checking out one of my past articles that talks about 3 strategies for moving to the cloud.   

So, the question I want to answer for today is: What should you move to the cloud first? In a past blog, I discuss 3 of the common apps customers move to the cloud. This can be a good place to start if you aren’t sure. The things I would think about as I consider a migration to the cloud are: 

1. Everything does not have to go at once, but make sure “connected” workloads stay together. For example, if you have a SQL server you want to move to the cloud, it probably makes sense to move the applications that are dependent on the SQL server as well. If you separate the SQL server from the applications that depend on it, performance may suffer if your network connection between the on-premises applications and the cloud-based SQL server is too small. Some customers do not have a bandwidth concern, so the cloud looks like an extension of their network but be sure to understand the available bandwidth and the bandwidth your application(s) demand. 
   
   
2. Batch processing solutions are a great place to start because the cloud offers compute on demand capabilities. Remember, you only pay for the compute you use, when you use it. If you have after-hour batch processes, the compute they require can be “spun up” when needed, then taken offline when the processing is complete. This is a great way to leverage the cloud in an “on-demand” type model where you only pay for the compute you use. 
   
   
3. Storage is another great place to leverage the cloud. Some customers have a redundant site, or at least offsite storage. The cloud is a great solution for a redundant solution, or an “offsite storage” solution. Some customers mirror all their data to their redundant site. Using the cloud as your redundant site means you are only paying for the storage your company needs, and it is a great way to move your data into the cloud as you contemplate the next steps in your Disaster Recovery model, or your migration to the cloud. Once the data is there, or at least mirrored, it makes it much easier to move other workloads at a more leisurely pace. 
   
   
4. If you have your data replicating to the cloud, this gives you the ability to look at how you deliver reporting services. Going back to item #2, batch processing. If your data is mirrored into the cloud, you can now generate reports and do other batch type work, during the day, as opposed to after-hours. These reports can now run against the replica of your data without impacting the performance of the business applications accessing that data. Some companies suffer with real time reporting constraints because reporting tends to impact their real-time databases. Leveraging a replica of the data gives your reporting near real-time reporting capabilities without impacting your business applications. 
   
   
5. Disaster Recovery (DR) is a very common first step in moving into the cloud. This is similar to item #3, but DR goes further because it addresses not only your data, but your compute resources as well. It requires that you also mirror your business-critical compute capabilities to the cloud. Notice how I said “business-critical” compute, not all compute. Every good DR plan must identify business-critical workloads and non-business critical workloads. By identifying business-critical workloads; in the event of a disaster, your technical team knows which workloads to focus on first and which ones can wait until they have time, or the DR event as passed, and work goes back to normal. 
   

These are some of the areas I would think about as I ponder my migration to the cloud. It’s easy to over-analyze things like this, and in the end do nothing. Honestly, it is usually easier to take the leap in a controlled fashion, then identify what you learn from each attempt. Maybe move a non-critical solution to the cloud and see what surprises are in store for your team. I recommend a similar mind-set when I would talk to customers about their DR plan. Typically, there is some committee that would spend more time arguing than making decisions. I liked the idea of replicating all the company data to an offsite location, FIRST. That way, if a DR event occurs before the “committee” has decided, you have at least saved the company data while the bureaucrats continue to argue about the plan.  

If your data is already replicated when a DR event occurs, it changes the discussion from one of blame on why a decision wasn’t made, to a discussion of how to put things back together so the business can move forward. 

Want to Learn More about a Cloud Migration Strategy?