Glossary

Cloud migration

Cloud migration is the move of applications and their data to a different environment: into a public cloud, between clouds, back on premises or onto a new platform. Applications can often be redeployed in days, while the volume of data, its metadata and its dependencies set the actual schedule.

Data volume sets the schedule

An application is a few gigabytes of code and configuration. The data behind it can be hundreds of terabytes or several petabytes, and it has to cross a network. One petabyte over a 10 Gb/s link takes a little over nine days at full use of the link; at a more realistic 60 percent, about fifteen. Plans built from the application list rather than the data volume tend to be wrong by weeks. The same weight explains why applications drift toward stored data and stay there, the effect described under data gravity.

How a live migration runs

  1. Inventory. List datasets with their size, object count, owners, and the applications that read and write them.
  2. Full copy. Copy everything while the source keeps serving users.
  3. Catch-up passes. Copy only what changed since the previous pass, so each pass is smaller than the last.
  4. Cutover. When the remaining changes fit in a short window, pause writes, run the final pass and point applications at the target.
  5. Verify. Compare source and target while the source is held read-only.
  6. Retire. Decommission the source only after verification passes.

The cutover window is set by the rate of change, not the size of the dataset. A system that writes a few gigabytes an hour can be caught up in minutes; one that rewrites terabytes a day may never converge, and needs a longer pause or an application-level switch. Keeping the source intact and read-only until verification ends also preserves a rollback path if the target misbehaves under production load.

What do copy tools leave behind?

Object contents rarely go missing. The attributes attached to them do: tags, access permissions, version history and retention dates, including locks set through S3 Object Lock. A tool that copies only bytes writes new objects with default settings and reports success. The verification step therefore compares object counts, checksums, tags, permissions and retention dates on a sample drawn across the whole dataset, which is possible only while the read-only source still exists.

Direction changes the constraint

A move into a cloud is limited mainly by uplink capacity. A move between clouds or back to owned infrastructure is limited also by egress fees, because the source provider bills for reading the full dataset out. The interface on the target decides how much application work follows: a target that speaks the S3 API lets applications move by changing an endpoint, while a proprietary interface means changing code. Estates that run on both sides of a hybrid cloud often migrate in stages rather than in one cutover, using the techniques covered under data mobility.

Frequently asked questions

What is the difference between rehosting and refactoring?

Rehosting moves an application unchanged. Refactoring changes it to use the target environment's services. Rehosting is quicker; refactoring takes longer and usually pays back over a longer period.

Is shipping disks faster than a network transfer?

For very large volumes on slow links, yes. On a fast link a petabyte moves in days over the network, so the choice depends on the transfer time for the actual volume and bandwidth.