What Is Cloud Migration and How It Actually Works

Cloud migration is the process of moving applications, data, and IT workloads from on-premises infrastructure to cloud environments, or between clouds. It is a staged engineering project, not a one-time transfer, and every workload in the portfolio needs its own decision about what moves, how, and when.

The situation is familiar. An aging data center is consuming attention, hardware leases are expiring, and the board wants a credible answer on cloud costs. Meanwhile, application owners warn that the systems everyone wants to move are tied to undocumented databases, fragile network rules, and batch jobs that nobody wants to interrupt.

That's why the useful question isn't just whether your company should move to the cloud. It's what should move, by which route, in what sequence, and with which people responsible for proving that the result works.

What does cloud migration mean in plain terms?

Cloud migration means moving applications, data, and other IT workloads from infrastructure you operate yourself into a cloud environment, or moving them from one cloud provider to another. For a shorter, business-first introduction, see this Wonderment Apps guide to cloud migration.

Think of it as relocating a business from a building you own into flexible leased space. You no longer maintain the physical building. You still have to decide where each team works, how equipment connects, which records need protection, and how the business stays open during the move. Cloud services can provide scalable infrastructure and managed capabilities, but they don't remove architectural decisions.

Three directions appear repeatedly:

• On-premises to cloud: Applications and data move from a company-owned data center or private infrastructure into a public, private, or hybrid cloud.

• Cloud to cloud: Workloads move between providers, regions, accounts, or service models, often because of capability, compliance, cost, or operating-model requirements.

• Reverse migration (repatriation): Selected workloads move from public cloud back to on-premises infrastructure or another environment when the original placement no longer fits.

The scope can be a single application or database, a mainframe, or a full data-center exit. The work is staged because applications rarely operate alone. Teams discover dependencies, select a migration strategy for each workload, establish performance baselines, replicate data, test recovery, cut over traffic, and then tune the new environment.

A non-technical executive should be able to explain it this way: cloud migration moves business systems and their data into a cloud environment or between clouds. It succeeds when the organization manages the dependencies, risks, people, and operating model around that move.

Why are enterprises investing in cloud migration?

Enterprises fund cloud migration because public cloud spending keeps growing. Gartner forecast worldwide end-user spending on public cloud services at $723.4 billion in 2025, up from $595.7 billion in 2024 (Gartner, November 2024). Workloads have to reach the cloud before anyone can pay to run them there.

Adoption has crossed the experiment stage

The European Union provides a concrete adoption signal. 52.7% of EU enterprises used paid cloud computing services in 2025, a 7.4 percentage point increase compared with 2023 (Eurostat, 2026). Cloud use has crossed a majority threshold in a major regulated market, even though migration methods remain mixed.

That mix matters. Rehosting (lift-and-shift) is among the strategies AWS lists as common for large migrations because it removes deadlines quickly, while refactoring and re-architecting attract investment for the applications that justify deeper change.

The business case is broader than infrastructure

Executives typically approve migration for a combination of reasons:

• Elasticity and cost model: Pay for capacity as it is used and scale without buying hardware. The savings appear only when someone manages usage.

• Modernization: Replace aging platforms and reduce dependence on hardware refresh cycles.

• Security: Use cloud services and controls that may be difficult to build consistently in-house, while retaining responsibility for customer-side configuration.

• Analytics: Make data more accessible to analytics platforms and distributed teams.

• Application replatforming: Move selected components to managed databases, containers, or other services without immediately rewriting everything.

That momentum doesn't mean every workload belongs in the cloud. A market can grow rapidly while individual applications still require hybrid placement, retention, or eventual retirement. The credible business case is therefore portfolio-based: move the workloads where cloud capabilities solve a real constraint, and leave the rest where they remain technically and economically sound.

What are the main cloud migration strategies?

The main cloud migration strategies are rehost, replatform, refactor, repurchase, and rebuild, plus the decisions to retire or retain a workload. AWS formalizes this as the 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect (AWS Prescriptive Guidance). The five strategies below form a spectrum: rehost favors speed, while rebuild favors architectural change. The right answer can differ for every application in the same portfolio.

