With the benefit of hindsight, was lifting and shifting a waste of time and energy?

This network diagram (taken from the talk “Peeling the Onion” from the AWS Architect & Developer Day) captures almost exactly the end result of our lift and shift efforts.

This is how AWS imagines the future of web development.

Clearly, we had only just scratched the surface of the cloud revolution. The Thoughtworks radar hit the nail on the head with this observation:

As more organizations are choosing to deploy applications in the cloud, we're regularly finding IT groups that are wastefully trying to replicate their existing data center management and security approaches in the cloud. This often comes in the form of firewalls, load balancers, network proxies, access control, security appliances, and services that are extended into the cloud with minimal rethinking.

But there is another aspect to migrating your existing infrastructure to the cloud that often stands to the side of the spotlight. It is one thing to incorporate all the functionality provided by your cloud provider into your technology stack, and quite another to drive cloud adoption in the hearts and minds of your teams.

While a cloud lift and shift will almost certainly mean pushing legacy techniques into the cloud, it is also often the least risky migration strategy. Just getting your existing infrastructure into the cloud means that decision makers signed off the migration, regulatory requirements were addressed, accounts were put in place, teams were trained and skill sets brought to a point where production apps could be hosted and supported in the cloud. All of these changes are mandatory before any of your cloud provider’s shiny services can be used in production, but are only indirectly related to the actual cloud technologies that you may implement.

Our migration was somewhat unique in that we have two mostly independent development teams running on isolated infrastructure within the same corporate structure.

The team I was involved with successfully performed a lift and shift. As a project, it was 80% political and 20% technical, and it came very close to failing due to the pressures that a cloud model placed on an organizational hierarchy that struggled with the concept of DevOps. Had the migration also required a major rethink of the infrastructure topology and included new services, it almost certainly would have failed. But with our lift and shift migration done, we now have time to plan our path towards the goal of being “cloud native”. The path is a long one, and our technology stack is not worth bragging about in its current state, but simply being in the cloud (even with our limited implementation) means we have cleared one of the biggest hurdles.

The second team has yet to make the transition. They still have the luxury of planning a more “cloud worthy” migration but have the significant disadvantage of adapting their people and processes to the mostly non-technical challenges involved. Right now it looks like it will be at least a year before they have any production code running in the cloud, and their shiny new cloud infrastructure only exists on paper.

As much as I would have liked to have left the three-tier architecture behind and adopted DevOps more fully as part of the initial cloud migration, anything more ambitious than a lift and shift migration would probably have failed, and there would not have been a second attempt. At least now we are in a position to iterate on our cloud infrastructure.

I agree with the assessment made by Thoughtworks that moving existing processes, infrastructure and mindsets from on-premise and into the cloud prevents you from harnessing the full potential that the cloud provides. I’ve seen this first hand. But I’ve also seen how easy it is for even a simple lift and shift migration to fail, and nothing will kill your cloud strategy faster than the time and money burned in a failed migration.