How to Build a Cloud Migration Strategy That Works

One company after another has moved to the cloud, yet they are still paying for capacity that they in fact never use. According to the Flexera 2026 State of the Cloud survey of more than 750 cloud decision-makers, 29% of spending on infrastructure and platform is wasted, this mark being the first rise after five years of decline, and 85% of the respondents regard controlling cloud expenditure as a major issue. That waste is seldom due to problems with the cloud; it is actually a planning problem which begins before the very first server is moved.

It is possible to avoid problems by having a cloud migration strategy. The guide provides details about the different migration methods, how to evaluate your environment, how to prepare a step-by-step plan, what risks you should anticipate, how to decide between using a public cloud, a private cloud or a hybrid cloud, and what steps need to be carried out after going live if the move is to be a success.

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. This can involve a move to a public cloud such as AWS, Azure or Google Cloud, or to a private cloud, or a combination of both.

Companies choose to migrate for three reasons. When it comes to scalability, capacity is scaled to meet demand rather than purchasing it in advance to deal with the peak periods. Regarding speed, a new environment can now be prepared in just a few minutes rather than having to wait for the procurement process. As for the cost structure, large capital purchases are replaced by usage-based operating costs, even though it is only when usage is actively managed that these costs become advantageous.

It’s hard to emphasize how great this change is. Gartner has predicted that global end-user spending on public cloud services will amount to $723.4 billion in 2025, which is a 21.5% increase on the $595.7 billion spent in 2024, and it also forecasts that by 2027 ninety per cent of organizations will have taken on a hybrid cloud approach. A cloud migration strategy is the one which specifies which systems will be moved, how they will be moved, the order in which they will be moved and how success will be assessed; otherwise the cloud ends up retaining all the inefficiencies of the old data centre and also results in a monthly bill.

What Are the Principal Types of Cloud Migration Approaches?

The migration approach is usually explained using the “Rs”. While the original model referred to six, AWS’s current guidance gives seven migration strategies, one of which is Relocate.

• Rehost: move the application without making any changes to it (“lift and shift”).
• Relocate: move the entire virtualized platforms to the cloud version of the same platform, making no changes to the servers.
• Replatform: carry out targeted optimisations, for instance by moving 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: switch off those items that are not necessary.
• Retain: keep the workload where it is for the moment.

Real migrations combine them, choosing a different R for each kind of workload. Retire is generally the most cost-effective solution: AWS suggests identifying ‘zombie’ applications that use an average of less than 5% of both CPU and memory, and in such cases it is enough simply to switch them off rather than migrating them.

Rehost (Lift and Shift)

Rehosting means getting applications running on the cloud without having to make 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 currently operating on older hardware, in situations where there are strict deadlines such as an upcoming expiry of a data centre lease, and it can be used as a first step if you plan to carry out optimisation at a later stage. AWS recommends that rehosting or replatforming should be carried out during major migrations and that modernisation can then be done.

The problem is that you end up with the current inefficiencies, since a server which is designed to cope with a peak that happens twice a year will be charged as if that peak occurs every hour.

Replatform and Refactor

It is possible to achieve targeted improvements by replatforming without the need to rewrite the application (for instance, by moving from a self-managed SQL Server to a managed database service or by packaging a virtual machine as a container), and generally the best return on investment is obtained.

Refactoring means redesigning the application for use in the cloud and generally leads to services that can be scaled independently. It is the most expensive and the slowest method and is the one that offers the greatest long-term advantages regarding resilience, scalability and cost. It should be used in situations where the application is business-critical, is going to be used over a long period of time, and is already having a negative impact on the business, for example if it is a monolith that no one can safely change or if the application has very limited test coverage. Since refactoring is just as much a software development project as it is a migration, it must be planned and tested in the same manner.

As a practical guideline, rehosting should be carried out in order to make progress, replatforming should be done when this results in easy successes, and refactoring should only take place if the business value proves to justify the investment.

How Do You Evaluate Your IT Environment Prior to Migrating?

A migration assessment removes a great many of the surprises which lead to cloud projects failing. Perform it in the order listed below:

