One enormous shift occurring across the industry right now, across all industries in fact, is the migration to the Cloud. I bet if you do some web searches right now you will find a myriad, nay a plethora, of articles talking about why you should migrate to the Cloud (and why their consulting firm is just the partner to help you do it!).

As the Cloud becomes more mature, and more and more case studies become available, the established body of knowledge and best practices continues to evolve. Interestingly there are already plenty of organizations that claim their cloud migration is a failure. Why is it a failure? How could this happen?

One important concept that is becoming evident is that there are different types of Cloud Migrations, levels of adoption you might say. Which level your organization utilizes depends upon your budget, your product and services portfolio, and your organization’s appetite for risk and commitment to change. Depending upon the depth and degree of your adoption, your cost savings, performance improvements, and business gains will all be different.

So what are the different levels of cloud adoption? And what are the pros and cons?

• Pure Lift

Also called “lift-and-shift”, or maybe “forklift”.  This is where you take your existing architecture and systems and you simply build a static representation, as identical as possible, in a Cloud service. Simply put this is like treating a Cloud Service Provider (CSP) like a giant “vSphere in the sky”.  You’re basically just using their hypervisor. And by the way, most of the large CSPs are making this available. For example, AWS gives you several tools to migrate your vCenter to AWS with as little fuss as possible.

https://aws.amazon.com/ec2/vcenter-portal/

https://docs.aws.amazon.com/amp/latest/userguide/migrate-vms.html

The Pro to this model is that it looks almost exactly like your current setup. Your core sysad team won’t have to learn very many new things (although your network team will!). Your products and services can probably function exactly as-is with no changes. And your “datacenter” now probably has better power and network redundancy.

The Con: You probably won’t save very much money. Typically you have to create fairly large virtuals in such an architecture, mostly because you have to build for the maximum usage use case and the systems will be running statically all the time. And if you need to scale up then it’s almost just as complicated as if your hypervisor were on-site.  You still have to plan downtime and so forth to increase your VMs’ CPU and RAM.

• Devops (-ish)

This is sort of a hybrid approach. You continue to use the same products and services but you put forth some effort to wrap them with automation. I’ve written other blog posts about this, but it’s possible to take legacy Commercial-off-the-Shelf (COTS) products and have them become scalable, elastic, and survivable if you put forth the effort. This way you can actually grow and shrink your capacity depending upon demand, and also you’ve added a decent amount of stability by allowing yourself to treat your systems like cattle and not pets.

(By the way, I’ve written about this approach here: Who DevOps the DevOps?)

The main pro to this model is that it allows your organization to continue to use the same tools, products, and services.  Many organizations, especially mid- to large-sized enterprises, are unwilling to accept the risk of changing core products. If your company has built its workflow around SharePoint, and your accounting team uses some Oracle Forms stack, then it might be too much to ask for them to refactor their processes.

Another pro is that you start to realize some real cloud-specific gains here. The Total Cost of Ownership for your infrastructure and datacenter management costs might finally come down, and your products and services now have the ability to scale more easily.

The cons are that this requires more effort and specialized training that the basic “Lift-and-Shift”. You’ll have to learn to use bootstrapping and CM tools such as Puppet, Chef, or Ansible (although maybe you already are, in which case this migration can be easier). Your sysads will need to learn scripting, building cloud-specific images (such as AMIs or containers), and learn to use the CSPs services to allow the systems to grow and shrink capacity automatically.

This can be an organizational challenge because it requires more effort and training than lift, although not as much as…

• Full Adoption, or Refactor

This is the ideal use case, the one that you will see evangelized and talked about. This is where you go back to the whiteboard, understand your organization’s real business requirements, and build, from the ground-up, a cloud-specific enterprise to meet this requirements.

The pro is that this will help you fully realize all the marketing promises about a Cloud Migration. In fact, if you can make the full leap to serverless-driven microservices, you can completely change the way your entire business operates. And furthermore, it will probably operate better than ever. The flexibility, agility, and cost savings will transform your entire company from the top down.

The con, of course, is that this takes the most time, money, and risk to actually perform the migration. Even if there are significant operating expenses (OPEX) savings in the long run, many companies cannot justify the short term capital expense (CAPEX), although this is usually more culture-driven and political than a technical decision. Also, when performing this type of migration it can take a long time to realize the gains. In the short term it will look like you’re not doing anything, and you’re paying a bunch of engineers to just sit around and play all day. It takes a truly savvy and enlightened organization to perform this shift.

As you can see, there are many different ways to perform a cloud migration, with pros and cons to each. Your organization needs to examine all the facts and make the decision up front, because if you start with one model and then shift to another part way through, even organically and by accident, then this will cause even more problems in the long run because you’re probably creating technical debt and an operations and maintenance nightmare.

Addendum:

While writing this article I realized there’s another approach, so I’ll list it here as a bonus: I call it the Pure SaaS model.  This is where you move your entire organization to SaaS systems. SharePoint? Office365! Microsoft Exchange? Gmail! File shares? Dropbox! CRM? Salesforce.com!

If your organization can handle it, this can be as transformative as a Full Adoption. Your workforce can be flexible, able to work from anywhere and any time. Reliability and performance risks are all transferred to another entity. And nowadays, finding a SaaS product for some specific business need is easier than ever!

Be cautious about a full SaaS model, however.  Make sure you keep your core competencies within your organization. And if you ever need custom solutions or software constructed then you still need a place to host it, in which case you’ll still need a CSP after all.