The 5 or 6 Rs of cloud transformation

A few years ago, a couple of colleagues showed me something they had been working on – a “5 Rs” approach to classifying applications for cloud transformation. It was adopted for use in client engagements but I decided it needed to be extended – there was no “do nothing” option, so I added “Remain” as a 6th R.

I later discovered that my colleagues were not the first to come up with this model. When challenged, they maintained that it was an original idea (and I was convinced someone had stolen our IP when I saw it used by another IT services organisation!). Research suggests Gartner defined 5Rs in 2010 and both Microsoft and Amazon Web Services have since created their own variations (5Rs in the Microsoft Cloud Adoption Framework and 6Rs in Amazon Web Services’ Application Migration Strategies). I’m sure there are other variations too, but these are the main ones I come across.

For reference, this is the description of the 6Rs that we use where I work, at risual:

  • Replace (or repurchase) – with an equivalent software as a service (SaaS) application.
  • Rehost – move to IaaS (lift and shift). This is relatively fast, with minimal modification but won’t take advantage of cloud characteristics like auto-scaling.
  • Refactor (or replatform/revise) – decouple and move to PaaS. This may provide lower hosting and operational costs together with auto-scaling and high availability by default.
  • Redesign (or rebuild/rearchitect) – redevelop into a cloud-aware solution. For example, if a legacy application is providing good value but cannot be easily migrated, the application may be modernised by rebuilding it in the cloud. This is the most complicated approach and will involve creating a new architecture to add business value to the core application through the incorporation of additional cloud services.
  • Remain (or retain/revisit) – for those cases where the “do nothing” approach is appropriate although, even then, there may be optimisations that can be made to the way that the application service is provided.
  • Retire – for applications that have reached the end of their lifecycle and are no longer required.

Right now, I’m doing some work with a client who is looking at how to transform their IT estate and the 5/6Rs have come into play. To help my client, who is also working with both Microsoft and AWS, I needed to compare our version with Gartner’s, Microsoft’s and AWS’… and this is what I came up with:

risualGartnerMicrosoftAWSNotes
ReplaceReplaceReplaceRepurchaseWhilst AWS uses a different term, the approach is broadly similar – look to replace/repurchase existing solutions with a SaaS alternative: e.g. Office 365, Dynamics 365, Salesforce, WorkDay, etc.
RehostRehostRehostRehostAll are closely aligned in thinking – rehost is the “lift and shift” option – based on infrastructure as a service (IaaS) – which is generally straightforward from a technical perspective but may not deliver the same long term benefits as other cloud transformation methods.
RefactorRefactorRefactorReplatformRefactoring generally involves the adoption of PaaS – for example making use of particular cloud frameworks, application hosting or database services; however this may be at the expense of portability between clouds. The exception is AWS, which uses refactor in a slightly different context and replatform for what is referred to as “lift, tinker and shift”.
 Revise  Gartner’s revise relates to modifying existing code before refactoring or rehosting. risual, Microsoft and AWS would all consider this as part of the refactoring/replatforming.
RedesignRebuildRebuildRefactor/re-architect.Gartner defines rebuilding as moving to PaaS, rebuilding the solution and rearchitecting the application.

AWS groups its definition of refactoring and rearchitecting, although the definition of refactor is closer to Microsoft/Gartner’s rebuild – adding features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment (for example.
  Rearchitect Microsoft makes the distinction between rebuilding (creating a new cloud-native codebase) and rearchitecting (looking for cost and operational efficiencies in applications that are cloud-capable but not cloud-native) – for example migrating from a monolithic architecture to a serverless architecture.
Remain  Retain/revisitPerhaps because their application transformation strategies assume that there is always some transformation to be done, Gartner and Microsoft do not have a remain/retain option. This can be seen as the “do nothing” approach but, as AWS highlights, it’s really a revisit as the do nothing is a holding state.
Maybe the application will be deprecated soon – or was recently purchased/upgraded and so is not a priority for further investment. It is likely to be addressed by one of the other approaches at some point in future.
Retire  RetireSometimes, an application has outlived its usefulness – or just costs more to run than it delivers in value, and should be retired. Neither Gartner nor Microsoft recognise this within their 5Rs.

Whichever 5 or 6Rs approach you take, it can be a useful approach for categorising potential transformation opportunities and I’m often surprised exercise how it exposes services that are consuming resources, long after their usefulness has ended.

Digital transformation – it’s not about the technology

For the last few years, every IT organisation has been talking about “digital”. Digital this, digital that. “Digital transformation” has become a buzzword (OK, two words), just like “Cloud” in 2010 or “Big Data” a few years later.

But what do we mean when we talk about digital transformation? It certainly caused a stir in my recent team meeting.

To answer that, let’s look at three forms of transformation – Cloud, Business and Digital – and how they build on each other:

  • Cloud transformation is about tools and technology. It’s often IT-led (though it should involve business stakeholders too) and so it’s the domain where us techies are most happy. Often, it involves creating new platforms, using cloud services – Azure, Amazon Web Services, Office 365, G-Suite, Dynamics 365, Salesforce. But cloud transformation is just an enabler. In order to deliver value, business transformation is required.
  • Business transformation is about re-engineering internal processes to better serve the needs of the business and improve the way in which services are delivered. It’s about driving efficiencies and delivering better outcomes, but still focused on the way that a business (or other organisation) operates. Business transformation should be business-led but will often (but not always) demand new platforms and services from IT – which leads back to cloud transformation.
  • Digital transformation relates to the external interface with clients/customers/citizens/students. This is the domain of disruptive innovation. Evolve or become extinct. It’s often spoken about in terms of channel shifting – getting people to use digital services in place of older, more laborious alternatives but, ideally, its complementary, rather than replacing existing methods (because otherwise we run the risk of digital exclusion). Importantly though, it’s no good having digital transformation without business transformation and, like business transformation, digital transformation should be business-led.
Cloud, Business and Digital Transformation

Let’s take an example of digital transformation: when my bins were missed from a council waste collection, I logged a call via my local council’s website, which created an incident in a case management system and within an hour or so the bin lorry was back in my street because the driver had been alerted to the missed collection on his in-cab display. The service was excellent (OK, there was a mistake but it was quickly dealt with), the resolution was effective, and it was enabled using digital technologies.

But here’s another example. When I was held up in the neighbouring county by some defective temporary traffic lights at some roadworks, the local authority‘s out of hours phone service wanted me to channel shift to the website (not appropriate when driving a car). It also couldn’t cope with my problem – the out of hours phone service ended up at a random mobile voice mailbox. In the end, I called the Police on 101 (non-emergency) when really some basic business processes needed to be fixed. That shouldn’t necessarily require a technical solution but digital transformation of external services does rely on effective internal processes. Otherwise, what you have created is a shiny new approach on the outside, with the same clunky processes internally.

Hopefully this post has helped to describe the differences between cloud, business and digital transformation. But also consider this… digital transformation relies on business transformation – but not all business transformation needs new IT… the important thing is to identify the challenges being faced, the opportunities to innovate, and only then consider the platforms that are needed in order to move forwards.