Rehost

Rehosting, or lift-and-shift, moves an application with minimal changes. It works when the immediate constraint is an expiring data center contract, a hardware deadline, or the need to establish a cloud operating baseline quickly.

The trade-off is obvious. You gain relocation speed, but you may preserve inefficient licensing, tightly coupled architecture, and infrastructure assumptions that don't benefit from elasticity. A stable internal reporting application can be a reasonable rehost candidate when redesign would create more risk than value. A close variant, relocate, moves whole virtualized platforms (for example, VMware environments) to a cloud version of the same platform without changing the servers inside them.

Replatform

Replatforming makes targeted improvements without changing the application's core design. Common examples include moving a self-managed SQL Server database to a managed service such as Amazon RDS, containerizing an existing service, or changing the storage tier while preserving application behavior.

This often offers the most practical middle ground. Teams reduce operational work and gain selected cloud capabilities without taking on a full rewrite. The danger is scope creep. A small platform adjustment can easily become refactoring if nobody controls the boundary.

Refactor

Refactoring, sometimes called re-architecting, changes the application so it can use cloud-native patterns. A monolith might be divided into services, a batch process might be redesigned around event-driven components, or a tightly coupled application might adopt managed queues and scalable data services.

This is the deepest investment and requires strong testing, observability, and product involvement. It fits a customer-facing platform whose growth, release velocity, or resilience requirements justify architectural change. It doesn't fit a stable application whose business value is declining. For large migrations, AWS recommends moving first and modernizing afterward, because refactoring during the move is the most complex strategy to manage at scale.

Repurchase

Repurchasing replaces an existing application with a cloud-based product, usually SaaS. Replacing a custom expense-management system with a suitable SaaS product is a familiar example.

The technical migration may be smaller, but the business change can be substantial. Teams must map data, workflows, integrations, access rules, and user adoption. Repurchase wins when the old application is a commodity and maintaining custom code no longer creates meaningful differentiation.

Rebuild

Rebuilding means creating a new application, usually because the existing system can't meet current business or technical requirements. It can produce a cleaner result than forcing a legacy design into cloud infrastructure, but it carries the highest delivery and product risk.

Two more decisions belong in every portfolio review. Retire applies to systems with no remaining business value, which can simply be shut down. Retain applies to systems that should stay where they are for now, because of data residency, specialized hardware, unresolved dependencies, or a recent upgrade.

The practical portfolio rarely uses one approach exclusively: rehost to remove a constraint, replatform where a modest change pays off, and reserve refactoring or rebuilding for workloads that justify the investment.

What are the phases of a cloud migration?

A cloud migration moves through four phases: discovery, planning, execution, and optimization. Each phase should end at a gate, not a guess. AWS describes the same arc as assess, mobilize, and migrate and modernize (AWS large migration guide), and Microsoft's Cloud Adoption Framework migration guidance follows a similar sequence for Azure. For Microsoft-centered programs, this Azure and Dynamics 365 migration guide from F1Group walks through readiness assessment with Azure Migrate, identity, data protection and recovery planning.

1. 1DiscoverInventory applications, data, integrations and dependencies, and capture performance baselines.
2. 2PlanAssign a strategy to each workload, design the target architecture and group workloads into waves.
3. 3ExecuteReplicate data, rehearse cutover, move traffic in stages and validate before closing each wave.
4. 4OptimizeRight-size resources, tune storage and networking, and decide which workloads to modernize next.

Discovery starts with evidence

Inventory every application, database, integration, scheduled job, and external connection. Capture CPU and RAM utilization, storage behavior, inter-service links, sensitive data paths, authentication dependencies, and operational ownership.

A server list isn't enough. A dependency map should answer questions such as:

• What calls this service: Identify upstream and downstream applications, databases, queues, and APIs.

• Where does sensitive data travel: Mark regulated or confidential data paths before choosing regions, services, and access controls.

• What happens during failure: Record recovery behavior, batch windows, and manual procedures that won't appear in infrastructure diagrams.

Planning turns inventory into waves

