Becoming Hybrid: Executing the Migration

The day has finally come. We’ve potentially ventured out of our comfort zone to collect information on business strategy and requirements from the leaders in our company. We then put in the hard work to analyze our existing applications, how they operate, and whether they’re a candidate for cloud migration. We’ve also reviewed the available cloud platform options, assessed their ability to meet our business and application requirements, and made informed decisions about which to integrate in our hybrid architecture. Now it’s time to perform the migration. In this post, we’ll look at the primary approaches to transitioning to the cloud and talk through some of the benefits and drawbacks associated with each. After jumping through the preceding series of hoops, we need to make sure we stick the landing.

Migration Approaches

Lift and Shift (Rehosting)

With the lift and shift approach, the focus is on relocating existing virtual machines as-is without any significant change in architecture or configuration. This type of migration is facilitated using a replication-based migration tool to connect to the existing on-premises virtualization environment and transfer virtual machine data to the cloud. Once this process is complete, replicated virtual machines can be instantiated in the cloud and will continue to operate as they were. On-premises versions of these virtual machines can then be retired. Examples of this include migrations using native tools like the AWS Server Migration Service and Azure Migrate, but some third-party disaster recovery tools are also capable of this type of replication. The effort and complexity involved in this type of migration is low, which can be useful, but the general value of taking this approach is less than the other options. Using this approach, you gain the benefits of transitioning to a pay-as-you-go model, and you’re no longer responsible for the underlying infrastructure layers. However, you don’t benefit from the new technical capabilities available to you in the cloud. You’re carrying things forward as they were in your data center.

Lift, Adjust, Shift (Replatforming)

The second type of migration approach builds on the lift-and-shift concept but focuses on making some key adjustments to how applications are configured and run in the cloud. If you were previously relying on a single VM instance to provide a service, you might scale the deployment out to multiple nodes and introduce a managed load balancer into the equation to improve performance and availability. Or, you might choose to transition to a managed database instance like Amazon RDS instead of managing your own SQL server instance on EC2. In this situation, you’re no longer responsible for managing a database instance, which can be particularly useful if you’re light on DBA expertise. Because you’re making changes to the server configuration, you may need to rebuild your instances in alignment with the new configuration, then perform data migration at the OS or database level instead of leveraging VM-level replication. While the effort and complexity here is higher than a simple lift-and-shift migration, the benefits are improved, as well. Even if you run traditional (non-cloud-native) applications, you’re now taking advantage of the technological improvements available to you in the cloud, which can bring significant business value.

Refactoring

The last migration approach is most appropriate for businesses writing their own applications and able to control how these applications are designed. Refactoring is a significant undertaking involving a complete overhaul of the application architecture to take advantage of cloud-native concepts and services. As an example, a batch processing application previously running on a set of interdependent servers in the data center might be broken out into input and output workers communicating via an intermediate layer like a message queue service. Alternatively, a web-based application might be transitioned to a serverless architecture and run using a service like AWS Lambda instead of a traditional web server farm. The application now fully leverages the improvements available within the cloud, along with the scalability, performance, availability, and cost savings this can bring. The downside is the effort and complexity required to re-write the application can be very intensive. Because of this, refactoring isn’t going to be the right approach for everyone. But in situations where this is the right answer, the benefits to the business can be very significant.

Wrap-Up

The migration approach you select can determine the amount of benefit you realize as a result of the migration. Lift and shift is the fastest path to the cloud, but this approach may not bring the improvements you’re expecting, especially in the areas of cost savings or availability/performance. On the other hand, refactoring is only available to organizations writing their own code and able to make architectural adjustments to how the application functions. Even where this is possible, the undertaking is significant, which can prevent some organizations from pursuing this route. A happy middle ground can be the lift-adjust-shift approach, where minor, but impactful changes are made to the configuration of the application (and infrastructure) to take advantage of new capabilities in the cloud. Now that our migration is complete, we need to look at how our new cloud environment is going to be operated and governed moving forward. In the next post, we’ll examine some of the key considerations involved in this phase to make sure your cloud transition is a successful one.