How to Build a Cloud Migration Strategy That Works

By Andrew

One after another, companies are moving to the cloud and yet continue to pay for capacity that they never actually use. According to Flexera’s 2026 State of the Cloud survey of over 750 cloud decision-makers, 29% of spending on infrastructure and platform is wasted, which marks the first rise after five years of decrease, and 85% of the respondents identify controlling cloud expenditure as a major issue. That waste is seldom due to problems with the cloud; it is actually a planning problem that begins before the very first server is moved.

A cloud migration strategy is a way of avoiding problems. This guide covers the different migration methods, how to evaluate your environment, how to create a step-by-step roadmap, which risks you should anticipate, how to decide between a public, private or hybrid cloud, and what steps must be taken after going live for the move to be successful.

What Does Cloud Migration Consist Of and Why Is It Important?

Cloud migration refers to the process of transferring data, applications and IT workloads from on-premises infrastructure to a cloud environment, or from one cloud environment to another. The destination may be a public cloud such as AWS, Azure or Google Cloud, a private cloud, or a combination of both.

There are three reasons why businesses choose to migrate. For scalability, capacity is aligned with demand rather than having it purchased years ahead to meet peak periods. Regarding speed, a new environment can be set up in minutes rather than waiting for a procurement process. As for the cost structure, large capital purchases are replaced by usage-based operating costs, which only become beneficial when usage is actively managed.

It is difficult to overstate the extent of this change. Gartner has forecast that worldwide end-user spending on public cloud services will reach $723.4 billion in 2025, representing an increase of 21.5% on the $595.7 billion spent in 2024, and predicts that through 2027 ninety per cent of organizations will have adopted a hybrid cloud approach. A cloud migration strategy is the plan that determines which systems will be moved, how they will be moved, the order in which they will be moved and how success will be measured; without such a strategy the cloud tends to carry over all the inefficiencies of the old data centre and also produces a monthly bill.

What Are the Principal Types of Cloud Migration Approaches?

The approach of migration is generally described in terms of the “Rs”. The original model mentioned six; AWS’s present guidance lists seven migration strategies, including Relocate.

• Rehost: move the application unchanged (“lift and shift”).
• Relocate: move entire virtualized platforms to the cloud version of the same platform, without altering the servers.
• Replatform: make targeted optimizations, for example by switching to a managed database (“lift, tinker and shift”).
• Refactor: redesign the application so that it makes use of cloud-native services.
• Repurchase: replace the application with a SaaS product.
• Retire: turn off things that are unnecessary.
• Retain: keep the workload where it is for the moment.

Actual migrations mix them, selecting a different R for each workload. Retire is usually the most cost-effective option: AWS recommends looking for “zombie” applications that use an average of less than 5% of CPU and memory, and these can simply be switched off rather than being migrated.

Rehost (Lift and Shift)

Rehosting involves getting workloads running on the cloud without making any changes to the application. It is the quickest method and poses the lowest technical risk, so it is suitable for stable legacy systems that are running on older hardware, in cases where there are strict deadlines such as a forthcoming data centre lease expiry, and can be used as an initial step if you intend to carry out optimisation later on. AWS itself suggests that rehosting or replatforming should be done during large migrations and that modernisation should then take place.

The disadvantage is that you end up with the existing inefficiencies. A server designed to handle a peak that occurs twice a year will be charged as if that peak occurs every hour.

Replatform and Refactor

By replatforming it is possible to make targeted improvements without having to rewrite the application (for example, by moving a self-managed SQL Server to a managed database service or by packaging a virtual machine as a container), and generally the best return is obtained for the effort involved.

Refactoring involves re-architecting the application for the cloud, typically resulting in independently scalable services. It is the most costly and slowest approach and is the one that brings the greatest long-term benefits in terms of resilience, scalability and cost. It is appropriate in cases where the application is business-critical, is going to be used for many years, and is already hindering the business, for instance when it is a monolith that no one can safely modify or when the application has very little test coverage. Refactoring is as much a software development project as a migration and should therefore be planned and tested in the same way.