Planning assigns a strategy to each workload, defines the target architecture, selects replication and infrastructure-as-code tooling, and establishes rollback conditions. Wave-based sequencing is safer than a big-bang move because teams can learn from a lower-risk workload before touching a business-critical dependency.

Each provider has native tooling for this work. AWS Transform MGN (formerly AWS Application Migration Service) replicates servers continuously for rehosting and groups them into waves. Azure Migrate is a free Microsoft service for discovery, assessment, dependency analysis and migration to Azure. Google Cloud Migration Center covers asset discovery, cost estimates and migration planning for Google Cloud. For how these provider programs compare with outside firms, see this comparison of cloud migration services.

Execution needs controlled validation

Replication, rehearsal, incremental network validation, and staged traffic movement belong in execution. Validate data integrity, authentication, firewall behavior, application responses, monitoring, and rollback before declaring a wave complete.

Practical rule: If a dependency appears for the first time during cutover, the discovery process was incomplete. Treat the finding as a planning defect, not as evidence that the cloud platform failed.

The most common operational surprise is hidden coupling. An application may look independent until a hard-coded hostname, an untracked batch job, or a firewall rule surfaces during the move. Phased cutovers reduce the blast radius and give engineers a controlled place to correct those findings.

Optimization begins after the move

Post-migration work includes right-sizing compute, tuning storage, reviewing network paths, improving observability, and deciding whether a rehosted workload deserves later replatforming or refactoring. Compare behavior against the original baseline rather than assuming the move preserved performance.

For a more detailed engineering checklist, see cloud migration best practices for engineering leaders.

What technical risks matter most in a cloud migration?

The biggest technical risks sit where data, security, and networking meet. Migrations fail technically when teams treat them as separate workstreams. A new storage tier changes performance, a new network path changes latency, and a changed identity boundary affects both application behavior and data access.

Data requires a cutover design

Large datasets need a transfer method that matches their size, change rate, consistency requirements, and downtime tolerance. Bulk transfer can work for a system with a planned maintenance window. Continuous replication, such as change data capture with AWS Database Migration Service or Azure Database Migration Service, is more appropriate when the source must keep accepting writes until a short cutover. Dual-write designs can reduce interruption, but they introduce reconciliation and failure-handling complexity.

Storage IOPS mismatches are a common source of quiet regression. An application that performed well on a local array may behave differently on network-attached block storage, even when compute sizing looks correct. Validate throughput, latency, queue depth, consistency, and backup behavior before production traffic moves.

Security boundaries remain explicit

Cloud providers secure the underlying infrastructure, but the customer's share depends on the services it chooses. On infrastructure services such as Amazon EC2, the customer manages the guest operating system, patches, installed applications, and firewall configuration. On managed services such as Amazon S3, the customer still owns its data, encryption choices, and access permissions (AWS Shared Responsibility Model). Assuming the provider owns everything is a dangerous shortcut. Misreading shared responsibility is one of the common mistakes in this guide to cloud migration mistakes. The fix is to write down who owns data, identity, access, configuration, patching, monitoring and response.

Before cutover, verify identity paths, least-privilege roles, secrets handling, encryption requirements, logging, segmentation, and incident response. Security validation should test actual access and failure behavior, not just confirm that a policy document exists.

Networking needs performance evidence

Bandwidth planning must account for replication traffic, backups, user access, monitoring, and peak application flows. New routes can introduce latency, asymmetric paths, firewall behavior changes, or dependency failures that don't appear in a simple connectivity test.

Capture source telemetry before migration, then benchmark the target workload against it. Sumo Logic's migration guidance recommends gathering application performance data in the current environment before the move and comparing it with what you see once workloads run in the cloud.

Measure latency, throughput, error rates, CPU, memory, storage behavior, and resource consumption. Run the benchmark repeatedly, and after a warm-up period, so normal variance and cold caches don't distort the result. If performance falls, investigate sizing, storage IOPS, network paths, and unvalidated dependencies before blaming the cloud platform.

Infrastructure-as-code tools such as Terraform make the target environment repeatable and reduce configuration drift, but they don't make a poor design safe. This plain-English guide to what Terraform is used for shows how defining infrastructure in code replaces undocumented manual changes.

