Cloud migration services move a workload off the infrastructure it runs on today — a rack in the office, a rented server, an ageing virtualisation cluster — and onto a cloud environment that is provisioned, monitored and billed by the month. The work is the inventory, the target design and the decision about what not to move; the cutover itself is the smallest part of the engagement.
What a cloud migration engagement actually covers
A migration answers four questions in order: what you have, what it should look like on the target, in what sequence it moves, and who operates it afterwards. Each one produces a document you can argue with — an inventory and dependency map, a target architecture, a sequenced cutover plan, and a runbook for the system after the move.
The deliverable is not a slide deck. It is a running system in the cloud, the old environment either decommissioned or kept warm as a rollback, and monitoring that tells you the migration worked before your customers tell you it did not.
The four shapes of a cloud migration
Almost every migration is one of four shapes, and the shape decides most of the cost. Choosing it deliberately is the single most valuable decision in the project.
| Shape | What moves | Effort and risk | Fits when |
|---|---|---|---|
| Rehost (lift and shift) | Servers copied to cloud instances largely as they are | Lowest effort, fastest; carries existing defects across intact | A lease is ending, hardware is failing, or the deadline matters more than a redesign |
| Replatform | Self-managed components swapped for managed equivalents — managed database, object storage, container runtime | Moderate, and usually the best return per hour spent | You want the operational saving without rewriting the application |
| Refactor or rebuild | The application itself is restructured for the cloud target | Highest effort, and the only shape that changes behaviour | A real constraint — scale, release speed, a component that cannot move — justifies the work |
| Retire or replace | Nothing moves; the workload is switched off or bought as a service instead | Cheapest option, and the most frequently skipped | Usage does not justify the maintenance, or a commercial product already does the job |
What an engagement includes, phase by phase
These phases are the deliverable list. If a proposal does not name them, the missing one is where the surprise will be.
- Inventory and dependency map. Every application, database, scheduled job, integration, certificate and DNS record, plus what calls what. Undiscovered dependencies are the main cause of a cutover that runs past its window.
- Target architecture. Network layout, identity and access, secrets, storage, backup and logging designed before anything moves, so the migration has a destination rather than a direction.
- Sequencing and cutover plan. Which component moves first, which moves last, what a rehearsed move looks like, and the exact trigger that sends you back.
- Data migration. How each dataset crosses, how the last write is captured, and how you prove the copy is complete rather than merely present.
- The move and verification. Cutover inside an agreed window with functional checks, performance checks and the traffic switch handled deliberately.
- Handover. Monitoring, alerting, runbook and an exit path, so the environment can be operated afterwards — by your team or under a managed IT plan — without depending on the migration vendor's tooling.
What drives the fee
There is no honest per-server or per-gigabyte price, because the cost is set by constraint rather than by volume. The drivers that actually move the number:
- Statefulness. Stateless web servers are replaceable and boring. A production database that cannot be offline for more than a minute is the project.
- Downtime tolerance. A maintenance window measured in hours is a different plan from continuous availability, which usually means running both environments and switching traffic.
- Integration surface. Every partner API, fixed IP allowlist and outbound webhook has to keep working from a new address.
- Compliance and data handling. Regulated data constrains region, encryption and logging before it constrains anything technical.
- Sizing honesty. Over-provisioned “just in case” capacity copied from a physical box is how a cloud bill ends up higher than the hardware it replaced.
A vendor who quotes a duration or a price before the inventory exists is quoting the cutover, not the migration.
What to require from a provider
- A written inventory and dependency map you can read, produced before the quote.
- A named engineer accountable for the cutover, not a rotating support queue.
- A rehearsed move against a copy of production, with the results shown to you.
- A rollback plan with a named trigger — and the discipline to use it.
- Verification criteria agreed in advance: what will be checked, and what result means go back.
- Documentation and monitoring handed over at the end, plus a support window after the cutover.
When a cloud migration is the wrong project
Sometimes it is. If the workload is one small application on a healthy machine, moving it changes the bill and little else. If the system is already scheduled for replacement within the year, the migration is throwaway work — replace it instead. If the workload is bound to something physical — a specialised interface card, a latency-sensitive device on site, licensing tied to particular hardware — the cloud target may not be able to host it at all. And if the real problem is that the application is unstable, the cloud moves the instability to a more expensive address; fix the defect first, then decide whether to modernize or rebuild.
The pattern in all four cases is the same: migration is a means, and the means only pays when the objective is clear.
Frequently asked questions
How long does a cloud migration take?
It is set by the inventory, not by the workload count. A handful of services with one database can be assessed and moved in a few weeks; dozens of interacting systems with scheduled jobs, partner integrations and a short maintenance window take considerably longer, because every dependency has to be mapped and every cutover rehearsed. A duration quoted before the inventory exists is a duration for the cutover, not for the project.
Is the cloud always cheaper?
No. The cloud wins on provisioning speed, flexibility and reduced capital cost, and it loses when a steady workload is left running at an over-provisioned size. The saving comes from matching capacity to demand — scaling with traffic, committed pricing for steady load, and deleting what nobody uses. An honest comparison prices the target design rather than the current server, and includes the operational time to run it.
Do we have to move everything?
No, and the most useful list in a migration plan is what stays. Stable, low-change systems with no scaling problem can keep running where they are, reached over a private or encrypted connection. Moving fewer things lowers the risk of the whole project and usually brings the first cutover forward.
What happens to downtime during the move?
It depends entirely on the tolerance you set before the plan is written. With a maintenance window, the migration can be a straightforward copy and switch. With continuous availability, the plan becomes two environments running side by side: the target stands up, data replicates, traffic switches, and the source stays warm until the target is proven. The tolerance changes the plan, not just the schedule.
723 Studios is a software development agency in Fort Lauderdale, Florida, and runs cloud infrastructure for its own client work on AWS, Azure and Google Cloud, delivered with managed hosting, encrypted backups, 24/7 monitoring and incident response under a managed IT plan. The same team builds and maintains the applications it hosts through its engineering services.