Completing a cloud migration on time and to budget

Five years ago, I would have mistakenly assumed most organisations were in the cloud, but as we continue to discover, many still have plans to move more workloads to Cloud (or between Clouds).

So, what is the key to a successful migration? 

In Softcat’s experience, it comes down to planning and an effective migration plan, to be specific. 

This is a plan that evolves as the level of detail grows and should be viewed as any other migration plan – it doesn’t need to be cloud-specific. However, it’s worth noting that some organisations advocate an ‘Agile’ approach to planning and migration. At a high level, your organisation’s appetite and expectations of change should drive your decision regarding this versus a ‘waterfall’ approach. In our experience, a waterfall approach is typically better suited to an infrastructure-style cloud migration, whereas Agile is better suited to an application modernisation project. Also not forgetting projects that combine both of these outcomes (migration and modernisation).

In this blog, we explore the key items that should be addressed by a well-thought-out migration plan.

Scope

This covers what has been agreed to migrate. It may sound obvious, but if you’re managing a complex migration or one with lots of systems in scope, documenting what’s moving is critical to managing changes.

Discovery

This should capture information about each system to be migrated and is clearly linked to the scope. Correctly planning and resourcing discovery with sufficient time for stakeholder input, review and agreement will set the foundation for a successful migration. Cutting corners and under-resourcing this step may lead to greater risks having to be accepted or significant effort required to fill in gaps closer to deployment. Key things to be discovered are:

- Current specifications – what does this system contain, including infrastructure and applications?

- Target specifications – what does this system need in the destination and are any of the current specifications being changed?

- Security – This needs to be a key consideration when understanding the current environment and future requirements of the organisations.

- Dependencies – what does this system talk to and what are the impacts of moving systems that talk to each other?

- Compatibility – linked to the specifications and dependencies - do any of the systems include components not supported in the target environment? Particularly key here is considering your licensing landscape. You may think licensing is portable, but it can come with caveats and royalties to pay. It’s important not to make assumptions and make sure it’s part of your due diligence.

- Benchmarking – subject to the criticality of the system being migrated, it is imperative to understand performance before and after you migrate so that you can measure the results of the migration. This may require a proof of concept in the target environment.

- Requirements for high availability often utilise multi-region capability - clear consideration should be given at the outset of your project to any regulatory obligations or restrictions you may have to adhere to as this will heavily influence your DR strategy and configuration.

This might seem time-consuming, but it is crucial in understanding the scale of work required and how complex it may be. It’s important to be honest with yourself regarding how much knowledge of your own estate is documented and held within the business.

Migration strategy

Nonetheless, for each system in scope, the migration strategy, e.g. rehost or refactor, should be determined, including the justification for doing so. This flows out of the discovery based on dependencies, specification, and compatibility. You may have completed this in advance or as part of discovery, including as part of establishing a business case. But at this point, you are looking to finalise the actual approach vs an earlier indication during a business case.

Stakeholders

For each system, and the migration as a whole, it is crucial to document system owners and parties responsible for key activities such as testing as well as having the appropriate flows for scenarios such as escalations. It cannot be assumed that there is a nicely maintained list of system owners somewhere – quite often this isn’t entirely true and is a significant source of delays, added risk and cost.

Migration tooling

Flowing out of the Discovery, you should identify, together with impact, any tooling required for the migration. The expertise and experience of the consultants you use will ultimately be the main tool deployed. The impact should cover the costs and/or expertise required to use said tooling.

Maintenance windows

For each system, you should define the maintenance windows during which migration activities can occur. Weekends give the biggest opportunity for migration, testing, and roll back windows, but there needs to be some ‘real’ user testing factored in to minimise the impact of foreseen issues emerging on Monday morning. This is key to the communications plan as well.

Migration activities

For the migration as a whole, as well as of each system, granular activities, owners, estimated timings together with a tracker of expected and actual behaviour of the activity should be captured, including:

- Pre-requisites – what to do before you migrate, e.g. inform users or install any necessary tooling.

- Deployment – what to deploy as part of the migration.

- Functional and non-functional testing – to ensure the systems work as expected.

- Acceptance criteria – to sign off the migration.

- Cutover plan – to execute the migration.

- Rollback procedure – in case the migration does not go as planned.

Change of processes

It’s likely that the operations and processes for your current systems will have to change due to the different way that cloud works. This will require your support teams to be adaptive to change.

It is critical that this is planned for ahead of the migration, with attention paid to areas such as:

- Permissions/identity and access management to maintain the target solution.

- Identifying who is responsible for maintaining the target solution, including their skill level as well as ensuring the correct escalation processes are established.

- Reviewing any updates in associated systems and processes such as backup, monitoring and patching to ensure they support the target solution.

Communications

This is one of the most critical items in the plan and extends across a few layers:

- It’s crucial to identify and build effective communications with all stakeholders impacted by the migration, including end users who will be required to test things post-migration and contribute to benefits realisation.

- Establishing an approval and escalation plan is important to ensure decisions are signed off and understood by the right stakeholders in the organisation.

- Reporting is vital to ensure the right stakeholder receives valuable and concise information at appropriate intervals.

Budget

This is often identified as a pre-requisite to planning itself, but this should then be tracked through the lifecycle of the migration plan. The communications plan should be used to report on the utilisation of the budget together with any deviations in scope to ensure all stakeholders are aware of associated impacts.

Project costs can be a bigger variable with cloud migrations compared to more traditional infrastructure changes. A flexible outlook is required, as costs can be much lower than forecasted in some areas and higher in others. The variance and scalability of costs in the cloud are a big advantage to your organisation, but it does require expectations to be set with stakeholders who need to understand the differences compared to a more traditional on-premises environment.

Risks, Assumptions, Issues, Dependencies (RAID) and Change plan

Tracking these items is critical to the success or failure of the project. They are the lifeblood of the plan and help you track deviations and factors which impact the ability to execute the migration. Managing the impact of these items will ensure all stakeholders have a thorough understanding of the project’s potential path, including changes such as the commercial impact from last-minute deviations in scope.

Realising the benefits

It’s important to understand the goal of the migration and how you will measure its success. This is linked to earlier benchmarking and communications activities, and will align with your organisation’s unique business goals.  Understanding your goals at the outset will provide a clear measure of success and help communicate this to the organisation. A comprehensive business case at the outset with expected cloud spend should provide a point of comparison post-migration.

Ensuring a successful migration

Adopting the age-old cliché of ‘fail to prepare then prepare to fail’ is the ethos that we believe dictates any successful migration. In our experience, having a team dedicated to planning and governing the migration is the most important aspect and offers the greatest route to success.  Your vendors, e.g. cloud providers, will provide lots of guidance on where and why to use their technology, but you are responsible for the successful execution of the migration to their technology. Even in a scenario where you work with your vendor’s technical teams or a managed service partner, these relationships typically only go so far, e.g. they probably won’t manage end-user communications and impact management from the migration, which means it’s vital that you take responsibility, ensuring a successful migration.

If you need any support with any of the topics mentioned, please get in touch to find out more info at cloudsales@softcat.com