• Inventory: every application, server, database, integration, license, and the name of the owner; shadow IT is to be included as well.
• Dependency mapping: which systems communicate with each other, the ports they use, and how often they communicate. An application that reads from a shared database cannot be moved alone unless there is a plan addressing the latency that the move will introduce.
• Performance baseline: CPU, memory, storage, I/O and latency under both normal and peak loads since, without this baseline, you would not be able to show that the cloud performs as well and you also could not size the instances correctly.
• Security posture: the patch levels, the access privileges, the encryption measures, and any known vulnerabilities; if you move a weakness it only ends up in a more exposed position.
• Compliance requirements: the type of regulated data that you hold and the locations where it is allowed to stay.

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

A compliance audit can pick up any flaws in data governance, access control and regulatory readiness before the data is moved, since at that stage it is most cost-effective to make the necessary corrections. It answers four questions: which personal or regulated data is held, where it is stored, who has access to it, and for how long it is kept.

With regard to the personal data of individuals in the EU, the provider chosen and the region selected are influenced by the rules of the GDPR, since personal data cannot be transferred outside the EU and the EEA unless appropriate safeguards are in place, for instance by means of an adequacy decision or through the use of standard contractual clauses. In the case of the United States, the European Commission adopted the adequacy decision on the EU-US Data Privacy Framework on 10 July 2023, thereby covering data transfers to US companies that are part of the framework. The decisions to select a cloud region, to check a provider’s sub-processors, and to review its data processing agreement are therefore compliance-related and not just technical decisions. As we have already mentioned, your choice of infrastructure is now a governance issue and the location where workloads are processed has become a matter that involves both the board and IT. A compliance audit before migration turns these questions into formally recorded positions; if EU personal data is in question, our GDPR compliance team can assist in documenting them.

How to Build a Cloud Migration Roadmap

A roadmap breaks down that single risky ‘big bang’ stage into a number of small and verifiable steps, and the majority of successful migrations adhere to five phases.

• Discovery: the assessment referred to above, in conjunction with specific business objectives; “leaving the data centre by March” and “reducing infrastructure costs by 20 per cent” lead to different plans.
• Planning: an R should be selected for each workload, the cloud model and provider should be chosen, the target architecture should be designed, and security, identity and cost governance should be set up.
• Pilot: migrate one or two low-risk workloads end to end in order to test the process, the tooling and the estimates.
• Migration waves: move workloads in batches, each batch including a testing phase, a cutover period, and a rollback plan.
• Optimization: right-size, tune and secure all that is currently running in the cloud.

You should decide on priority taking into account three factors: business criticality, technical complexity and dependencies. Start with the workloads that have a low score in all three areas (such as test environments, internal tools and standalone applications) and postpone action on those closely coupled, critical systems until the team has developed a proven process. The dependency chains decide how the systems are grouped since those systems which constantly communicate with one another should be placed in the same wave.

Setting Migration Milestones and KPIs

Before you begin, define what success means in quantitative terms so that your decision to continue, suspend or revert the project is based on evidence.

• Availability: the maximum level of downtime that is considered acceptable during a cutover and the uptime objectives following going live.
• Performance: a comparison of latency and response times with those of the pre-migration baseline.
• Cost: the cost per unit of workload, comparing the forecast with the actual figures, and includes a variance threshold which triggers a review.
• Milestones: the completion of the pilot phase, the completion of each wave, and the decommissioning of the legacy hardware.

The KPIs should not be given up at the end of the project; on the contrary, the same targets are to serve as the basis for the ongoing supervision of the managed IT services afterwards, the figures which had shown the move to have been a success being the ones that guarantee its continued success.

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

The standard risks are well known—for example, data being lost or damaged during transmission, downtime that goes beyond the planned amount, incorrect storage configurations or excessive permissions, cost overruns, and legacy applications behaving differently on the new infrastructure—and these risks too can be dealt with:

• Rollback plans: for each wave it is necessary to plan and practice the procedure for rolling back to the previous state.
• Phased cutover: carry out the deployment in waves and run the older and newer environments at the same time.
• Data validation: verify the number of records and the checksums afterwards, not just depend on the fact that the copy job had reported success.
• Continuous monitoring: compare the current behaviour with the baseline and send an alert if there is a deviation.
• Cost controls from day one: establish 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 should be included from the very start of the migration and not be added at a later stage. The three most important areas are:

• Encryption: the data is encrypted both during its transfer as it is being moved and when it is stored in the cloud, the keys being intentionally 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 have to be authenticated and authorised; NIST SP 800-207 provides a description of the architecture and acts as a practical reference.

