Data gravity is the tendency for applications, services, and operating processes to accumulate around large, active, difficult-to-move datasets. It is not a mystical force and it is not measured by terabytes alone. It is the combined effect of data volume, change rate, dependency density, latency sensitivity, transfer limits, governance obligations, and the cost of moving or duplicating data.
Cloud migrations fail when teams move the visible application tier but leave the data’s hidden anchors behind: databases, file shares, identity services, backup repositories, integrations, analytics feeds, encryption dependencies, recovery tooling, and people who operate the system.
The practical response is to measure those anchors before selecting a destination or migration wave.
TL;DR: the placement rule
Place compute near the authoritative data when latency, transfer volume, change rate, sovereignty, or recovery constraints dominate. Move or replicate data when the destination creates enough measurable value to justify transfer time, ongoing synchronization, egress, operational complexity, and risk.
Do not approve a migration until the team can answer:
- What is the authoritative copy during every phase?
- How long will the initial copy and final synchronization take at usable throughput?
- Which applications, users, devices, and services read or write the data?
- What data may cross regions, countries, tenants, or providers?
- What will steady-state cross-boundary traffic cost?
- How will integrity be validated and rollback performed?
Measure data gravity as a system
Start with seven dimensions.
| Dimension | What to measure | Why it changes the design |
|---|---|---|
| Volume | Logical and physical size, object count, file-size distribution, compression and deduplication | Determines copy method, staging needs and minimum transfer time |
| Change rate | Writes per second, daily churn, transaction logs, ingest peaks | Determines whether synchronization can converge before cutover |
| Dependency density | Upstream/downstream systems, protocols, identities, DNS, certificates, scheduled jobs | Reveals workloads that must move together or remain connected |
| Latency sensitivity | Response-time budget, chatty calls, storage I/O, user location | Determines whether distance or network variability breaks the service |
| Throughput | Tested usable bandwidth by time of day, packet loss and protocol efficiency | Replaces optimistic circuit speed with an executable transfer plan |
| Governance | Classification, residency, retention, legal hold, key ownership and access rules | May prohibit a destination or require a different data path |
| Economics | Ingress, egress, inter-zone/region traffic, appliances, replication, parallel run and staff time | Exposes recurring cost hidden by a one-time migration estimate |
Treat the result as a workload-and-data graph rather than a server inventory.
The companion guide to measuring data gravity turns these dimensions into inventory, flow, latency, change-rate, and dependency evidence that can be reviewed before wave planning.
Calculate the transfer window before scheduling it
The theoretical lower bound is:
minimum transfer seconds = data size in bits ÷ usable throughput in bits per second
Then adjust for protocol overhead, encryption, compression, small files, source read speed, destination write speed, competing traffic, retries, and operational windows. Test with representative data instead of assuming a percentage of line rate.
For continuously changing data, also calculate whether replication can catch up:
net catch-up rate = usable transfer rate − source change rate
If the net catch-up rate is near zero or negative during peak periods, the migration cannot converge without throttling writes, increasing capacity, changing the replication method, or accepting a longer outage.
Example: a 200 TB repository is not merely a 200 TB copy. If it changes by 4 TB per day, contains hundreds of millions of small files, and can use only part of a shared WAN link, its cutover risk is driven by both the initial seed and the last consistent delta.
Find the hidden anchors
Discovery should include more than network flows. Interview application owners and inspect configuration, logs, schedules, and recovery runbooks for:
- database links, replication partners, and transaction-log consumers;
- file shares, object stores, content-addressed repositories, and archives;
- identity providers, domain controllers, DNS, NTP, PKI, secrets, and key management;
- backup proxies, media servers, immutable copies, and restore dependencies;
- API endpoints, message queues, ETL jobs, analytics pipelines, and batch schedules;
- hard-coded addresses, allowlists, firewall rules, load balancers, and certificate names;
- monitoring, ticketing, CMDB, patching, deployment, and licensing services;
- users, branch sites, factories, devices, and partners that access the data directly.
Cloud-provider migration guidance consistently treats inventory and dependency mapping as prerequisites. Google’s current migration planning guidance recommends mapping workloads to infrastructure and dependencies before planning waves; AWS’s portfolio assessment guidance likewise treats accurate dependency data as foundational.
Evaluate governance before copying data
Data residency is only one constraint. Review:
- where primary, replica, backup, log, and support data are stored;
- whether administrators or support personnel in other jurisdictions can access it;
- which organization owns encryption keys and how keys are recovered;
- retention, deletion, legal-hold, and evidentiary requirements;
- tenant and account boundaries;
- data-processing agreements and subcontractors;
- audit evidence required before and after migration.
Classify each requirement as mandatory, risk-accepted, or design preference. Obtain approval from the data owner, security, privacy, legal, and compliance stakeholders before transfer.
Model steady-state cost, not just migration cost
Data gravity often reappears as recurring traffic after cutover. Model at least four flows:
- user and device access to the data;
- application-to-database and service-to-service traffic;
- replication, backup, analytics, and logging traffic;
- recovery and repatriation traffic.
For each flow, record direction, monthly volume, peak rate, source, destination, price class, retention, and owner. Include cloud egress, cross-region or cross-zone transfer, private connectivity, transfer appliances, temporary storage, dual licensing, and observability ingestion where applicable.
Use provider calculators and contract prices as inputs—not as substitutes for measured traffic.
For a deeper operating-cost model, see controlling data-transfer cost, including recurring egress, replication, backup, logging, and repatriation flows.
Common data-gravity failure modes
Moving compute without its latency-critical data
The application starts in the destination but continues making chatty calls to an on-premises database. Functional tests pass; production latency and WAN variability make the service unusable.
Control: trace dependencies, measure round trips, and test at production concurrency before approving split placement.
Underestimating the final delta
The initial seed completes, but the data changes faster than the replication process can catch up before the maintenance window ends.
Control: measure peak change rate, calculate convergence, rehearse the final synchronization, and define a write-freeze or alternative cutover plan.
Discovering compliance restrictions during transfer
Teams learn late that backups, logs, personal data, export-controlled data, or encryption keys cannot move to the planned location.
Control: classify all copies and metadata—not only the production database—before selecting the target.
Creating an expensive permanent data bridge
The application moves, but reporting, backup, identity, or partner integrations remain elsewhere. Cross-boundary traffic becomes a monthly operating cost and a new failure domain.
Control: model steady-state flows and decide which dependencies move, remain, are replaced, or are retired.
Treating successful copy as successful migration
Checksums match, but jobs, permissions, recovery, monitoring, performance, and business transactions fail.
Control: use application-level acceptance tests and restore tests in addition to byte-level validation.
Choose a migration pattern
Google Cloud’s large-dataset transfer guidance describes several useful patterns. The same decision logic applies across platforms:
- One-time migration: suitable when a controlled outage is acceptable and the final delta can be synchronized inside the window.
- Continuous replication: reduces the cutover window but adds replication complexity and requires a positive catch-up rate.
- Parallel read/write: supports stringent availability goals but demands application changes, reconciliation, and careful consistency management.
- Data-access abstraction: can decouple applications from location, but it is an architecture change—not a shortcut for an urgent lift-and-shift.
- Offline appliance or seeded transfer: useful when online bandwidth is insufficient, with additional chain-of-custody, encryption, shipping, and delta-sync planning.
Select the pattern per dataset, not per migration program.
Use a weighted placement decision
Score each candidate location from 1 to 5 and multiply by an agreed weight.
| Criterion | Example weight |
|---|---|
| Mandatory legal, residency, and sovereignty fit | Gate, not a score |
| Application latency and performance | 20% |
| Transfer feasibility and cutover risk | 15% |
| Dependency co-location | 15% |
| Resilience and recovery | 15% |
| Five-year data movement and platform cost | 15% |
| Security and key ownership | 10% |
| Operational skills and tooling | 5% |
| Exit and repatriation feasibility | 5% |
A failed mandatory gate eliminates a candidate. Keep the scoring evidence, assumptions, and data date with the architecture decision record.
The data-locality architecture patterns guide can help translate that placement decision into compute, storage, caching, replication, and access boundaries.
Migration runbook and rollback gates
- Freeze the scoped inventory and dependency graph.
- Record baseline performance, error rates, transaction counts, checksums, and recovery state.
- Provision the target with identity, network, logging, backup, encryption, and policy controls.
- Seed data and validate completeness.
- Start replication or incremental synchronization.
- Rehearse cutover with representative load and production-like data.
- Define a last safe rollback point and the authority that can invoke it.
- Quiesce writes or enter the approved parallel-write mode.
- Apply the final delta and run technical and business validation.
- Observe through a stabilization window before retiring the source.
Rollback is credible only while the source remains consistent and the team knows how to reconcile writes made after cutover.
Treat recovery as a placement decision too: disaster recovery and data gravity explains how replica location, restore bandwidth, sovereignty, and dependency order affect recoverability.
Post-cutover measures
Track application response time, throughput, error rate, data freshness, replication lag, transfer volume, egress cost, backup success, restore time, policy exceptions, user experience, and support effort. Compare them with the baseline and decision thresholds.
Data gravity has not been solved if the workload is merely running in a new location. It has been managed when performance, governance, recovery, and economics remain inside agreed limits.