What are cloud migration services? A practical guide to moving to the cloud

Cloud migration services are the work of moving your applications, databases and infrastructure from where they run today (your own servers, a co-located data centre, a hosting company or another cloud) to a cloud provider such as AWS, Microsoft Azure or Google Cloud. A good migration partner assesses what you have, decides the right approach for each system, builds a secure foundation in the cloud, moves workloads and data with a tested rollback plan, and then tunes cost and performance once you are live.

That definition hides most of the difficulty. The servers are rarely the hard part. The hard parts are the dependencies nobody wrote down, the database that cannot be offline for more than an hour, the licence that does not transfer, and the monthly bill that surprises everyone in month three. This guide walks through what cloud migration services include, the strategies providers use, how a migration actually runs, what drives cost and timeline, and how to tell a careful partner from a careless one. It also covers when you should not migrate at all.

What cloud migration services include

Providers package the work differently, but a complete engagement covers the same ground. If a proposal skips one of these, ask who is doing it, because somebody has to.

• Discovery and assessment. An inventory of servers, applications, databases, integrations, scheduled jobs and the people who depend on them, plus performance baselines so you can prove later that nothing got slower.
• Business case. A realistic comparison of what you run and pay for today against the target setup, including the cost of the migration itself and the period when you pay for both environments.
• Strategy per workload. A decision for every application: move it as is, adjust it, rebuild it, replace it with SaaS, keep it where it is, or switch it off.
• Landing zone. The cloud foundation: accounts or subscriptions, identity and access, networking, logging, guardrails and budgets, ideally defined as code so it can be reviewed and rebuilt.
• Migration execution. Moving workloads in planned waves, replicating data, testing, cutting over and keeping a rollback path open until the new environment has proven itself.
• Data migration. Choosing transfer methods, keeping source and target in sync, and validating that every record arrived intact.
• Optimisation. Right-sizing, autoscaling, storage tiers, commitment discounts and modernising the pieces that benefit most from managed services.
• Decommissioning. Shutting down the old servers, cancelling contracts and securely wiping data, so you stop paying twice.
• Run and support. Monitoring, patching, backups, incident response and cost reporting after go-live, either handed to your team or provided as an ongoing service.

Notice how much of this happens before anything moves and after the move is technically finished. Providers that quote only for the middle part are quoting for the easy part.

Why companies migrate, and when they shouldn't

The good reasons to migrate are specific. A hardware refresh or data centre contract is coming up and you would rather not sign for another five years. Traffic is spiky and you are paying for peak capacity all year. Your team spends its time patching servers instead of shipping features. You need environments on demand for testing, or managed databases with automated backups and failover that would take months to build yourself. You want to use managed AI, analytics or messaging services that only exist in the cloud.

The weak reasons are vague: 'everyone is moving', 'the cloud is cheaper', 'the board asked about it'. The cloud is often cheaper for variable workloads and for small teams who would otherwise need specialist operations staff. It is often not cheaper for large, steady, predictable workloads running on hardware you already own. Be wary of anyone who promises savings before they have looked at your usage data.

There are honest cases for staying put, at least for now:

• The application is close to retirement or will be replaced by a SaaS product within a year. Migrating it twice is waste.
• It depends on specialised hardware, a mainframe or a licence model with no cloud equivalent.
• A regulator or a contract requires data to stay in a specific facility or country where your preferred provider has no region.
• Latency to on-site equipment (factory machines, lab instruments, point-of-sale hardware) matters more than elasticity.
• You just invested in new on-premises infrastructure that has years of useful life left.

AWS's own guidance lists cases like these under its 'retain' strategy, which is a useful reminder that even cloud providers do not expect everything to move.

A migration is a business decision with a technical delivery, not the other way round. If nobody can say what will be better, measurably, once a workload is in the cloud, that workload is not ready to move.

The 7 Rs: choosing a strategy for each application

Most providers use some version of the 'Rs' to classify workloads. AWS describes seven: retire, retain, rehost, relocate, repurchase, replatform and refactor. Google Cloud's migration guide uses a similar list and adds rebuild (retire the old app and write a cloud-native one). The names matter less than the discipline: decide deliberately, one workload at a time, rather than applying one approach to everything.

One point from AWS's guidance is worth repeating because many buyers get it backwards: for large migrations, AWS recommends rehosting, relocating or replatforming first and modernising after the move, because refactoring during a migration is the most complex and costly option. Google's guide makes the same point in its own words: change the workload as little as possible at first. Modernisation is valuable, but bundling it into the migration doubles the number of things that can go wrong on cutover night. If your system needs deeper work, our legacy software modernisation guide covers that path separately.

How a cloud migration runs, phase by phase

Providers name the phases differently. Google uses assess, plan, deploy and optimise. Microsoft's Cloud Adoption Framework uses plan, prepare, execute, optimise and decommission. The substance is the same.

1. Assess and discover

