After much persuasion, deliberation and perhaps a couple of false starts, the board has agreed to a full cloud migration. Now what?
Three paths to keep your cloud strategy on track
Gartner first outlined the ‘5 Rs’ of cloud migration in 2011. Microsoft broadly follows this framework – albeit with some additions and adaptations. More recently, AWS’ Stephen Orban has written extensively about the ‘6 Rs’. But the trouble with all these Rs is that most of them aren’t very intuitive. What’s more, some of these not-very-intuitive words have different meanings depending on where you look. For instance, ‘refactor’ can refer to moving to Platform as a Service or a complete rewrite.
The upshot is that any discussions about cloud migration approaches can be inherently confusing – and this is a problem. The 2018 Accelerate: State of DevOps report is very clear about the importance of how you implement cloud technology: “teams that leverage all of cloud computing’s essential characteristics are 23 times more likely to be high performers”.
In our experience, the various Rs of cloud migration are much easier to digest if you just look at three simple paths. There is no ‘best way’. In fact, most businesses will use a combination of the three. The main decision is whether to modernise as you move, or afterwards. But there is a very clear ‘wrong way’, which is to move to the cloud and not modernise at all.
Here, we look at the merits of each migratory path – along with associated compromises and risks – so you can plan your journey and arrive in good shape.
1. Lift and shift
This is often perceived as the natural choice by those from a traditional infrastructure background. Gartner and AWS call it ‘rehosting’. It’s essentially the bulk replication of machine images onto Infrastructure as a Service.
A decade ago, VMware migrations were typically automated in this way, and it was impressive at the time. But it unlocks minimal capabilities from highly functional cloud platforms. Legacy headaches are replicated, and until you optimise, headline costs will be higher (although AWS estimates a typical 30% total cost of ownership reduction from lift and shift, when you’re honest about your on-premise costs).
Some people (you might call them ‘purists’) are deeply opposed to this approach. But it’s fast, and there’s a strong argument that it’s easier to modernise after you move – not as you move. Lift and shift is widely used and has its place.
Why would you take this path?
This is the quickest and simplest route to the cloud. It’s favoured when there’s a hard deadline looming, such as a datacentre closure, a hardware refresh or some other big renewal. Chances are, it’s a good option for some of your estate, but a more involved approach would be better for applications closer to core value streams.
…and why wouldn’t you?
You’re going to take all your legacy problems with you, and there’s no immediate opportunity to exploit even basic cloud-native capabilities such as auto-scaling.
This infrastructure-led approach requires relatively low effort, represents low risk and is certainly the fastest way into the cloud. But it all adds up to low return.
2. Evolve
There are many middle ground approaches between lift and shift and a full rebuild. They’re ‘infrastructure-led’ and don’t make any attempt to change architecture or user features. But
they’ll generally require some developer involvement and tweaks to make sure everything keeps working in the new cloud environment.
This path captures the strategies that Gartner and AWS refer to as ‘replatforming’, ‘revising’ and ‘refactoring’. Applications might be containerised, or there could be a shift to PaaS options like Azure Web Apps or AWS’s Elastic Beanstalk. Alternatively, an ‘everything-as-code’ approach could see redeployment into a freshly defined, immutable VM-infrastructure, with scale-sets and advanced recoverability options.
When you evolve, you are simply improving operability and doing so at the infrastructure layer. The existing codebase can be reused in the more effective cloud environment, and you don’t need to dramatically reskill dev teams or adopt new languages or frameworks.
Watch out for missing features in PaaS offerings, though. Even in this increasingly mature market for PaaS, some features from installable versions of software, such as SQL Agents, are missing cloud counterparts.
Why would you take this path?
This is the quick route to partial modernisation. It’s an opportunity to improve reliability, operability and costs without rearchitecting or significant recoding. Containers can also overcome concerns around code portability and are useful for migrating legacy systems.
…and why wouldn’t you?
This approach walks the middle ground between risk and reward, which translates into medium return.
3. Go native
The stakes are high with this approach. Few development teams combine an intimate understanding of core application(s) with deep knowledge of the target cloud platform. Diving straight into this demands that developers rapidly get a handle on new technologies and adopt new ways of working. However, with the right architecture, and knowledge gained through migration of other applications, this approach delivers high returns. The 2018 Accelerate: State of DevOps report found that teams running cloud native applications were 1.8 times more likely to be in the elite performing group.
Cloud-native apps are designed for the cloud, so assume that the infrastructure they run on is inherently unreliable, but also controllable. They should be largely self-aware, self-scaling and self-healing. Typically, they’ll also embrace as-a-service features from the cloud vendor, which means that a lot of functionality is simply consumed rather than written into the code.
Going native is expensive upfront, but perhaps less so overall than a phased lift and shift followed by gradual redevelopment. And avoiding vendor lock-in becomes very challenging, so switching provider could mean abandoning IP and rebuilding from scratch.
Why would you take this path?
Organisations that go native typically hold innovation as the primary goal of their cloud strategy. It’s the best route when long-term agility, feature development, scaling and performance are critical.
Going native is also an excellent opportunity to rearchitect and embrace micro-services or remove serious amounts of technical debt. However, it does carry the risk of accruing new debt – especially if you have limited experience working in the cloud.
…and why wouldn’t you?
Only 16.2% of software projects come in on-time and on-budget (according to the CHAOS report). Going native is a major redevelopment, with high costs and inherent risks.
Going native increases developer productivity and leverages effective cloud-native technologies to unlock agility, scale and speed-to-market. As a rule of thumb, investing more upfront unlocks greater value from the cloud.
Go your own way
There will always be an element of compromise and risk. It’s important to be pragmatic, be clear on your goals, and make decisions aligned with core objectives.
So, by all means, read and debate the various strategies and considerations put forward by vendors and cloud migration experts. But since you cannot plan everything in advance, just take action, learn, and avoid the analysis-paralysis trap. Don’t underestimate the value of on-the-job learning: start with impactful but lower risk projects before jumping feet-first into a large-scale programme.
