Assess before you move — the seven measurements that make a migration estimate defensible

What to measure, in what order, before anybody quotes a number: the inventory with real utilisation, the network dependency graph that defines the waves, the per-family parity differences, the egress volume, the identity and secret inventory, the observability baseline, and the destination quotas. Each one says what goes wrong without it.

markdownguidev1SD83-S9Z6stage: designtrust: officialfamily: migrationservice: migration-centerinterface: anymigration assessmentinventoryutilisationnetwork dependencieswavesegressquota pre-checkobservability baselineright-sizingmigration center

Created 21 Oct 2026 · Modified 23 Oct 2026 · 1 version

Assess before you move

Seven measurements. Each one is cheap, each one is refusable by a stakeholder who would rather start, and each one has a named failure mode if you skip it.

1. Inventory, with measured utilisation and not provisioned capacity

Use Migration Center (discovery client, manual upload, or agentless CLI export) or the source cloud's equivalent. The output you need is the asset inventory with performance metrics.

Without it: you size the target from what the source was provisioned at, which on most estates is two to four times what it uses. Right-sizing is the single largest saving available and it needs this number.

2. The network dependency graph — this defines the waves

Migration Center produces network dependency visualisations. Build the waves from them.

Without it: waves get drawn by application ownership or by team, two chatty systems land in different waves, and their traffic crosses clouds for weeks at egress rates. That is the most expensive avoidable mistake in migration planning.

3. The per-family differences — what actually changes

Walk the ten parity guides for the families in scope. Each one's estimate-bearing rows are naming, quota model, pricing dimension, regional model and IAM model. Write down the rows that apply to your estate:

FamilyThe row most likely to apply
identityAWS policy JSON decomposing into bindings, conditions and deny policies
networkingN regional networks becoming one global VPC, and the transit object disappearing
storageARCHIVE's 365-day minimum against 180 elsewhere; lifecycle rules needing re-tuning
computefunction concurrency 1-per-instance against up-to-1000 — a correctness risk, not a cost one
databasesSpanner having no counterpart; SQL Server mapping to three Azure products
dataa node count not converting to bytes-scanned or slots
messagingone Pub/Sub against two or three source products, and consumers that disappear
observabilityOpenTelemetry against vendor SDKs

Without it: the estimate is a name-mapping exercise and every difference arrives as a surprise.

4. Egress volume — in bytes, before anyone quotes a number

How many bytes leave the source cloud, and over how long. Storage Transfer Service is optimised for transfers exceeding 1 TiB, which tells you what scale this is at.

Without it: the largest line in the project is missing. It is charged by the source cloud, it is on nobody's target-cloud estimate, and event-driven mirroring means it is charged over the whole migration window, not once.

5. The identity and secret inventory

Count: service accounts or roles per workload; long-lived keys; secrets; and the permissions each workload actually used (not what it was granted).

Without it: you re-create the source's over-granting on the target, and you migrate keys that guides/identity/github-actions-without-keys.md would have deleted. Keys are "a security risk if not managed correctly", and a migration is the one moment when removing them costs nothing extra.

6. The observability baseline — and fix the instrumentation now

Record: logs GB/day by source; custom and log-based metric count with label cardinality; trace volume and sampling; and the count of alerting policies and dashboards, which is a direct effort estimate because they are re-created rather than migrated.

Then do the one thing in this list that pays for itself even if the migration is cancelled: if the estate uses a vendor tracing SDK, move it to OpenTelemetry on the source platform first. Cloud Trace recommends OpenTelemetry over Google-specific APIs, and so do the other two clouds.

Without it: you cannot tell whether the target is slower, and you discover the observability gaps when the source is already gone.

7. The destination quotas, per project and per region

Check the allocation quotas you are about to consume — CPUs, addresses, disks — and request increases before the wave. Distinguish a quota from a system limit: a system limit "cannot be increased or decreased" and needs a design change instead.

Without it: a wave fails half-done, which is the worst state to be in — the source is drained and the target is incomplete (reference/migration/errors.md §3).

Then, and only then

Produce the estimate, with guides/parity-and-migration-method.md as the method. Re-run step 1 after the first wave: measured reality beats every assumption in the plan, including the ones in this guide.

Read this document as markdown — the same bytes an agent receives.