Start with an inventory, but go further than a list of servers. Map how systems talk to each other: shared databases, APIs, file shares, authentication, scheduled exports to a partner's SFTP server. Discovery tools help by watching network traffic, but they miss the monthly report that runs on the last Friday, so interview the people who operate each system as well. Capture baselines for response times, CPU, memory and storage growth. Record each workload's owner, how critical it is, and how much downtime the business can tolerate.

2. Plan and build the landing zone

Group workloads into waves based on their dependencies. Microsoft's guidance is sensible: move simpler, lower-risk workloads and non-production environments first, include one representative complex system in early waves to surface surprises, and schedule critical systems once the team has proven the process. Avoid business peaks such as month-end close or a seasonal sales period.

In parallel, build the landing zone: the account structure, identity and single sign-on, network design, encryption defaults, central logging, backup policies, budgets and alerts. Define it with infrastructure as code (Terraform, OpenTofu, Pulumi, Bicep or CloudFormation) so changes go through review and the whole foundation can be recreated. This is also the moment to make sure the cloud accounts are registered to your company, not to the vendor doing the work.

3. Migrate in waves

Each wave follows the same loop: replicate, test, cut over, watch, and either confirm or roll back. Rehosting tools replicate servers continuously so the final switch is short. Replatformed or refactored components are deployed through a pipeline into the new environment and tested against production-like data. Functional tests prove things work; performance tests against your baselines prove they work as well as before.

4. Cut over, with a rollback you have actually tested

Decide in advance what counts as failure: error rates, response times, failed health checks, a broken integration. Write the rollback steps down, automate them where you can, and rehearse them in a staging environment. Agree who has the authority to call a rollback at two in the morning. A migration plan without a tested rollback is a hope, not a plan.

5. Optimise and decommission

After a few weeks of real traffic you know what each workload actually needs. Right-size instances, turn on autoscaling, move cold data to cheaper storage tiers, and consider commitment discounts only for usage that is genuinely steady. Then switch off the old environment. Teams often leave it running 'just in case' for months; set a date, take a final backup, and stop paying for it.

Data migration: the part that usually sets the timeline

Applications can be redeployed in minutes. Data has weight. The volume, the rate it changes, and how long the business can stop writing to it decide your approach far more than the choice of cloud provider.

• Offline or downtime migration. Stop writes, copy the data, verify it, switch over. Simple and reliable, and fine for internal tools or systems with a maintenance window.
• Online or near-zero-downtime migration. Copy a snapshot, then stream ongoing changes (change data capture or native database replication) until source and target are in sync, then switch over in a short window. Needed for customer-facing and transactional systems, and noticeably more complex to set up and test.
• Physical transfer. For very large archives, providers will ship you storage appliances to load and send back. Slow, but it keeps the load off your network.
• Network path. A private connection (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) or a VPN is preferable to the public internet for sensitive or large transfers.

Whatever the method, validate. Compare row counts and checksums, run the reports the business relies on in both environments and compare the results, and check character encodings, time zones and file permissions, which are the classic sources of quiet corruption. Keep the source read-only but intact until the business has signed off.

Security and compliance after the move

Moving to the cloud does not hand security to the provider. AWS calls this the shared responsibility model: the provider secures the cloud itself (data centres, hardware, the virtualisation layer), and you secure what you put in it (your data, identities, configuration, network rules and application code). The split shifts with the service: on a virtual machine you patch the operating system, on a managed database the provider does. The cloud incidents that make the news usually start on the customer's side of that line: a public storage bucket, an over-permissive access key, an unpatched server exposed to the internet.

A migration is the best chance you will get to fix security debt, because you are rebuilding the foundation anyway. Use it to enforce single sign-on with multi-factor authentication for every administrator, give each workload its own narrowly scoped role instead of shared keys, encrypt data at rest and in transit by default, centralise logs somewhere an attacker cannot delete them, and keep secrets in a managed vault rather than in configuration files. Our cybersecurity services guide covers the wider programme.

For regulated data, check region availability before you choose a provider. Data protection laws such as the GDPR in Europe, and sector rules in finance and healthcare, can restrict where personal data is stored or who can access it. All three major providers publish compliance documentation for their regions; your partner should map your obligations to specific regions and services, not just assert that the cloud is compliant.

What drives the cost of a cloud migration and of running in the cloud

There are two separate bills: the one-off cost of the migration project, and the ongoing cost of running in the cloud. Both depend on drivers you can identify early.

The project cost is mostly engineering time, and it scales with the number of workloads, how tangled their dependencies are, the strategy chosen for each (rehosting is far quicker than refactoring), data volume and downtime tolerance, how much automation already exists, and compliance requirements. Add the overlap period, when you pay for the old and new environments at the same time, and any training your team needs.

The run cost depends on compute sizing, storage and its tier, managed services, licences (some database and operating system licences cost more in the cloud, others can be brought with you), support plans and, often forgotten, data transfer. Moving data into a cloud is usually free; moving it out, between regions or across the internet to users usually is not. Waste is the other big driver. Respondents to Flexera's 2026 State of the Cloud survey estimated that 29% of their IaaS and PaaS spend is wasted, typically on idle or oversized resources.

