Migration Center — the assessment platform, its three collection methods, and the six outputs an estimate can actually use
Google Cloud's own assessment tool, and the reason the owner's use case has a first-party starting point. What it does, the three ways assets get into it, and the outputs — inventory with performance metrics, TCO, network dependencies, risk and product recommendations — that an estimate consumes directly.
markdownreferencev1CCZQ-TM58stage: designtrust: officialfamily: migrationservice: migration-centerinterface: anymigration centerasset discoverydiscovery clientagentlessassessmenttotal cost of ownershipTCOnetwork dependenciesmigration wave planningpreference setgroupsrisk assessment
Migration Center
1. What it is
"A unified platform that helps you accelerate your end-to-end cloud journey from your current on-premises or other cloud environments to Google Cloud."
"Or other cloud environments" is the clause that matters here. This is not an on-premises-only tool, which makes it the first-party starting point for exactly the cross-cloud work this hub's parity guides serve.
2. Three ways to get assets in
| Method | When |
|---|---|
| discovery client installed | continuous, detailed collection including performance metrics |
| manual upload | you already have an inventory from somewhere else |
| agentless scanning via CLI tools | a one-time export, when you cannot install anything |
The agentless path is the one that unblocks an assessment in a political environment: no agent, no change window, one export.
3. What it does
- cost estimation, in two depths: rapid estimates and detailed assessments;
- asset discovery and inventory;
- infrastructure assessment with technical fit analysis;
- total cost of ownership (TCO) reporting;
- network dependency identification;
- grouping of assets, and migration preference configuration;
- migration wave planning with risk assessment.
4. The outputs, and which of them an estimate consumes
| Output | What an estimate does with it |
|---|---|
| asset inventory with performance metrics | the sizing input. This is the one that matters most — it is measured utilisation rather than provisioned capacity, which is how right-sizing stops being a guess |
| cloud cost projections and TCO reports | the cost line, under preference sets you chose |
| network dependency visualisations | the wave boundaries. Two systems that talk to each other move together, or you pay for the traffic between them crossing clouds mid-migration |
| risk assessments with mitigation strategies | the contingency |
| product recommendations | a starting mapping, to be checked against the parity guides |
| groups and preference sets | the model you re-run the assessment under |
Network dependencies are the most under-used output. A wave plan built from application ownership rather
than from measured traffic is the commonest reason a migration incurs unplanned egress — which is frequently
the single largest unexpected cost in the whole project
(guides/parity-and-migration-method.md).
5. How to use it with this hub
Migration Center answers "what have I got, and roughly what will it cost on Google Cloud". It does not answer "what changes, and what work does that imply" — that is what the ten parity guides are for.
The intended sequence, set out in full in guides/parity-and-migration-method.md:
- inventory and measure — Migration Center, or the source cloud's equivalent;
- map — the parity guide per family, for counterpart names;
- price the differences — the estimate-bearing rows in each parity guide;
- sequence — waves from the network dependency graph;
- move — the migration family's execution services
(reference/migration/migrate-to-virtual-machines.md,
reference/migration/database-migration-service.md,
reference/migration/storage-transfer-service.md).
A rapid estimate is enough for step 3's first pass; a detailed assessment is what you want before committing to a number anybody will be held to.