The situation this design is for
An organization that has been in the cloud for years usually has one shared network that production runs on, grown project by project, changed by a mix of console, scripts and code, with firewall rules nobody can fully draw. Beside it, a new hub-and-spoke estate has been designed: hubs by environment and regulated scope, workloads in spokes, every change through a pipeline. The question is not whether to move. It is how to move without carrying the old estate's debt into the new one, and without the move itself becoming the excuse for not fixing anything.
The answer this reference design gives is a rule: two estates, one standard. The established estate is not exempt from the controls because it is leaving. Everything it holds is remediated where it runs before it is allowed to move.
The two estates
The established estate is one shared network serving many projects. Its rule is that it is frozen before the first wave: nothing new is built there, and a new project is admitted under a dated exception only until the hub for its scope accepts new work. Its tags are backfilled, six identity tags on every project. It is drained by waves and then retired.
The hub-and-spoke estate is the only place new work lands, once the hub for its scope accepts it. It is changed only through the pipeline. Its projects are born tagged: no project is created without the dictionary's tags. It is the steady state.
Both are held to the whole catalog. In the established estate that means the controls are met where the workload runs, including the network controls, which puts the shared network on firewall policy and fences each portfolio tier by its tag. In the hub-and-spoke estate the same controls are built into the modules and held by the readiness gate.
Three moves, always in this order
Remediate. The workload is brought to the standard in the established estate. Every control that applies to it is met and verified, the network controls included.
Normalize. It takes its standard form: standard modules, dictionary tags and labels, delivery only through the pipeline. A project that will be kept is converted until a plan reports no changes; an application that will be rebuilt is written fresh.
Migrate. It lands in its spoke through the pipeline, in a wave with its portfolio tier, and its footprint in the old estate is deleted.
A readiness gate sits between the second and third move. Nothing from the established estate lands in a spoke without a signed readiness record for its tier, where a tier is one portfolio in one environment. The record is a merge request carrying the evidence of the earlier steps, approved by security and by the network owners, never by the workload's owner alone. A passed gate lapses after 30 days without a landing, and the evidence is read again.
The disposition of every project
Before any of that, every project in the established estate gets a disposition: migrate, join without a network move, retire, or stay. Retiring projects are contained, watched for callers over a full business cycle, and deleted by a register date. Projects that stay are remediated and converted to the pipeline by a conversion date, after which every remaining project is in the pipeline whatever its future. Projects that join without a network move take the hub-and-spoke estate's folder and tag without a wave. The rest migrate, and the migrating ones take the three moves.
One wave, eight steps
Scope, map, prepare the spoke, pre-validate, move, validate, soak, remove. The map is built from five kinds of evidence over a full business cycle: flows, audit logs, routes, firewall hit counts and attachments, read by a viewer-scoped identity. The spoke is prepared by the module with the tier's tag rules carried over from the fence and its range rules cut again for the spoke's addresses. Every mapped dependency is tested in both directions before the move. The landing run is approved on the run itself by both teams, and a constraint admits a kept project only to a spoke host of the hub its environment and scope tags match. Target tests and a catalog scan run in the spoke; the old footprint is left in place, unused, through a soak; then security signs the verification, the freeze exception that would have allowed re-attachment is removed, and the decommission list runs in order.
Until that signature the move is reversible: a failed target test or a missed dependency re-attaches the project under the dated freeze exception and redeploys it from code, and the wave is re-planned. The estate tag and the folder stay on the new side through a rollback and revert only if the tier returns to remediation.
Why the gate signs, and the owner does not
The person who most wants a workload to move is its owner, and the gate exists to make the move safe for everyone else: the hub it joins, the spokes beside it, the regulated scope it may or may not belong in. So the record is approved by the people accountable for the controls and for the network, with the owner's evidence in front of them. Exceptions do not travel: a dated exception in the established estate never lands in a spoke, and a standing need is turned into an approved pattern instead.
What the design is careful about
Freeze once, for the whole estate, before the first wave, rather than scope by scope, so there is one date everyone can plan against. Build the new path before closing the old one; callers move first. Share hybrid circuits between the estates only with separate attachments, routers and route policy per environment. Pick one inspection technology per path, never two. Decide the landing method per portfolio: rebuild in new projects where an outage is not acceptable, keep the project where data or identity is bound to it. And accept that the slowest part is not the network: it is bringing every workload to the standard where it stands, which is also the part that makes the move worth doing.