Brazeal: The lift-and-shift shot clock

The clock ticked loudly. Everybody could hear it. I was working with a company that lived in fear. Fear of breaches at their private data center --  not from hackers, but from the weather. Literal puddles of water formed between the server racks whenever it rained. Legends even told of leftover Fourth of July fireworks stored in a nearby utility closet. The whole place was a time bomb waiting to take down their business: drip drop, tick tock. A “cloud-native” architecture strategy, needless to say, was not this business’s top concern. They had to escape the house of horrors and move into a professionally-managed data center before time ran out. It was a question of survival. For that very good reason, Leaky Servers Inc opted for a “lift-and-shift” cloud migration strategy: they dumped their applications into AWS pretty much as-is, with minimal training and refactoring beforehand. They beat the clock to get out of their data center. But the race against time to adopt the cloud had only just begun.

Lift-and-shift: taking the shot

Not every migration story involves literal fireworks. But you can still find businesses choosing lift-and-shift, instead of re-architecting applications for the cloud, for a grab bag of reasons:

• Urgent need to get out of a data center (because your servers are haunted, or maybe just because of an expiring lease)
• Desire to get some cloud benefits (scalability, lower maintenance, or even lower cost) without incurring the full risk and expense of re-architecting
• As a financial engineering tactic, to shift CapEx burden to OpEx
• As the first stepping stone to cloud adoption, with the goal to take on a more cloud-native approach later, after everyone gets their feet wet

All these can be reasonable justifications for lift-and-shift. And every one of them is potentially dangerous. Because the moment you drop your monolithic, legacy app servers on EC2, you have started a shot clock on your chances for success in the cloud. Tick, tock. Can you hear it?

The lift-and-shift shot clock

You are buying yourself time with a lift-and-shift migration. Time to figure out your next move, time to train up your team, time to convince the business that cloud has value. But the bill for that time comes due fast, and at a high interest rate. That’s because the cloud doesn’t run like your old data center. The cost model is different, the skills are new. And if you change your infrastructure without bringing the rest of your organization along with it, you will find your missing competencies creeping up on you. You need SRE The cloud scales fast; it’s made of ephemeral resources and black-box services coordinated across multiple geographical sites, and it generates tons of telemetry. The only way to cope with these challenges in the long term is automation. The discipline of site reliability engineering may not seem important on Day 1 in the cloud, but the longer you go without it, the more its absence will hurt you. You need governance You moved to the cloud to get better insight on IT spend, to push costs down, to manage risk more effectively. How are you going to do that without automation, without tagging, without isolation of the workloads sharing your legacy monoliths? Continuous compliance isn’t going to happen when you’re still treating your cloud resources like pets. You need a culture of comprehensive learning To get the most out of the cloud, you need people who understand it. A lift-and-shift migration intentionally delays the process of cloud competency, usually with the stated or unstated assumption that team members will pick up new skills along the way. But this doesn’t just happen. As long as team members are stuck in the same grind of firefighting legacy apps, their cloud knowledge will remain ad-hoc, limited, and insufficient to propel the next stage of cloud evolution. You must intentionally perpetuate a cloud culture -- through certification training, incentives, and active efforts to refactor for the future.

Lift-and-shift is not a stable state

The longer you wait to adopt a cloud-native mindset, the more the interest on that lift-and-shift loan compounds. Because your engineers have to do something while they wait for the business to catch up with cloud. In the absence of proper SRE, they build highly manual, slow, error-prone operational procedures that drag down time-to-value and MTTR. Without a clearly-defined cloud center of excellence, they rely on tribal wisdom and faulty mental models of how cloud operates. Lacking cloud-native governance and cost controls, they run the cloud like a data center: expensively. Remember how you went to the cloud to save money? Let me know how that’s working out after two years of lifted/shifted workloads. Every day, those bad habits become more ingrained. You’re not just bringing your old legacy systems to the cloud. You’re building a whole new web of poor practices and procedures around them. And as those temporary stopgaps harden into permanence, you’ll see your brightest engineers leaving for less dysfunctional projects. Eventually, if you can’t take the step forward into cloud-native, the positive value created by the lift-and-shift will be overwhelmed by its negative side effects. If all software eventually becomes technical debt, lift-and-shift migrations are payday loans. The benefits are heavily frontloaded, and the longer you hold onto them, the deeper they put you in a hole. So lift-and-shift if you must. If your data center is on fire, lift-and-shift immediately! But don’t put off a true cloud transformation. Because you’re racing the shot clock. And as the 70% failure rate for large-scale change projects attests, the clock likes to win. Tick, tock. Can you hear it?

---

Beat the lift-and-shift shot clock with ACG Certification Accelerator

---

Forrest Brazeal is an AWS Serverless Hero and enterprise architect who has led cloud adoption initiatives for companies ranging from startups to the Fortune 50.