Alisdair Brown

by Alisdair Brown

Enterprises are at different stages of cloud adoption. A sizable proportion of enterprises are already taking a ‘cloud first’ approach, where the hosting of systems will be in the cloud by default. However, for enterprises embarking on the cloud ‘journey’, it’s imperative to adopt a structured approach to ensure a smooth transition and successfully achieving the expected outcomes avoiding the common pitfalls often seen in a cloud migration.

In this article we will discuss Seven Consulting’s practical experience of project managing cloud migrations and provide some learnings for you to consider when you are managing your own cloud migration.

Cloud Migration Project Business Case

Learning #1 – The ‘Whole of Life’ cost of the Cloud Migration needs to be considered in your Business Case

Like all good projects Cloud Migration projects should begin with a business case underpinned with clear expectations of the value the project will deliver. The business case process is important to clarify Executive expectations and ties-in stakeholders to the migration process.

The business case should not only include timeline and effort to migrate but also potential set-up of the target environment and support model; known operational and regulatory risks (Data sovereignty and required security and resilience levels i.e., Multi-site, Australia based, ASD IRAP accreditation), high-level resourcing (Cloud skilled staff will demand a premium in the market) and of course the cost of undertaking all of this.

Potentially there may also be related, although unintended costs, to be considered e.g., uplift of the Service Management capability to implement in a hybrid Cloud environment and uplift of network capability due to support changing cloud traffic volume and patterns.

Learning #2 – Leverage Cloud provider expertise and incentives but be wary of lock-in

Engaging with Cloud service providers or implementation partners to leverage their expertise in cloud migration journey can also be valuable. Most Cloud Providers will have established blueprints or frameworks incorporating best practices for migration related to specific workloads.

Additionally, Cloud partners may offer significant financial inducements if workloads are migrated to their Cloud e.g., Support building the business case; provide ‘sandpit’/proof of concept environments for free, discounts on subscriptions based on volume of workload migrated to their Cloud etc. but careful of lock-in.

Learning #3 – Tangible Financial Benefits are hard to derive and even harder to measure. Create a basis to measure benefit against.

Determining your existing onsite system costs allows later comparison with cloud providers estimates for determining the overall total cost of your environment ownership and whether cloud migration project benefits have been met.

Until all your services are moved to the cloud then existing and new services will have to be maintained and paid for. These additional ongoing operational costs also need to be included in the Migration business case.

The Migration Delivery Lifecycle

Migration to the Cloud follows a generic delivery lifecycle :

The Discovery Phase involves a deep dive of your existing infrastructure and applications landscape building a comprehensive view of the end-to-end systems environment. The discovery process identifies workloads and the platforms (servers) on which they run (physical and virtual), storage devices and databases, resource-usage patterns, networks and components, relationships, and dependencies among all these elements, as well as the associated costs of ownership and operations

Learning #4 – A deep understanding of what you are migrating is critical to understanding the feasibility and suitability to migrate and the risk of doing so (including regulator risk)

Discovery, hopefully using automated tools, answers three important questions:

  1. Are we (“the organisation”) ready for the cloud? i.e., feasibility and capability to migrate to the Cloud e.g., Skills, processes, roles & responsibilities
  2. Does a maintained CMDB exist with active discovery tools and service mapping capability?
  3. What is the current application workload and technology landscape?

Learning #5 – Engaging the Owners and Supporters early creates buy-in and support for the migration project

Apart from creating an inventory of workload information, the Discovery phase also provides the opportunity to engage stakeholders from outside the IT department in the migration process and provides early insight into potential project risks requiring the identification of application owners and those who support the applications (who could be external to your organisation)

A key output of the discovery assessment is the relative importance of the application to each business unit.  This helps with the understanding the operational and strategic advantages of moving specific application workloads to the cloud, as well as helping with the phasing of the workload migration. In a regulated environment you need to engage the regulators early and set a cadence for ongoing engagement.

