“Lift and Shift” is the Opposite of Digital Transformation

Migrating to the cloud? Now is the perfect time to start or continue your digital transformation. There are several methods when it comes to cloud migration. At some point in your cloud journey you’re bound to encounter more than one of them and each of them certainly has its purpose.

But if you aren’t designing in the cloud, for the cloud (which could involve rearchitecting or procuring replacement application components), you’re missing out on many of the biggest advantages of cloud computing.

Here’s why “lift and shift” ends up stifling what could be a transformative cloud migration that sets the stage for your enterprise IT for years to come.

Cloud Migration Models

At a basic level, there are three ways to move to the cloud:

Lift and shift, in which you simply provision virtual servers and move your workloads to them intact, with minimal re-architecting and most changes coming from network, security, and other simple reconfigurations.

Refactoring, in which you move most of your application components but take advantage of cloud-native PaaS and SaaS elements.

Rebuild or rearchitect, in which you essentially start from scratch with cloud-native PaaS, SaaS, and IaaS components and cloud-specific licensing.

There are certainly times when lift and shift is effective and useful, like when you’re due for a hardware refresh or out of capacity and the application is both up to date and effective. In other cases, the status quo might be maintained even through a cloud migration simply because that’s just what your IT team is used to. A lack of initiative and the appeal of convenience drive this decision.

Taking the Opportunity to Re-evaluate and Transform

Instead of simply moving your data center to a virtual one by lifting and shifting, take the time to think about why you’re moving to the cloud. Is it agility and flexibility? Reliability?

Cloud VMs don’t come cheap, particularly for high performance workloads. While there is opportunity to save operational expenses (and obviously capital expenses, since you aren’t buying servers), you need to strategize to achieve them.

After all, you aren’t running servers or databases or other platforms for the sake of operating and maintaining a server. You’re running them to provide a business service in the form of a specific application. You’re supporting revenue generation and productivity in the form of servers and applications.

There are dozens of PaaS components, plugins, and cloud-adjacent software that you can leverage when you migrate to replace a large component of your manual administration, from Database as a Service to Active Directory to Office 365.

Take five steps for every business application when considering the cloud:

Identify your goals for the migration: why is this app going to the cloud?

List your requirements and any restrictions: what kind of servers or PaaS/SaaS components will you need? What security factors are involved? What about storage IOPS/capacity and network bandwidth? How will your users access the service?

NOTE that the key here to transformation is thinking about services, not just infrastructure. The goal is to deliver a functional service.

Consider alternatives: does this have to go into the cloud? Are there other platforms or service providers you could use instead of your targeted cloud provider that might be more effective or easier to implement?

Prioritize: which of your goals are most important? Which of your requirements are absolutely essential and which could be adjusted or changed at a later date?

Work with providers: evaluate service providers for your cloud elements, whether they are PaaS, IaaS, SaaS, or a combination. Identify potential cost centers and look for SLA / QoS details.

Each of these steps offers opportunity to re-examine the service itself and your goals for it over the migration period and for the future. This is your IT today; what do you want it to look like in 3 years? 5 years? 10 years?

Where is your infrastructure in 10 years?

A solid cloud migration lays the foundation for your infrastructure 10 years down the line. By re-architecting, you’re more prepared to integrate cloud-native platforms. That can mean running SQL in the Azure cloud as Cloud DBaaS, for example,  or it can mean implementing VMware Identity Manager features for 2FA rather than controlling it via the OS. In those cases, it becomes easier to use that database or those authentication rules across your entire environment.

Stop thinking about the cloud as “someone else’s computer” or a big, remote data center. Start thinking about it as a trigger for digital transformation, and your migration will be a much greater success.