"Lift and Shift" is the worst...

Lift and shift cloud migrations are the worst way to deal with legacy technology.

You'd think that by this stage in cloud computing's maturity, all of those platform migrations would be done and dusted. That all the old legacy systems would be consigned to the great server room in the sky. Surely no-one is still running things on-prem, are they?

"Just move everything to the cloud now. We can stop paying all the hosting costs/sell the building/re-purpose the space and downsize the team. Then we can worry about fixing things after we've moved".

I've heard this a lot over the past decade, and I understand the rationale. But in the majority of cases, these headlines are just that - headlines - with limited total cost analysis or operational risk factored in. Whether your organisation has 100 or 10,000 employees, it's likely that you're heavily reliant on some line of business applications. And it's also therefore likely that if you're planning a cloud migration, or have already migrated via lift and shift, you'll need to do something about your architecture.

Those client/server applications you’ve got running on-prem are probably reliant on a whole host of unknown platform dependencies. When you go about moving them as-is to a cloud environment, there’s a good chance you’re not taking all of the old dependencies with you in the way they’re wired together - and in many cases physically - today. But what you are taking are the applications' original limitations, security vulnerabilities, and performance issues.

So what happens when you move? Will it still work? Will it be cheaper to run?

Faced with this dilemma, some teams try and move the whole lot in one go. Surely if everything moves together, it’ll still just work, won't it?

Well, not necessarily - a lot depends on the specific configuration, be it network, storage or even basic things like machine names. Because all documentation has either vanished without trace, has never been written or is so out of date as to be useless, you’ll just never know til you push the?button(s), by which time it’s too late. And when was the last time anyone tested the legacy backup/restore capability?

You could of course phase things, which seems eminently more sensible. Small chunks, migrated over time, with rigorous testing as you go.

But why are you moving anyway? That’ll be because the stack is expensive and outdated, sitting there on 8 year old servers that are no longer supported in a rack down in the basement. By moving it, surely you’re just protecting the business and saving a load of cash in the process in the quickest and easiest way possible?

Unless the total cost of cloud and the trappings that go with it are less than the cost of power and support of keeping it on-prem, or provide tangible strategic benefit (e.g. scale), you might be in for a surprise post-move. That's not taking the cost of change/migration into account either...which is likely to be more than you anticipated too (because inevitably, there's more to the migration than just next > next > finish, and everything takes longer than you think).

In addition, and despite the fact that cloud as we know it has been around for what feels like an age now, some skills are still hard to come by or are at a premium, as many technologists have had to spend more time doing rather than learning - so expect to pay more for new hires and/or invest in training for your team.

Surely though it’ll be easier to unpick the architecture once it’s running on a modern cloud-hosted platform? Well maybe - that’s if it runs at all, virtualisation or no virtualisation. Some legacy code/systems just don't run well on some cloud platforms and it's not beyond the realms of possibility that re-work or re-configuration will be required, especially when "stretching" the front-end, back-end and everything in between through multiple layers of complexity.

So am I against cloud migration? On the contrary, I'm an advocate where there is a solid business case to justify doing so. Furthermore, in some scenarios there’s just no other option but lift and shift. I get it.

But if you do have the opportunity to go through a best-practice assessment and treatment process (like the 6 R’s - rehost/refactor/revise/rebuild/replace/retain), then I'd highly recommend doing so to optimise the financial commitment for the organisation, to protect the uptime of your environment and ultimately, to protect your own sanity during what will potentially be a stressful and drawn-out process.