As a practical guideline, rehost should be done in order to make progress, replatform when it leads to easy successes, and only refactor if the business value justifies the investment.

How Do You Evaluate Your IT Environment Prior to Migrating?

A migration assessment eliminates many of the surprises that cause cloud projects to fail. Carry it out in the following order:

• Inventory: every application, server, database, integration, license, and the name of the owner; shadow IT is included.
• Dependency mapping: which systems communicate with one another, the ports they use and how frequently they do so. An application that reads from a shared database cannot be moved on its own without a plan for the latency the move introduces.
• Performance baseline: CPU, memory, storage, I/O and latency under both normal and peak loads since, without such a baseline, you cannot demonstrate that the cloud performs as well and you also cannot size the instances correctly.
• Security posture: patch levels, access privileges, encryption, and any known vulnerabilities; moving a weakness just puts it in a more exposed location.
• Compliance requirements: the kind of regulated data that you hold and the places where it is permitted to reside.

What Role Does a Compliance Audit Play Before a Migration to the Cloud?

A compliance audit can detect flaws in data governance, access control and regulatory readiness prior to data being moved, since at that stage it is most economical to make the necessary corrections. It addresses four questions: what personal or regulated data is held, where it is stored, who has access to it, and for how long it is kept.

When it comes to the personal data of individuals in the EU, the choice of provider and the selection of region are affected by the rules of the GDPR, which limits the transfer of personal data outside the EU and the EEA unless appropriate safeguards are established, for example through an adequacy decision or the use of standard contractual clauses. In the case of the United States, the European Commission adopted the EU-US Data Privacy Framework adequacy decision on 10 July 2023, covering data transfers to US companies that are part of the framework. The decision to select a cloud region, to check a provider’s sub-processors, and to review its data processing agreement are therefore compliance-related decisions, not merely technical ones. As we have previously pointed out, your infrastructure choice is now a governance decision, and the location where workloads are run has become a matter that concerns both the board and IT. A compliance audit prior to migration turns these questions into formally recorded positions; if EU personal data is involved, our GDPR compliance team can help document them.

How to Build a Cloud Migration Roadmap

A roadmap divides that one risky “big bang” into a series of small, verifiable steps, and most successful migrations follow five phases.

• Discovery: the assessment mentioned above together with definite business objectives; the aims of “leaving the data centre by March” and “reducing infrastructure costs by 20 per cent” result in different plans.
• Planning: select an R for each workload, choose the cloud model and provider, design the target architecture, and establish security, identity and cost governance.
• Pilot: migrate one or two low-risk workloads end to end in order to test the process, the tooling and your estimates.
• Migration waves: move workloads in groups, each of which includes testing, a cutover window, and a rollback plan.
• Optimization: rightsize, tune and secure what is now running in the cloud.

You should prioritize based on three factors: business criticality, technical complexity and dependencies. Begin with those workloads that score low on all three (for example, test environments, internal tools and standalone applications) and delay dealing with closely coupled, critical systems until the team has established a proven process. The dependency chains determine how the systems are grouped: systems that constantly communicate with each other should be included in the same wave.

Setting Migration Milestones and KPIs

Define success in numbers before you start, so the decision to continue, pause or roll back is based on evidence:

• Availability: the highest acceptable amount of downtime during a cutover and the uptime targets after going live.
• Performance: latency and response times as compared to the pre-migration baseline.
• Cost: the cost per workload, forecast versus actual, with a variance threshold that initiates a review.
• Milestones: the pilot phase completed, each wave completed, and the legacy hardware decommissioned.

The KPIs should not be abandoned at the end of the project; instead, the same targets will form the basis for the continued oversight of managed IT services after the migration, the numbers which showed that the move had been successful being the ones that ensure its continued success.