When is cloud migration the wrong answer?

Cloud migration is the wrong answer when a workload's dependencies, data-location rules, hardware needs, or economics make the move riskier or costlier than staying put. A migration portfolio should always include the option not to migrate.

The reverse direction is no longer theoretical. In Foundry's 2025 cloud computing survey, 75% of IT decision-makers said they had moved or planned to move applications or workloads out of public clouds and back on-premises. Their reasons included security concerns (53%), cost (48%) and reliability issues (44%) (Foundry 2025 Cloud Computing Survey).

• Security concerns53%
• Cost48%
• Reliability issues44%

Source: Foundry 2025 Cloud Computing Survey

Warning signs that demand restraint

• Undocumented coupling: The application depends on services, jobs, or network controls that nobody has mapped.

• Data residency constraints: Regulations or contracts limit where information can be stored or processed.

• Latency sensitivity: The system depends on physical proximity, specialized hardware, or predictable local response times.

• Unclear economics: Usage is steady, resources are difficult to scale down, or cloud egress and managed-service costs undermine the business case.

• Weak ownership: No team can operate the target environment, respond to incidents, or validate the migration result.

Keeping a workload on-premises can be a rational decision. So can a hybrid architecture, where sensitive or latency-critical components remain local while elastic services move to the cloud. Multi-cloud can also fit organizations with regulatory, resilience, or capability requirements, although it adds operational and skills complexity.

Cost control needs an operating discipline rather than a one-time estimate. The same Foundry survey found that 69% of IT decision-makers planned to create roles dedicated to managing cloud costs (Foundry 2025 Cloud Computing Survey). Those roles help only when engineers, finance teams, and application owners agree on usage accountability.

The practical test is simple: migrate when the target environment improves the workload's business or technical position. Don't migrate to satisfy a slogan.

For systems that need deeper modernization analysis, this guide to legacy system modernization strategies covers alternatives to a forced move.

Who do you need for a cloud migration, and how do you hire them?

A cloud migration needs a cloud architect, DevOps or platform engineers, data engineers, security engineers, QA engineers and a migration lead. Hire each through the engagement that matches how long you'll need that skill. Permanent ownership calls for direct hires, a time-boxed surge calls for contractors, and a migration you'd rather buy as an outcome calls for a vetted migration partner. Tools don't discover undocumented dependencies or decide whether a business process can tolerate a cutover. People do.

The skill sets a cloud migration needs

• Cloud architect: Defines target patterns, landing zone, service boundaries, connectivity and resilience, and records why each workload got its strategy. This overview of the cloud-native architect role covers the skills involved.

• DevOps, SRE and platform engineers: Build the environments in code, deployment pipelines, observability and rollback, and turn the target architecture into something an operations team can run after the project ends.

• Data engineers: Design bulk transfer and change data capture replication, schema handling, reconciliation and the data cutover plan.

• Security engineers: Validate identity and least-privilege access, encryption, segmentation, logging and the shared-responsibility boundary before each wave goes live.

• QA and test engineers: Prove functional behavior, performance against the baseline, integration paths and recovery before production acceptance.

• Migration lead or program manager: Keeps waves sequenced, decisions documented, risks visible and application owners engaged, so the program doesn't lose control of dependencies and timing.

Hire for the target platform as well as the role. An engineer who has already run cutovers on AWS, Microsoft Azure or Google Cloud knows that provider's migration tooling, identity model and failure modes. That shortens discovery and reduces surprises at cutover. If you are moving to one provider, recruit by platform: AWS engineers, Azure engineers and Google Cloud engineers each bring that cloud's migration services and identity model to the first wave.

How have real companies built their cloud migration teams?

Successful migrations have been run in-house, with partners, and with a mix of both. What they share is clear ownership and the right specialists at the right time.

• Netflix (in-house): Netflix began moving to AWS in August 2008 after a database corruption stopped DVD shipments for three days. In January 2016, after seven years, it shut down the last data center used by its streaming service. Its own engineers rebuilt the platform as cloud-native services rather than lifting servers as they were (Netflix).