The discipline of controlling this is called FinOps. The FinOps Foundation's framework describes it as a loop of three phases: inform (make spending visible and allocate it to teams), optimise (act on what you see), and operate (build the habits and ownership that keep it in check). In practice that means tagging every resource with an owner and a cost centre, setting budgets with alerts, reviewing the bill monthly with engineers in the room, and treating cost as a design input. We cover it in more depth on our FinOps service page.

One regulatory change helps European customers keep their options open. Under the EU Data Act, providers can only charge cost-based fees for switching and data egress during a transition period, and from 12 January 2027 those switching charges, including data egress for switching, are removed entirely, according to the European Commission's explainer. That lowers the cost of leaving a provider later, but it does not remove the engineering effort of leaving, which is why portable choices (containers, open-source databases, infrastructure as code) still matter.

Choosing an approach: four common migration paths compared

How long does a cloud migration take? Two worked examples

Timelines depend on the drivers above, so treat these as illustrations of how estimates are built rather than quotes. Each assumes a competent team and a client who can make decisions quickly.

Example 1: one SaaS product moving from a hosting company to a major cloud. A web application, a background worker, a PostgreSQL database of moderate size, file uploads and a handful of third-party integrations. A senior engineer and a DevOps engineer, part-time support from the product's own developers. Roughly one to two weeks for discovery and the landing zone, two to three weeks to containerise the app, move to a managed database and file storage, and build the deployment pipeline, one to two weeks of testing including a rehearsal of the cutover and rollback, then a cutover in a low-traffic window with near-zero downtime replication. Call it six to eight weeks end to end, followed by a month of tuning and decommissioning.

Example 2: a portfolio of internal business applications in a company data centre. Around thirty applications, mixed Windows and Linux servers, several shared SQL databases, a file server and an identity directory. Assessment alone can take four to six weeks because of the dependency mapping. The landing zone and identity integration add several more. Then waves of a few applications each, every two to four weeks, with a small core team (a lead architect, two or three migration engineers, a database specialist) and application owners joining for their own wave's testing. Plan in quarters, not weeks, and expect the last ten percent of awkward systems to take a disproportionate share of the time.

If the migration is part of a wider rebuild, our software cost calculator can help you size the development side of the work.

Common mistakes that sink cloud migrations

• Skipping dependency mapping. The application moves, the nightly batch job that fed it stays behind, and nobody notices until finance runs month-end.
• Modernising everything at once. Combining a migration, a rewrite and a provider change multiplies risk. Move first, then improve.
• Copying on-premises sizing. Servers sized for five years of growth are expensive by the hour. Size for today and scale.
• No owner for the bill. Without tags, budgets and a monthly review, spending drifts upwards quietly.
• Untested rollback. If you have never rehearsed going back, you do not have a rollback.
• Vendor-owned accounts. If the migration partner owns the cloud accounts or the only copy of the infrastructure code, you have swapped one dependency for another.
• Forgetting the people. Operations teams need runbooks, training and access before go-live, not after the first incident.
• Never decommissioning. Paying for both environments for a year wipes out the savings you migrated for.

How to choose a cloud migration partner

Certifications and partner badges tell you a company has trained people. They do not tell you who will do your work or how carefully. These questions do:

1. Who exactly will plan and carry out the migration, and will they be the people we meet before signing?
2. How will you discover dependencies, and what do you do about the ones tools cannot see?
3. Which strategy do you recommend for each of our workloads, and why not the cheaper or faster one?
4. Will the cloud accounts, infrastructure code, runbooks and documentation be ours from day one?
5. What is the rollback plan for each wave, and when was it last rehearsed?
6. How will you show that performance and data integrity are at least as good as before?
7. What happens after go-live: who watches it, who gets called, and how is cost reported?
8. Are you tied to one provider's partner programme, and how does that affect your recommendation?

Good partners will also tell you which workloads to leave alone. If every system in your estate is recommended for a full re-architecture, ask whose interest that serves.

How Authect approaches cloud migration

Authect is a founder-led studio, so you talk to the founders who plan and build your migration, never a salesperson. Every project is led by a senior engineer who stays with it from assessment to decommissioning, in a small team rather than a rotating bench.

We start with an assessment that tells you what to move, what to change and what to leave alone, with the reasoning written down. We build the landing zone as code, in cloud accounts registered to you, so you own the infrastructure, the code and the documentation from day one, with no lock-in to us. We migrate in waves with tested rollback, and we set up cost visibility and the DevOps pipeline that keeps the new environment maintainable. Our delivery is AI-accelerated, with an engineer reviewing every line, which helps on repetitive work such as generating infrastructure code and runbooks.

Work can run as a fixed-price project for a well-defined migration, as monthly sprints when the scope will evolve, or as ongoing support and evolution once you are live. Our team works from Dubai and Spain, with partners in Lithuania, for clients across Europe, the Middle East and beyond. If you are weighing a move, tell us about your setup and we will give you a straight answer, including when the answer is to wait. You can also read more about our cloud migration service.