What Are the Main Risks Involved in Moving to the Cloud and How Can They Be Avoided?

The usual risks are well known (data being lost or corrupted during transmission, downtime that exceeds planned amounts, incorrect storage configurations or excessive permissions, cost overruns, and legacy applications acting differently on the new infrastructure), and they can also be managed:

• Rollback plans: for each wave, plan and practice the procedure for reverting to the prior state.
• Phased cutover: carry out the deployment in waves and operate the older and newer environments simultaneously.
• Data validation: check the record counts and the checksums after the transfer, not merely rely on the fact that the copy job had reported success.
• Continuous monitoring: compare the current behaviour with the baseline and issue an alert when there is a deviation.
• Cost controls from day one: set up budgets, alerts, and resource tagging before the first workload is deployed.

Testing should have its own entry in the plan; a migrated application must pass the same functional and performance tests as it did before the move, and load testing should match actual traffic rather than an optimistic one. Our article on why load test numbers lie outlines the most common errors.

What’s the Role of Data Security in Cloud Migration?

Security must be incorporated into the migration from the beginning rather than being added at a later stage. The three areas that are most important are:

• Encryption: the data is encrypted while it is being transferred during the move and when it is stored in the cloud, with the keys being deliberately managed and rotated.
• Identity and access management (IAM): least-privilege roles should be implemented, multi-factor authentication should be used, and there should be no shared administrator accounts. It is easy to give cloud permissions broadly but difficult to audit them later.
• Zero trust: no user, device or network is trusted by default and all requests must be authenticated and authorized; NIST SP 800-207 outlines the architecture and serves as a practical reference.

The shared responsibility model should be remembered in that it is the provider’s role to secure the underlying infrastructure, but it is up to you to manage the configuration, the identities and the data. Structures for the controls on your side of that line are available through ISO/IEC 27001, the NIST Cybersecurity Framework and the CIS Benchmarks.

Should You Move to a Public Cloud, a Private Cloud, or a Hybrid Cloud?

Public clouds are best suited to ordinary business workloads, those with varying demand and teams who want to gain speed without having to manage hardware. Private clouds are appropriate when there are strict regulatory or data-sovereignty requirements, special performance needs, or steady and predictable workloads. A hybrid cloud is suitable for organizations that have sensitive data or are still using legacy systems and therefore need to keep things under close control, while at the same time wanting the capacity of the public cloud for all the other areas, which is the reason why Gartner expects nine out of ten organizations to end up choosing this option.

You should make your decision taking into account industry practices, the sensitivity of the data, the existing infrastructure and the skills of your team; you should also consider the cost of exit, since exit fees and proprietary services can make it expensive to leave a provider, a factor that we examined in the renewal that costs 37% more for the same seats.

How Can Managed IT Services Assist You with Your Cloud Migration?

A provider offering managed IT services takes care of all the stages: during the planning phase those involving assessment, dependency mapping, architecture and cost modelling; during the execution phase the tasks relating to tooling, testing and co-ordinating the cutover; and after go-live the responsibilities of monitoring, patching, backup, security and cost optimisation.

The ability of a skilled team lies in its capacity for pattern recognition. A provider which has carried out migrations in the past knows in advance the points at which problems occur: for example, the forgotten batch job which was running on an old server, the licence that doesn’t transfer, and the integration that times out when the latency doubles. When we migrated a multinational client’s production infrastructure to Rackspace, the most difficult aspects were precisely these: a number of linked, heavily loaded Oracle databases amounting to several hundred gigabytes that could not be taken offline for any length of time, and a collection of Windows Server 2003 machines which the new platform did not officially support.

There is also a structural benefit to a provider who takes overall responsibility, covering the entire process from software development via quality assurance to continuous support. In the case where the same partner is in charge of refactoring an application, testing it, migrating it and then running it in production, no information is lost between different vendors and there is a single team that can be held accountable for the outcome.

What Takes Place After the Cloud Migration Has Been Completed?