In the final stage of the Discovery phase a Suitability Assessment should be undertaken. The Suitability Assessment works across four dimensions which may require scarce specialist skills:

  • Business —prioritise business and IT needs to gauge cloud adoption feasibility at an organisational level
  • Financial —establishes the financial feasibility of cloud adoption and justify the ROI of application workload migration to the cloud
  • Technical —map applications requirements/features against equivalent cloud platforms (Public, Private, Hybrid, Multi-cloud, SaaS, PaaS) to determine technical fit
  • Application functionality —map application workload functionality to the cloud platforms of choice (mapping includes IT environment and application dependencies, workload categorisation, automation of development and operations, reference architectures, and infrastructures)

The Migration Strategy adopted by an enterprise to migrate their applications to the Cloud will largely be influenced by:

  • Time to migrate
  • Budget available to migrate
  • Degree of value realisation required e.g., Need to enable new initiatives e.g., CI/CD, future proofing, etc.

Learning #6 – Migration strategies need to be carefully considered vs the benefits to be achieved from the Cloud migration.

Note – Most enterprise environments are not ‘beautifully’ architected. In order to be cost effective, cloud environments are standardised and well-architected built to operate automated processes at industrial scale. This means that your applications typically need to fit into much more structured environment which you don’t have entire control over.

Having a decision-making model to decide how you get to the cloud (or not) is therefore critical

The defacto industry approach to assess application cloud migration is known as the ‘6R Approach’…

© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.

  1. Re-host or ‘Lift and Shift’ – Applications are moved out of on-premise data centres into the cloud environment ‘as-is’. The ability to undertake this path for most enterprise applications is typically not possible due to source system complexity due to a legacy of multiple integrations, bespoke change and support available for the system components.
  2. Re-platform – Significant changes to the underlying system infrastructure with minimal code of the applications prior to cloud migration. Again, typically difficult for most enterprises but an option to benefit from a migration from physical to virtual environments. Careful not to creep scope into (3) …
  3. Re-factor – Applications are re-written to leverage cloud native features; the core architecture of the applications remains unchanged. Re-factor can become a very common approach to Cloud Migration as the drive to migrate to the Cloud outweighs the effort of enabling applications so they can migrate. Which often leads to (4) …
  4. Re-purchase – Applications are replaced with more functional, ‘cost-effective’ Software-as-a-Service alternatives. This is a Strategic choice and should become a whole business case in its own right.

Learning #7 – There is always the option not to migrate or better decommission legacy applications

And often the forgotten 6R approach options, which should always be considered especially if the effort of Options 2 to 4 outweighs the business case for migration:

  1. Retire – Applications found no longer to be of any value to the company are decommissioned. This can be a key benefit of cloud migration projects driving real savings through simplification in the IT landscape. In these projects care must be taken that the application is ready for retiral. Active monitoring throughout the retiral process is required to ensure it is!
  2. Retain – Applications that have been agreed to be retained on-premise and not candidate for cloud migration. Examples may be critical security systems i.e. An enterprise’s ‘crown jewel’ systems.

Learning #8 – A key output from Discovery and Migration Strategy phases is the creation and approval of Treatment Plans which outline details of the approach as well as any associated changes required to ensure successful application migration to the target cloud

Learning #9 – Preparation for Migration Execution is a project in its own right with activities required across the Provider & Host’s Operating Model: Process, People and Technology

Prior to undertaking Migration Execution consider that although Cloud Providers will typically prepare the Cloud Target, they will expect client organisations to own certain critical elements of the new E2E hybrid environment. Some examples:

  • Data Security – will require an assessment of the current data and systems controls ensuring the principle of least Privileged access. Including a review of the ancillary data usage in test and development environments, as what was considered acceptable when the application was first built may have changed e.g., need for encrypted data
  • Network – For workloads sensitive to latency and high network bandwidth network requirements, additional network deployments such as Direct connect to Cloud provider, CDN or deploying resources closer to users’ geographical location might be required.
  • Support Operating Model – a new Support Model will require to be established with perhaps the necessary implementation of new ITSM tooling, a support organisation straddling Client and Cloud Provider organisations, processes that integrate and enable adequate support…

