tl;dr: Cloud—It’s easy to misunderstand. When building your cloud migration strategy, it’s easy to overlook areas that can come back to cost you. Based on conversations with our clients, these are the 3 most commonly misunderstood items about the cloud:
- Rehosting your legacy workloads actually works in many instances. ↓
- You’re responsible for more data security than you think. ↓
- Back up your cloud. Please. ↓
Moving your workload to the cloud can give you flexibility, scalability, and global availability, but it won’t solve all of your problems. Many companies that we’ve spoken to look to the cloud to “fix” whatever issues they are having. Unfortunately, that just isn’t true.
While public cloud infrastructure can fix issues of scale and availability, it may limit you in areas like performance and security. Other customers we’ve spoken to see cloud as impossible for their company due to a lack of specialist engineering resources. Fortunately, you can gain or hire for these cloud-computing skills for the right opportunity.
These are the common misconceptions about on-premise to cloud migrations that we’ve discovered through conversations with customers.
Misconception 1: You have to rearchitect your apps to move to the cloud.
Many technology leaders that we’ve spoken to think that you have to rearchitect applications so that they’re cloud-ready before you can move them to cloud infrastructure. While a cloud migration is an excellent time to analyze your existing applications, you don’t have to do all of the work in advance.
According to Gartner, you can choose from among five different options when migrating an application to the cloud: Rehost, Refactor, Revise, Rebuild, or Replace. Later others began recommending a sixth: Retain. If you don’t have a Gartner subscription, AWS wrote a simple explainer of the 6 migration strategies and Azure has an explainer of the 5R’s as well.
Of the six strategies, only four are worth discussing here because two of them—retiring and retaining—don’t require moving anything as all. And of those four, only one of them—re-architecting—requires significant engineering resources. The other three—repurchasing, re-platforming, and rehosting—may only require a small amount.
Repurchasing might only be a matter of dropping the on-premise licenses and relicensing the software in the cloud. However, if you’re purchasing different a replacement for your existing software, say migrating your CRM to Salesforce.com, you’ll likely need specialist resources to migrate your data and rebuild your workflows in the new tool.
Re-platforming aka. Refactoring involves moving some or all of your applications to a Platform as a Service (PaaS). For example, moving to a database as a service model to reduce the time spent managing instances.
That leaves us with the remaining option—rehosting.
Rehost where it makes sense.
Rehosting is probably the root of this particular misconception. While most organizations begin cloud migrations by considering all of the cloud-native features, AWS found that in large legacy migration scenarios, companies choose to rehost the majority of applications.
What exactly is required to get your application up and running in the cloud?
- Perhaps you need to rethink networking between your VMs.
- Perhaps it’s where you store files.
- Or perhaps, you have a nest of NFS/SMB shares that you think might prevent you from rehosting your complex web.
It could be as simple and automated as using a VM importing tool, like those from AWS or Azure to upload your existing VMs and convert them for your Infrastructure as a Service (IaaS) of choice.
And, post-migration tools like Azure NetApp Files can be used to support network shares in SAP and other core applications.
Finally, if you want some of the expandability and availability of cloud on your existing architecture, you can use tools like HPE Cloud Volumes.
Misconception 2: Because it’s in the cloud it’s secure.
If you’re unfamiliar with the cloud, you might assume that since the cloud is someone else’s computer, they’re going to protect it. That the truth, but not the whole truth.
Here’s the truth: Everything you do on-premise, you still have to do for your cloud applications. Networking, security, backup, etc.
Cloud providers will protect physical access to the site, the hardware your application uses, and the software that they use to host your VMs but that’s where their security responsibility ends—and your responsibility begins.
If you want to know more, learn how to protect your environment from cloud security threats.
Fortunately, many of the tools that you trust to provide network security in your on-premise environment (like Symantec, PaloAlto, and F5 Networks, etc.) have developed cloud counterparts.
Misconception 3: Because it’s in the cloud, you don’t have to back it up.
Do you remember just a minute ago when we said that everything you need to do on-premise you need to do in the cloud? That also applies to backups.
Just like RAID isn’t a backup, distributed cloud storage isn’t a backup. It’s there to protect the cloud provider’s SLA, not your data. The SLA that cloud vendors provide only covers their infrastructure, not your data’s availability.
You are responsible for your own Recovery Time Objective (RTO). Protect your data by backing up regularly. Please. This may even be a time where on-premise becomes viable again — as a midline or cold-line backup of your cloud services.
A simple quote always rolls around in my head when I think about cloud infrastructure: “The cloud is just someone else’s computer.” This means that we have to protect it like any other computer. Use the 3-2-1 backup rule to make sure your data is safe.
And remember to backup business-critical SaaS applications like Microsoft 365 with a tool like Veeam or Barracuda as well.
Cloud isn’t right for every workload, but it can give you more flexibility, geographic availability, scalability, and super-brag-ability. And it’s more accessible for legacy applications than you might think.