• Capital One (in-house, built by hiring): Capital One exited eight on-premises data centers by migrating to AWS. It built 80% of the nearly 2,000 applications it now runs in the cloud from the ground up. To do it, it scaled its engineering organization and hired experienced engineers and new graduates (AWS case study).

• University of Newcastle (in-house team plus partners): Facing a data-center deadline, the university completed its migration to AWS in 9 months. University staff, AWS, consulting partner Deloitte and cloud operations partner CSA worked on it together daily. It replatformed 72% of its applications, refactored 23%, and cut infrastructure operations costs by 20% (AWS case study).

• AXIS Capital (internal and partner teams): The insurer moved its Boston primary data center to Azure with around 500 internal and partner team members, including Microsoft and other strategic partners. It completed the full data-center exit in under ten months (Microsoft customer story).

• Norton (a mix of engagement models): To move older on-prem systems fully to the cloud, lower its AWS spend and strengthen security, Norton filled more than 10 software and DevOps roles through TekRecruiter. It used nearshore engineers, US staff augmentation and direct hire, each matched to how long the role was needed (Norton case study).

The pattern in these examples: companies that move everything and rebuild, like Netflix and Capital One, invest in a large permanent engineering team. Companies that need extra capacity add partners or contractors around a core internal team, like Newcastle, AXIS and Norton.

What are the ways to hire for a cloud migration?

Most companies hire for a migration in one of five ways, and many combine two or three. The deciding question is how long you'll need each skill after the last wave moves.

1. Hire one or two permanent owners, then add help for the surge

If you'll run the cloud for years, the cloud architect and a lead platform engineer should be your own employees. They make the decisions you'll live with: landing zone, identity model, cost controls and operating standards. One or two strong direct hires who own the platform, supported by contractors or a partner during the migration itself, is the most common setup for mid-size companies. With TekRecruiter, direct hire searches are contingent, so there's no fee until your hire starts, and every placement carries a 90-day guarantee. In our 2026 placements, SRE and platform engineers averaged about $180,000 to $190,000 in base salary, depending on the stack (TekRecruiter 2026 Tech Salary & Rate Guide).

2. Add a contract migration team through staff augmentation

Migration work peaks during assessment, replication, testing and cutover, then drops. Contractors fit that curve. Through IT staff augmentation, you add migration, data and QA engineers who work under your leadership and inside your tools for the length of the program. With TekRecruiter, consultants can start in as little as three days after you approve them. There's no minimum term, a contractor who isn't working out is replaced quickly, and engagements usually run about 7 to 12 months. You pay one hourly bill rate per consultant that covers their pay, employer costs, insurance and our fee. In our 2026 placements, DevOps, SRE and platform contractors billed about $109 an hour in South Florida, $116 in Boston and $120 in New York (2026 Tech Salary & Rate Guide).

3. Use nearshore engineers for senior skills at a lower cost

Cutovers usually run in your maintenance windows, so time-zone overlap matters more on a migration than on most projects. Nearshore engineers in Latin America work your hours. Through TekRecruiter, a senior SRE or DevOps engineer in Latin America costs about $42 to $57 an hour all in. A US contractor in the same role bills $109 to $120 (TekRecruiter 2026 Tech Salary & Rate Guide). We screen for at least three years working directly for US companies and for professional English. After about a year, an engineer can move to our employer-of-record rate with most of the recruiting fee removed.

4. Convert the people who will run the platform after cutover

The engineer who migrates a workload knows it better than anyone who arrives later. Contract-to-hire lets that person start as a contractor during the migration and join your team once they've proven themselves, with no conversion restrictions.

5. Outsource the migration to a partner or MSP

Outsourcing fits when nobody inside can lead the program. It also fits when you want a company to own a fixed-scope outcome, or a managed service provider to run the environment after the move. It fits less well when the goal is building permanent cloud capability inside your team, because the knowledge leaves with the partner unless the contract requires a handover. If the gap is leadership rather than hands, executive search for a head of infrastructure and cloud may solve more than any vendor. If you need that leadership for months rather than years, a fractional or virtual CTO is a supplier we find through the same partner search described below.

How do you hire cloud migration engineers?