These aspects all need to be readied prior to execution proceeding and either should be considered in the Migration Business Case or as a separate dependent project.

The Migration Execution phase is typically planned using wave-based planning where migration ‘waves’ are scheduled and executed based on application workloads treatment planning. Manage your waves like backlogs with each consisting of a group of application workloads that have the same cutover date. The execution of the respective waves is run in parallel using agile/scrum-based approach. Waves should be constructed to enable early migration success, proving migration processes while minimising risk to service.

‘Scrum of Scrum’ meetings between the respective migration waves at a pre-decided cadence will help to align on the risks, assumptions, issues, and dependencies encountered by the respective migration wave teams. Centralised dashboards and reports should be made available to all stakeholders acting as information radiators providing real-time information on the respective migration progress and other information.

Learning #10 – Careful consideration of migration waves should be considered to balance risk vs opportunity of migration

The dynamic provisioning of cloud resources enables undertaking ‘proof of concepts’ of planned workload migrations. However, a full scale functional, regression and performance testing prior to the migration cutover will avoid any surprises postproduction cutover. Expect early wave ‘failures’. Retrospectives of those ‘failed’ waves will improve the performance of later waves.

Testing effort is significantly impacted by the 6R approach undertaken. From straight forward Regression Testing for ‘Rehosting’ migrations to full system adoption testing phases for ‘Re-Factor’ and ‘Re-Purchase’ approaches.

Learning #11 – Functional migration is important but don’t forget to prepare for the many non-functional changes required to enable secure and supportable services in the Cloud

A parallel run of both the on-premise and Cloud environment will enable to provide monitoring of application performance against production workloads whilst retaining the legacy environment.

A Disaster recovery or Rollback plan in case of failure at component level is also recommended for mission critical applications to reduce downtime and provide a contingency plan in case of critical system outages.

Learning #12 – Test & Learn of your repeatable (and ‘as far as possible’ automated), ‘industrialised’ implementation approach is required to ensure migration pace and quality of multiple parallel deployments into the target cloud environment while ensuring production service is protected

Learning #13 – As a minimum the service that was available before the Cloud Migrations should still be there after!

The Post-Migration Enablement Phase ensures that migrated applications perform at the same level or higher in the target cloud environment and that the applications continue to maintain or enhance the same business functionality that they supported before migration.

Learning #14 – Cloud Migrations can enable step changes in organisation ‘ways of working’ but should face same benefit delivery scrutiny as any other projects

This phase should set up the business to measure the effectiveness of the cloud initiative and to assess its ongoing value. That assessment includes:

  • Did we achieve operational advantages in terms of cost, ease of use, etc.?
  • Did we achieve strategic advantages?
  • Did we achieve an economic advantage in terms of profitability?

Post-Migration Enablement ensures that things work as expected today and puts the business in position for continuous improvement moving forward. This phase may continue for an elongated period after completion of migration and needs consideration in the project business base and planning.

This phase is also the next stage of planning to enable some of those intangible benefits that the cloud migration business case promised i.e., implementing cloud enabled, value-add IT processes previously not possible e.g., support for DevOps and CI/CD processes to enhance application lifecycle management processes.

Conclusion

The approach for undertaking Cloud Migration projects is well documented. There are also many resources. Cloud providers now have platforms, optimised services, accredited partners, and a wealth of freely available IP to help you successfully migrate as well as money to help you migrate to their Clouds.

But there are many common risks that need to be considered each of which manifest in a unique way in each enterprise:

  • Clarity of tangible benefit to be derived from the cloud migration
  • Enterprise cloud strategy and related regulatory landscape
  • Application ownership and support and engagement of those critical stakeholders
  • Unexpected but related costs e.g., network upgrades
  • Lack of information regarding workloads/services to be migrated
  • Application change required to enable successful migration to standardised target Cloud environments
  • New operating model required to support the cloud e.g., Support ownership and roles, ITSM platform, support processes, SLAs and KPIs

From a Seven Consulting perspective managing those risks and other pitfalls involved in Cloud Migration projects can be mitigated by undertaking a structured approach considering the learnings outlined.