The go-live mark is when operations begin, not when the project ends. After migration, the work falls into four areas: monitoring performance in line with the KPIs that were set out, carrying out cost optimisation, conducting scheduled security audits of the configurations and permissions, and providing training so that internal staff will be able to operate and secure the new environment. Migration should be regarded as a continuous process since prices, services, workloads and threats are all in a state of constant change, and an environment that is not the responsibility of anyone eventually slips back to the 29% waste level.

Optimizing Cloud Performance Over Time

Three practices do most of the work:

• Autoscaling: capacity that adjusts automatically in response to demand, so that you don’t have to pay for the peak levels all the time.
• Commitment planning: reserved instances or savings plans for the predictable baseline, and on-demand pricing for everything else.
• Rightsizing: regularly matching instance sizes to measured use.

Quality assurance should also be included in this case. Backups and failover arrangements should be tested on a regular schedule, each change must go through testing and receive approval, and service performance should be checked against the SLA targets. Outages in the cloud are frequently the result of changes which appeared to be safe, as was shown by Microsoft’s own Azure incident. It is the quality assurance procedures that maintain a high level of reliability after the migration team has left.

A migration succeeding is more a matter of the decisions taken beforehand and of the discipline maintained afterwards than of the move itself. Should you decide to carry out one, our managed services team can look after it from the assessment stage through to the point where the cloud environment starts earning back its cost.

Frequently Asked Questions

What counts as a cloud migration strategy and why do I need one?

A cloud migration strategy is a written plan which specifies the workloads that will be moved to the cloud, the method each one will employ, the order in which they will be migrated, the cost involved and the way in which success will be measured. Such a plan is necessary since unplanned migrations usually result in budget overruns, lead to unnecessary downtime and transfer the old inefficiencies and security vulnerabilities into the new environment.

How long does an average cloud migration project take?

The time required will vary depending on the size and complexity of the environment; a small business having only a few standard workloads can carry out the migration within a few weeks to a couple of months, whereas a large organization with a number of interdependent systems or with applications that need to be refactored may take a year or longer. The most reliable estimate for your own situation can be obtained from a pilot migration involving one or two workloads.

What is the difference between public cloud and private cloud for business use?

Public cloud runs on shared infrastructure operated by a provider such as AWS, Azure or Google Cloud, with pay-as-you-go pricing and fast scaling. Private cloud is dedicated to a single organization, which gives more control and easier customization for strict compliance needs, at a higher fixed cost. Many businesses combine the two in a hybrid model.

How does GDPR affect where I can store data in the cloud?

GDPR restricts transfers of EU residents’ personal data outside the EU and EEA unless appropriate safeguards exist, such as an adequacy decision or standard contractual clauses. In practice this means choosing cloud regions deliberately, checking where a provider and its sub-processors process data, and documenting the legal basis for any transfer. For transfers to the US, the EU-US Data Privacy Framework applies to companies certified under it.

What should I look for in a managed IT services provider for cloud migration?

Look for proven migration experience you can verify, a documented methodology with rollback plans, security and compliance credentials, transparent SLAs, and the capacity to support the environment after go-live. A provider that also offers software development and quality assurance can handle refactoring and testing within the same engagement, which reduces handoffs and risk.

Can I migrate legacy software systems to the cloud without rewriting them?

Often, yes. Rehosting moves many legacy applications to cloud infrastructure with no code changes, and replatforming adds limited improvements such as a managed database. Systems tied to specialized hardware, mainframes or unsupported operating systems may need modernization first, and a pre-migration assessment will show which applications fall into that group.

How do I calculate the total cost of cloud migration?

Add the one-time costs (assessment, migration labor, tooling, testing, training and any refactoring) to the ongoing costs (compute, storage, data transfer and egress, licences, monitoring and support). Compare the total with the full cost of your current environment, including hardware refresh, power, space and staff time. Add a contingency, and track actual spend against forecast every month after go-live.