Hire for migrations they've already run, not for certifications alone. The engineers who have led a cutover on your target platform are usually employed and not applying to job posts. Most companies find them through referrals, the AWS, Azure and Kubernetes communities, or a recruiter who works in that market every day.

• Screen for the whole migration, not trivia. Ask the engineer to walk you through a migration they ran: what moved, what depended on it, why each workload got its strategy, how the cutover and rollback were planned, and what broke. AI tools can answer scenario questions; only someone who did the work can explain the whole picture and the business reason behind each decision.

• Match the platform and the tooling. Look for hands-on time with your target cloud's migration and replication services, infrastructure as code such as Terraform, and the observability you'll run afterward.

• Check the contract history for contractors. For contract roles, look for completed engagements of similar length and people who are committed to the work for the full program, not juggling several clients.

• Decide early who stays. Mark which roles you'll keep after the last wave, so you can hire those people permanently or convert them, and plan the knowledge handover for the rest.

TekRecruiter recruits the DevOps, SRE, platform, data and security engineers that migrations depend on. We screen every candidate for the work behind the résumé and for HEART: high agency, execution, accountability, resourcefulness and transparency.

How do you choose a cloud migration partner?

Choose a migration partner on proven experience with your exact source and target, the named team that will do the work, and the terms for cutover, handover and exit. A polished proposal is not evidence. Check these before you sign:

• Matching migrations: Past projects with the same source and target, such as VMware to AWS or SQL Server to Azure SQL, with references you choose.

• The actual team: Who will actually do the work, how long they've been with the firm, and whether the senior people from the pitch stay after the pilot.

• Pricing model: Fixed price suits stable scope, time and materials suits discovery-heavy work, and managed monthly pricing is typical for operations after the move. Ask how scope changes are priced.

• Cutover and rollback: A written plan for each wave, the service levels that apply, and the remedy if a cutover fails.

• Handover and exit: Infrastructure code, runbooks and documentation delivered to you, and exit terms that let your own team or another supplier take over.

• Security evidence: SOC 2 or ISO 27001 reports where relevant, and how the partner's staff get and lose access to your accounts.

• A stack you can staff: Whether you'll be able to hire engineers for the platform and tools the partner proposes once the engagement ends.

The cloud providers' directories are a reasonable place to build a long list: the AWS Partner Solutions Finder, Microsoft's Azure partner directory and the Google Cloud partner directory show each firm's specializations. A listing is a starting point, not vetting.

How TekRecruiter helps you find the right cloud migration partner

TekRecruiter doesn't perform migrations or managed services. We find the top 1% of suppliers the same way we find the top 1% of talent. When the work is better owned by a company, we find and vet the right cloud migration partner or managed service provider for your need.

1. We learn the need: source and target platforms, workloads, timeline, budget, and your security, contract and location requirements.

2. We set the criteria with you before any supplier is contacted.

3. We search and vet across a network that reaches more than 1 million technology and engineering suppliers, through our own relationships and broker-level partner access. We check how each would approach the work and what its track record shows.

4. You meet a shortlist of the suppliers who meet every requirement, and talk with them directly.

5. We check the terms before you sign, so scope, price, cutover and exit terms match what you asked for. The contract is yours with the supplier.

6. We stay in touch for renewals, end dates and the next need, whether that's another supplier or a hire to own what the partner built.

What it costs: nothing to you. The supplier you choose pays an industry-standard 10% finder's fee, the same for every supplier, so we have no reason to favor one. You pay the same price you would going direct, often less. Why it helps: a single supplier can only offer its own services and stack. Through us you compare several vetted options with one point of contact. Because we're vendor- and stack-agnostic and see the hiring market every day, we also tell you whether you'll be able to hire for the stack a partner proposes once the engagement ends.

Keep accountability inside

External support should add capability, not hide accountability. Internal owners still need to approve architecture, security controls, data handling and operational readiness. The strongest arrangement pairs outside specialists with employees who will run the environment afterward.

The right team is the one that can answer five questions at every cutover: what is moving, what depends on it, how will we know it works, what happens if it fails, and who owns it afterward. If those answers are vague, changing providers won't fix the migration.