--- cuppy_hub: gcp cuppy_path: guides/migration/assess-before-you-move.md cuppy_section: docs cuppy_doc: SD83-S9Z6 cuppy_doc_uuid: be54232c-df98-4351-a831-a30474ee418e cuppy_permalink: https://cuppy.io/gcp/d/SD83-S9Z6 cuppy_version: 1 cuppy_updated: 2026-10-23T16:16:52.575Z cuppy_canonical: https://cuppy.io/gcp/docs/guides/migration/assess-before-you-move cuppy_mcp: https://cuppy.io/mcp cuppy_body_sha256: 9dbb6e66a49f13ade3d3abe862e3e79d0a74016933eabf30112b3a198e75b938 # cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks. --- # 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: | Family | The row most likely to apply | |---|---| | identity | AWS policy JSON decomposing into bindings, conditions and deny policies | | networking | `N` regional networks becoming one global VPC, and the transit object disappearing | | storage | `ARCHIVE`'s **365-day** minimum against 180 elsewhere; lifecycle rules needing re-tuning | | compute | function concurrency 1-per-instance against up-to-1000 — **a correctness risk, not a cost one** | | databases | Spanner having no counterpart; SQL Server mapping to three Azure products | | data | a node count not converting to bytes-scanned or slots | | messaging | one Pub/Sub against two or three source products, and consumers that disappear | | observability | OpenTelemetry 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. --- You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.