According to IDG’s 2022 Cloud computing study, 69% of organisations have accelerated cloud migration over the next year, and the percentage of businesses with the majority of their IT infrastructure in the cloud is expected to jump from 41% to 64% over the next 18 months. Clearly, businesses recognise the value of the cloud in reducing IT costs, enabling better scalability and improving security.
But cloud migration presents companies with a lot of challenges like downtime, large project scope and securing necessary data. If teams get these wrong the costs and capacity crunch can easily mount up. A recent McKinsey report forecast that businesses stand to waste $100 billion of their cloud migration spend in the next three years.
So how can businesses sustainably navigate this? A successful migration follows through on a well-considered and supported plan. Let's break down the 3 key stages of planning a cloud migration:
1. Deciding what you want to achieve
As mentioned, most businesses are in the cloud or moving towards it, but that doesn’t mean they run everything in the cloud. Requirements can change, as can the choice of cloud provider. The majority of businesses still use on-premise and collocated data centres, and more and more infrastructure strategies are relying on a mix of on-premise, colocation, cloud and edge delivery options.
Despite this, Mckinsey claims that by 2024, most enterprises aspire to have $8 out of every $10 for IT hosting go toward the cloud, so naturally, cloud migrations will continue to be a key goal for the foreseeable future. The cloud is no silver bullet however, it can do a lot for your business but it can’t do everything, nor should it. Just as when you’re looking at integrating any new tech, it's vital you set clear goals and identify the business value you are targeting from it.
When planning your cloud migration, make sure you establish KPIs to help you understand and measure exactly what a successful migration will look like. This clarity will help you get crucial buy-in from your organisation’s leadership, as well as help you determine the scope of the project.
2. Scoping out the migration
Once you have clear objectives and goals, you can begin to build your parameters for the project. First cover the more basic project details: decide on a kick-off date, determine and inform those who will be involved, and agree on how the project will be managed. Once you have these covered, bear in mind your objectives and begin to look at what you will need to migrate.
Perform a thorough evaluation of your applications and try to determine and focus on where value can be unlocked by moving operations to the cloud (or to a different cloud). Typically, good plays for the public cloud are public-facing applications with a global reach and variable load, while other applications might be too difficult, risky or simply not worthwhile to migrate. It's important to make these decisions now, and get them right — meticulously decide on what has value for migration and what doesn’t.
Scoping is a key stage and can make or break your project. An incomplete or inaccurate appraisal of the workloads to be migrated can mean your planned requirements are inaccurate and result in possible downstream scope creep. And if you fail to identify and flag key interdependencies between migrating systems you may create bottlenecks, so try to map out all dependencies between systems to avoid this and potential network performance issues.
Before moving to the next stage it's also useful to conduct an audit of the skills and knowledge of your migration team. Assess the level of expertise you can draw from, and try to identify any gaps early. If you do identify skills gaps that will affect the migration, you can either quickly upskill your team or bring in an external migration consultant to help plug the gap and advise on the overall strategy.
3. Identifying and refining your approach
Once you’ve set your goals, defined the scope of your migration project and assessed the level of expertise you can draw from, you can begin truly defining your approach. A big factor in this will be the level of expertise you outlined in the previous stage. If you have a shortage of expertise you may be restricted to just rehosting. Also known as ‘lift-and-shift’ this involves simply moving applications wholesale and unchanged from one environment to another.
More complex migration methods include refactoring, replatforming and rebuilding. The refactoring process involves modifying applications to fit the cloud, while replatforming is a medium between refactoring and rehosting, making some changes to applications to take better advantage of the cloud. Finally, rebuilding involves rewriting the application from scratch. If you are working with a cloud partner they will be able to advise on the best approach that fits your specific needs, goals and infrastructure.
Either way, once you have defined your approach you can begin to budget for cost, choose an appropriate cloud environment and finally pick a cloud vendor that suits your needs — again, an impartial migration partner can be valuable at this stage. Once you’ve established this, it's time to refine and customise your plan further.
Start with a checklist of what needs to be in place before migration can commence, for example, having the cloud architecture validated and ready for migration. Next, create a roadmap of the migration steps, from informing your user base about the plans to establishing contingencies such as rollbacks and disaster recovery. You and your team must be clear and aligned on the order in which various elements will migrate and go live, keeping in mind interdependencies between applications.
Time to migrate
With a thorough plan in place, you can be confident in beginning your cloud migration journey. Final considerations include testing your migration process well in advance, as well as a thorough trial of your go-live. Once your new cloud is live, make sure you test the new environment thoroughly, ensuring the performance and workload functionality match your needs.