I recently shared my thoughts on cloud migration. In particular, I wrote about the 5 R migration approach not working. If you have not come across the 5 R approach, it has been advocated by Gartner and versions of it have been outlined by various cloud providers and consultancies. The 5Rs in question are – Rehost, Refactor, Revise, Rebuild, or Replace. You can find the original blog here.
Building on experiences on the ground I want to expand on the challenges of that approach and provide some practical recommendations for alternatives that deal with the realities across the technology estate. The devil is always in the detail and the detail rarely sits comfortably with the abstractions in architecture diagrams.
Castles built on sand
One of the founding principles of many migration approaches has the starting point being is an extensive discovery process. This can be a drawn out, expensive process that ultimately fails for a range of reasons: –
- Very few companies have the data needed for discovery to hand. The data needed to make meaningful decisions includes architecture layers, components, COTS vs in house build, language and version, build/test/release automation tools, interfaces/dependencies
- At its core, this process gathers information your teams already know into a central location for management purposes, this is inefficient and costly.
- Large organisations have a large and heterogenous environment, the amount of variation will be significant making discovery complex
- Invariably you will miss key data points needed to make the decision on which “R” is appropriate.
- Assessing a large part the application portfolio up front when migrations will proceed at a slower pace wastes resources better used elsewhere
Building Bridges
The core of any great plan is a solid foundation. In the case of cloud migrations this means defining and building a cloud platform for the applications to be migrated into. The focus should be on the following:-
- Ensure the cloud platform team includes security and risk people to input into requirements up front
- Build the base cloud platform with connectivity to on premise solutions
- Define the capabilities the cloud platform needs to offer based on the outcomes the business wants from a migration. EG. SQL DB, NoSQL DB, API Gateway, Containers, etc
- Establish a service catalogue of components that fulfil the capabilities, which will likely be a combination of CSP provided and other vendor solutions.
- Create a standardised automation pipeline for CI/CD based on self-service and evergreen principles
- Build a team, funding and operating model to provide ongoing support and iteration of the cloud platform
Hive of Industry
The obvious temptation when taking on a challenge of a very large-scale migration is to take a factory approach. The factory approach in theory enables applications to be migrated at a marginal cost.
The immediate challenge with creating a separate team to commoditise the migrations is that the day-to-day application knowledge is not going to be in this central team. The hands-on knowledge is going to lie with the teams and individuals who build, own and operate the solutions.
My recommendation is to use the existing teams to do the migrations once the cloud platform is established. Involving the solution teams has a double benefit. They already know the information needed for discovery and involvement in the migrations will help train and familiarise them on the cloud technology they will use post migration.
Target Rich
Starting with the end in mind may seem like an obvious place to begin but a surprising number of organisations fail to do this. Establishing a goal and business outcomes up front is critical to help teams make the choices through the migration process.
The risk with using existing teams is that they do not understand or achieve the outcomes needed. Setting up a series of KPIs aligned to business outcomes will set the framework for the cloud migration. The key to establishing a successful set of KPIs is the level of granularity. Too granular and everyone will be lost in the detail, to generic and it will be meaningless.
These are some of the criteria to consider when setting the KPIs.
- Define the priority outcome the organisation is looking to achieve as part of the migration (run cost reduction, agility, evergreening, etc)
- Different priorities can be established for apps based on strategic intent (build new vs migration of existing)
- Establish a set of KPIs based on the agreed priorities
- A central team established to provide advice, guidance and funding based on teams agreeing to the KPIs
Conclusion
The complexity of migrating to cloud is all about the detail of an organisation’s application landscape. The 5 Rs approach does not expose this detail and creates an overly simplistic view for senior management, which drives unrealistic expectations. Avoid the 5 Rs approach, focus on the cloud platform and federate the migration to the existing teams who already understand the complexity to create a successful cloud migration program.
