Justin Campbell CTO@junkshon
There’s a fairly common misconception that the primary goal of cloud migration is to move an IT estate to one of the big hyper-scalers so it can be accounted for as opex, as opposed to capex. In other words, it’s a ‘lift & shift’ operation. In reality, this not only massively underestimates the transformative potential of a move to the cloud but is based on something of a false premise.
If we use the language of Gartner’s 6Rs (Rehost, Replatform, Refactor, Repurchase, Retain, Retire), lifting and shifting is basically either a Rehost. Essentially, you’re picking up existing workloads and moving them. And while this is a smart move for applications that aren’t revenue generation opportunities – established systems of record, for example – you might find you’re taking an IT estate full of technical debt, inefficiency, legacy and redundancy, and dumping the whole mess into someone else’s data centre. In other words, you’re improving nothing and, what’s worse, you might find you’re spending even more than you were before.
While relocating your ERP system in the cloud might feel like a quick win, it’s actually much more productive to consider testing the waters with a handful of small, manageable projects where there are obvious business benefits to migration. It might be you focus on areas where there are high levels of technical debt, but you’ve also got to look at a variety of other inter-dependencies and the potential value you can unlock via cloud-native optimisation.
The methodology we use at Junkshon involves running models in our ASPIRE platform that look at attributes and map each application or infrastructure element with one (or occasionally more) of the 6Rs. We also occasionally add a 7th ‘R’ – more on that shortly.
The 6R analysis is a classic example of the nuanced decision-making that’s required when putting together a cloud strategy. Perhaps we have some applications that we see continuing to make a strategic contribution to the business for at least another 2-3 years, in which case it’s worth modernising the entire code base of those applications so they can run natively in the cloud (Rearchitect). Other applications might be more appropriate for Replatforming, where we reinstall them on cloud infrastructure without necessarily fully modernising or redesigning them, but we still leave behind the technical debt that’s been incurred.
And at the other end of the scale, where is it better to do nothing, perhaps an old mainframe or an unsupported application (Retain), or scrap an application that’s going to be made redundant by the capabilities of the cloud vendor’s own platform (Retire). When organisations lift and shift everything without going through this kind of process, they find themselves paying for systems in the cloud that they simply aren’t using, and never will.
The last of Gartner’s 6Rs is Repurchase. Let’s say you’re considering what to do with your CRM system. You can either custom-build a CRM solution from scratch or simply buy the cloud edition of the same application – in other words, Repurchase the same application in native cloud form.
The 7th R I mentioned earlier is something we at Junkshon are starting to talk about, and that’s Reinvent. Microsoft, with its Power Platform, and Amazon with Honeycode, are both innovating in the emerging field of ‘citizen development’ based on these new ‘low code’ development platforms. We’re essentially seeing applications being ‘reinvented’ using these tools, putting the power with your business users rather than with technically-trained developers.
The point here is that cloud migration is complex, but it’s also a brilliant opportunity for companies to rethink their IT so it delivers much more for much less. The ‘lift and shift’ mentality overlooks both these factors.
There are times, of course, where time pressures force the issue, and a quick Rehost seems to be the only option. And while that’s not optimal, it’s also not the end of the world.
At Junkshon, we spend a lot of time talking about cloud optimisation – looking at workloads that are already in the cloud and considering ways of improving performance. That approach can also apply to those situations where deadlines have resulted in a quick migration. There’s always time to apply the other 6Rs.