Thinking beyond the 7Rs of cloud migration

Agility

Change management bottlenecks, stakeholders’ unavailability, complex migration defects and sudden changes in scope, leadership, schedules and priorities, to name a few, are factors that can derail a migration project. Therefore, as an organisation operates amid unstable circumstances, it is important to adopt agile principles, in terms of people and processes, to achieve enough resiliency to cope with unforeseen variables that might come up during a migration.

Collaboration

From infrastructure and security teams to change management and business decision makers, a large-scale migration requires collaboration across different teams with diverse functional responsibilities. Hence, it is important for these teams to work together harmonically to resolve any communication silos and to be properly aligned.

Since each team handles many responsibilities other than the migration itself, it will be effective to have assigned individuals from every team who are dedicated for the migration to avoid any conflict of priorities. Adopting a defined and agreed RACI model (responsible, accountable, consulted, informed) would enable clarity and alignment whereby teams and individuals are aware and accountable for their assigned tasks and responsibilities.

Communication

Every migration project should be driven by effective communication. This can be realised by an established communication cadence, such as a daily standup meeting, where status updates, emerging challenges and tasks are thoroughly discussed across all stakeholders to get input and alignment.

Review calls are also recommended following migration efforts or sprints to discuss lessons learned for possible adoption in future waves. A clear communication channel should be in place for any ad hoc calls and a notification process to inform all stakeholders of the start and end of every migration wave. In parallel, a clear escalation matrix should be defined to ensure the right people are contacted and the right decisions made should challenges arise.

Methodology

An assessment of an organisation’s readiness should be the starting point of any migration to identify potential technical and operational gaps.

A thorough infrastructure discovery will define the migration plan and the treatment of every application while keeping modernisation as a preference wherever possible.

As the migration waves start to unfold, a continuous improvement mindset and a bias for automation are vital to improve migration efficiency.

Understanding dependencies

An application can be dependent on foundational services or applications, while also being a dependency for other applications. In some scenarios, multiple applications might be sharing the same configuration or services, introducing complexities for both the migration approach and the stakeholders involved. Determining how an organisation’s different applications and components are intertwined together is key for a successful migration.

Verification, testing and pilot

Running pilot migrations prior to migrating the actual production workload validates the migration process and provides an idea of what to expect during a live migration. In addition, it offers a chance to resolve potential gaps or faults in the migration tools and methodology beforehand. The test outcomes can be documented by artifacts to inform subsequent production migrations. Testing is also crucial post-migration, where the technical health checks and the business functionalities of newly-migrated applications are tested and compared against pre-migration results to identify any resulting defects and to verify the success of a cutover.

Minimal business disruption

A successful migration is one with the least collateral damage possible. However, when it comes to migrations, downtime is inevitable. Nevertheless, it is possible to control this downtime by scheduling migration windows in a way to have the least impact on the business (e.g., outside peak times). The output collected during pilots can inform the duration of the downtime window, as explained earlier, while always factoring in some planned space for rolling back in case the cutover doesn’t go as expected.

Beyond the 7Rs

The 7Rs treatment strategies (Rehost, Refactor, Replatform, etc.) define the different approaches to cloud migrations. Where possible, organisations should look to transform every application migrated to cloud (to varying degrees), otherwise the benefits of cloud will not be realised.

While a rehost migration approach is “good enough” and can help move wholesale workloads into a cloud platform, organisations that undertake a rehost approach are unable to fully leverage the complete advantages that cloud enables, such as PaaS and serverless services, automation, DevOps practices, elastic scaling and healing. Without elastic-scaling, infrastructure is usually overprovisioned to cater to availability zone outages. In addition, with rehost, since the application architecture will stay the same, any technical debt, in terms of software, security, integrations and design, that existed prior to the migration, would be carried on to the cloud.

As a result, extra efforts should be taken in the future to resolve those inherited issues. Organisations will find applications which have been rehosted are more expensive to run in the cloud and would then need to invest additional funds later to transform it to a modern architecture.

In comparison, a transformative migration approach is where the application is refactored and/or re-platformed to a minimum level, where the advantages in cloud (elastic scaling, auto healing) can be realised and best practices followed. This entails a migration approach where the application infrastructure and software are built, configured and installed utilising CI/CD pipelines, automation, configuration management tooling and infrastructure as code following a DevOps or site reliability engineering (SRE) approach.

This approach also leverages foundational cloud-native services such as cloud load balancers and, where possible, immutable application machine images are built (utilising a golden machine image as its starting point). Where possible, the database is migrated to a Database-as-a-Service offering using the same DB engine. Moreover, the use of infrastructure as code significantly speeds up deployment and makes it easy to replicate your environments.

As each application and infrastructure is re-architected and re-built on the latest machine images, Database-as-a-Service and using cloud firewalls (e.g., security groups), much of the technical debt is removed through the migration process.

While a transformative migration approach requires more time, effort and initial cost, in the long run it will cost less to run, while being more operationally resilient and providing the ability to adopt modern practices such as DevOps and SRE.

Organisations should look beyond the 7Rs and look to adopt the services available on their chosen cloud platforms through (project and ongoing) transformation, to leverage the benefits of cloud and take full advantage of their cloud service investment and technology.

Read the results of our 2023 Global Technology Executive Survey: The Innovation vs. Technical Debt Tug-of-War.

To learn more about our cloud consulting services, contact us.