# How do you migrate petabytes from on-prem to the cloud?

A petabyte-scale migration is a logistics problem with a verification problem inside it. The order that works is the same every time: know exactly what you have, move the bulk while the old system keeps serving, verify every byte, cut over a small delta in a short window, and keep the way back open until you no longer need it.

Canonical: https://kitecorp.org/guides/migrating-petabytes-from-on-prem-to-cloud
Updated: 2026-10-12

## What do you inventory first?

Every data store, with its size, its growth rate, its access pattern and its owner. Size decides the transfer method; growth rate decides how long the delta phase lasts; access pattern decides whether the store can be moved live or needs a freeze; the owner decides who signs off the verification. Add the constraints that do not show in a listing: residency rules that pin data to a jurisdiction, licences that do not transfer, retention obligations, and the systems that read the data from a place that will not exist after the move. The inventory is a spreadsheet at first and a plan by the end, and the plan's phases are grouped by dependency, not by team.

## Which transfer method fits which data?

Online transfer over a dedicated link for anything that fits in the window: at 10 gigabits per second a petabyte takes about ten days of saturated transfer, which is fine for a bulk phase that runs while the old system serves. Physical transfer appliances (the cloud providers ship them) for volumes where the link would take months or where the link does not exist; they move tens of petabytes per shipment and the limiting factor becomes the time to load them. Database-native replication for stores that must stay consistent: set up the cloud side as a replica, let it catch up, and cut over by promoting it. Object stores move with the provider's transfer services, which handle retries and checksums for you; file systems need a tool that preserves metadata and resumes. Mixed estates use all four, each for the data it fits.

## How do you verify integrity at scale?

Count and checksum, recorded. For object stores, compare the listing on both sides (count, size, and the checksum the store exposes) and keep the comparison as a report. For file systems, hash at the source during the copy and verify at the destination, in parallel, because a serial verification of a petabyte takes as long as the copy. For databases, row counts per table and a checksum over an ordered sample, then application-level checks on the records that matter most. The verification runs on the bulk phase and again on every delta, and nothing is declared migrated until its report is green. A migration you cannot prove is a copy you hope is complete.

## How do you plan the cutover window?

Backwards from the delta. After the bulk phase, the remaining difference is whatever changed since; the delta sync moves it, and the cutover window needs only to be long enough to freeze writes, sync the last delta, verify it and switch the readers. For an object store that is minutes; for a busy database it is the time to drain in-flight transactions and promote the replica. The window is rehearsed on a copy before the real one, with the clock running, and the rehearsal's timing sets the window's length with headroom. Readers switch by configuration (a DNS name, a connection string, a feature flag) so the switch is one change and so is the way back.

## What is the rollback?

The old system, kept intact and reachable until the new one has served a full business cycle. Rollback means switching the readers back and replaying the writes that landed on the cloud side in between, so the cloud side logs its writes from the cutover onward until the rollback window closes. Decommissioning the old system is the last phase of the plan, with its own date, and it does not start until the owners of every store have signed off the verification and the cycle has passed. The migrations that go wrong are the ones that tore down the way back to save a month of hosting.

Kitecorp runs this work as part of [cloud migration](/services/cloud-migration) engagements.

## How to start

Send a message at https://kitecorp.org/contact or email admin@kitelang.cloud. Pricing follows a discovery call.