Keep the shared responsibility model in mind: it is the provider’s duty to secure the underlying infrastructure, but you are responsible for managing the configuration, the identities and the data; the frameworks relating to the controls on your side of that line are provided by 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 most suitable for typical business workloads—those with fluctuating demand and for teams who wish to speed things up without having to manage hardware themselves. Private clouds should be used when there are strict regulatory or data-sovereignty requirements, particular performance needs, or when dealing with steady and predictable workloads. A hybrid cloud is appropriate for companies that have sensitive data or are still using older systems and therefore need to keep a close watch on their operations, at the same time taking advantage of the public cloud’s capacity, which is why Gartner expects nine out of ten organisations to end up selecting this option.

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

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

A provider that provides managed IT services looks after all the various stages: in the planning phase those which include assessment, dependency mapping, architecture and cost modelling; in the execution phase the tasks concerning tooling, testing and co-ordinating the cutover; and after go-live it carries out the duties of monitoring, patching, backup, security and cost optimisation.

The reason why an experienced team is so effective is due to its ability to recognise patterns. A provider that has done migrations before will know in advance at what stages problems are likely to arise—for instance, because of a batch job that had been forgotten and was running on an old server, because of a licence that doesn’t transfer, and because of an integration that times out when the latency is doubled. When we carried out the migration of a multinational client’s production infrastructure to Rackspace, it was exactly these features that proved most difficult: a number of closely linked, heavily loaded Oracle databases totalling several hundred gigabytes that could not be taken offline for any length of time, and a group of Windows Server 2003 machines which the new platform did not officially support.

There is also a structural advantage for a provider who takes full responsibility, carrying out the whole process from software development through to quality assurance and continuous support. When 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 one team that can be made accountable for the result.

What Takes Place After the Cloud Migration Has Been Completed?

The go-live point is when operations start, not when the project finishes. Once the migration has been carried out, the subsequent work is divided into four areas: monitoring performance in accordance with the KPIs that were established, carrying out cost optimisation, conducting periodic security audits of the configurations and permissions, and providing training so that internal staff can operate and secure the new environment. Migration should be seen as an ongoing process because prices, services, workloads and threats are all constantly changing, and if no one takes responsibility for an environment it will eventually return 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 that outlines the workloads which are to be moved to the cloud, the method that each will use, the order in which they will be migrated, the cost involved and the method by which success will be assessed. It is necessary to have such a plan because unplanned migrations generally cause budget overruns, result in unnecessary downtime and carry the old inefficiencies and security vulnerabilities over into the new environment.

How long does an average cloud migration project take?

The length of time needed will depend on the extent and complexity of the environment; in the case of a small business with only a few standard workloads the migration can be completed in a few weeks or a couple of months, while a large organization having a number of interdependent systems or possessing applications that need refactoring might take a year or more. The most accurate estimate for your particular situation can be arrived at by carrying out a pilot migration with one or two workloads.

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

A public cloud uses shared infrastructure managed by a provider like AWS, Azure or Google Cloud and offers a pay-as-you-go pricing scheme with quick scaling capabilities. A private cloud, on the other hand, is used exclusively by one organization and therefore provides greater control as well as easier customization when strict compliance requirements must be met, although it does so at a higher fixed cost. Many businesses choose to combine both of these approaches by using a hybrid model.

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

Personal data of EU residents is restricted from being transferred outside the EU and EEA unless adequate safeguards are in place, for example through an adequacy decision or the use of standard contractual clauses. In practice this involves deliberately selecting cloud regions, finding out where a data provider and its sub-processors carry out data processing, and recording the legal basis for any transfer. When it comes to transfers to the United States, the EU-US Data Privacy Framework applies to companies that have been certified under it.

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

Search for a provider who has verifiable migration experience, along with a documented methodology that includes rollback plans, security and compliance certifications, clear SLAs, and the ability to continue supporting the environment after go-live. If the provider also provides software development and quality assurance services, it will be able to carry out refactoring and testing as part of the same engagement, thus reducing the number of handoffs and associated risk.

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

That is often the case. When applications are rehosted they are moved to a cloud environment without any changes to the code, and when replatforming is carried out only limited improvements are gained, for example through the use of a managed database. Applications which are dependent on specialised hardware, mainframes or on operating systems that are no longer supported may have to be modernised first, and an assessment carried out before migration will indicate which applications belong to that category.

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.