Deployment Plan — Agile Work Breakdown

A ready-to-use work breakdown for a VMware Cloud Foundation 9.1 deployment, structured as epics → stories → tasks so it drops straight into a scrum / agile backlog (Jira, Azure DevOps, GitLab, …). It captures what and in what order and who owns it — deliberately no dates or estimates; add those in your own tool.

▶ Open the Deployment Plan export tool — build your deployment scope and export this plan as Markdown or a CSV that imports into Jira, Azure DevOps, or GitLab.

▶ Track execution in the Deployment Tracker — the same plan as a checklist: tick stories as done, watch per-epic progress, and save/load the progress file to hand over between colleagues (it follows the scope you set in the export tool).

Build your scope from the blocks below: the core epics apply to every deployment, and the variants switch on independently. The management domain can be stretched or not; the Day-2 fleet is optional; and you add one or more workload domains, each independently non-stretched or stretched.

Scope building blocks

Epic ids follow execution order. Mix freely — e.g. a stretched management domain

• the Day-2 fleet + two workload domains (one stretched) = Core + E7 + E8 + two E9. Execution order runs core config → management stretch → Day-2 → workload domains → handover. The export tool assembles the exact epic/story set per scope.

Core epics (every deployment)

E1 — Network, DNS & routing plan · Owner: Network + AD/DNS/NTP

Ref: 01-network-dns-plan.md

• Story 1.1 — VLAN / subnet plan. Lock every management VLAN, subnet, MTU, gateway, and the IP carve-out.
  • Acceptance: one-page plan signed by the network owner; every VLAN/subnet/gateway/MTU recorded and no overlapping subnets.
• Story 1.2 — North-south connectivity plan (choice: Centralized or Distributed). Pick the model per domain (intake A10 for the management domain, H4 per workload domain) and plan only that model’s inputs — see 01-network-dns-plan.md §B.
  • Centralized (BGP plan). Edge AS, ToR AS, peer IPs, BFD, advertised/received routes — plus an optional MD5 password only if you enable BGP authentication.
  • Distributed (Transit Gateway plan). No BGP and no Edge uplinks: plan the external VLAN (every ESX host in the domain must attach to it) and its gateway CIDR, the routable external IP block for north-south NAT/SNAT and load-balancer VIPs, the private transit-gateway block (9.1: must be a /16 — a /24 worked in 9.0 and never completes in 9.1), the VNA appliance FQDNs + IPs (2 minimum for HA, on the ESX Management subnet), and whether default outbound NAT is enabled. Routing is the fabric’s job here — there is no Tier-0, so the physical network must route the external VLAN and advertise the external IP block.
  • Acceptance: Centralized — Edge AS, ToR AS, peer IPs, BFD, and advertised/received routes agreed and documented with the fabric team. (BGP MD5 is optional — capture a password only if authentication is enabled; VCF/NSX requires just the neighbor IP + remote AS.) Distributed — external VLAN + gateway CIDR, external IP block, private transit block (/16), and the VNA FQDNs/IPs agreed with the fabric team, with written confirmation that the fabric routes the external VLAN and advertises the external IP block — the same gate BGP gets under Centralized.
• Story 1.3 — DNS & NTP records. All A + PTR records created; NTP sources confirmed.
  • Acceptance: forward (A) + reverse (PTR) records created for every planned appliance FQDN and resolving both ways; NTP sources reachable and serving.
• Story 1.4 — Certificates. CA type (Microsoft CA or OpenSSL; external CA is CSR-based only — VCF won’t import an externally-created cert+key), template, and signing approach decided.
  • Acceptance: CA reachable; signing method and certificate template chosen, with a test issuance succeeding.

E2 — Intake & sizing · Owner: Architect + all role teams

Ref: 02-intake.md · 04-sizing.md

• Story 2.1 — Role-based intake complete. Sections A–F answered by their owners.
  • Acceptance: every intake question answered or explicitly marked N/A by its owner.
• Story 2.2 — Sizing & host fit. Run the sizing calculator; confirm the fleet fits the proposed hosts at N-1.
  • Acceptance: sizing fit-check passes at N-1 (or hosts adjusted); sizing signed off by the architect.

E3 — Workbook & deployment-JSON prep · Owner: Architect + Platform

Ref: workbook-cell-mapping.md

• Story 3.1 — Fill the P&P workbook. Transfer intake answers into the official workbook — or use Coscia’s VCF Planner for an easier fillable form (live VLAN/IP/CIDR validation) that also doubles as an as-built record, with JSON/Markdown/CSV export.
  • Acceptance: workbook complete with no red validation warnings (or the equivalent complete in Coscia’s Planner).
• Story 3.2 — Generate the deployment JSON. Produce the bring-up JSON (e.g. VCF.JSONGenerator) from the filled workbook.
  • Acceptance: deployment JSON generated, schema-valid, and reviewed against the plan.

E4 — Prerequisites & readiness gate · Owner: Architect + infrastructure teams

Ref: prerequisites.md

The final go/no-go before bring-up — it verifies everything the plan (E1–E3) called for has actually been built. Runs in parallel with E1–E3; must be all-green before E5.

• Story 4.1 — Hardware ready. Hosts on the VCG, matched spec, BOM confirmed. Ref: Preparing ESX Hosts for VCF.
  • Confirm CPU/RAM/storage per host against the sizing output (E2).
  • Principal storage (choice: vSAN ESA / vSAN OSA / NFS / VMFS-on-FC) — pick it in the export tool; it adapts these prereqs and the E5 bring-up. vSAN ESA wants all-flash NVMe + 25 GbE; NFS/FC need external storage + the storage network (no local vSAN disks).
  • Acceptance: all hosts on the Broadcom compatibility guide, identical spec; host count meets the cluster minimum (with an even per-AZ split if the cluster will be stretched).
• Story 4.2 — Physical network ready. VLANs, MTU, and the north-south fabric provisioned — which fabric work depends on the connectivity model chosen in story 1.2.
  • Trunk the required VLANs to host uplinks; set MTU 9000 on jumbo networks.
  • Centralized: configure the ToR BGP fabric (AS numbers, peer IPs) for the NSX edges.
  • Distributed: trunk the external VLAN to every ESX host in the domain (not just to an edge pair — there are no Edge VMs), configure its gateway SVI on the ToRs, and advertise the external IP block upstream. Because there is no Tier-0, the physical fabric performs the routing NSX would otherwise do — so this is a hard gate, not a follow-up.
  • Acceptance: required VLANs trunked with MTU 9000 on the jumbo networks; Centralized — ToR BGP fabric up; Distributed — the external VLAN reaches every host in the domain, its gateway answers, and the external IP block is reachable from upstream. All verified against the network plan (E1).
• Story 4.3 — Core services ready. AD, DNS, NTP, CA, depot reachable (open the firewall flows — see 07-firewall-ports.md).
  • Acceptance: forward (A) and reverse (PTR) DNS resolves both ways for every management/fleet FQDN — ESXi hosts, vCenter, SDDC Manager, NSX Manager VIP + the 3 nodes, the NSX Edge nodes (Centralized) or the VNA appliances (Distributed) — a domain has one or the other, VCF Operations nodes (+ optional external LB VIP), Cloud Proxy, License Server, and the VCF Management Services FQDNs (fleet components, instance components, identity broker, services runtime — all deployed at bring-up), and any Day-2 fleet appliances (Automation, Log Management; plus the Avi controller nodes + VIP if the Avi LB is in scope); NTP in sync; CA reachable; depot/binaries staged.
• Story 4.4 — Access & final readiness. A jump/bastion host reaches the management network, and out-of-band (iDRAC / iLO / BMC) access to the hosts is available.
  • Acceptance: the build team can reach the management network and host consoles; and the full prerequisites checklist (prerequisites.md — hardware, network, AD, DNS, NTP, CA, depot) is green before bring-up starts.

E5 — Management domain bring-up · Owner: Platform

• Story 5.1 — Install & configure the management hosts. Image each host with the supported ESXi ISO (see the VCFHostPreparation repo to prep + commission hosts quickly); set the management VMkernel (IP / gateway / VLAN), DNS, NTP, and root password; confirm the ESXi build matches the BOM. Ref: Preparing ESX Hosts for VCF.
  • Acceptance: every host reachable on the management network with the matched ESXi build; DNS + NTP correct.
• Story 5.2 — Stage the VCF Installer. Deploy the Installer on a management-domain host using the IP + FQDN planned for SDDC Manager (it switches into SDDC Manager at bring-up — not a throwaway IP); verify it reaches the ESXi management network. Ref: Deploy the VCF Installer Appliance.
  • Running the Installer outside the management domain is also supported — the wizard then deploys a separate, new SDDC Manager appliance and asks for its FQDN (“The VCF Installer appliance is not deployed on one of the hosts in the management domain. During the deployment process, a new SDDC Manager appliance will be deployed.”). Plan the extra FQDN + IP if you take that route; on the host-resident route the SDDC Manager FQDN is not asked again.
  • On that host, put the Installer on a port group carrying the VM Management VLAN. A fresh ESXi host’s default VM Network port group is untagged (VLAN 0), so if VM Management is a tagged VLAN, set the VLAN ID on it (or use a tagged port group) first — otherwise the appliance has no management connectivity.
  • Acceptance: VCF Installer deployed on the VM-Management VLAN, resolves in DNS on the planned SDDC Manager FQDN, and reaches the ESXi management network.
• Story 5.3 — Deploy the management domain. Run bring-up: the Installer validates the prepared hosts, then works through its milestones — deploy vCenter → deploy SDDC Manager → configure the vSphere cluster → deploy & configure NSX → VCF Management Platform (VCF Operations) → operations appliance → VCF Management Services. Plan ~4–6 hours for the run. On the Review page, download the JSON spec — it can be edited and re-uploaded from the Installer homepage for repeatable/automated runs. Ref: Start a New VCF Fleet Deployment by Using the VCF Installer Deployment Wizard.
  • VCF Operations is deployed at bring-up in VCF 9.1 — not Day-2. Only VCF Automation can be deferred indefinitely (Existing Component screen: “I have an existing VCF Automation instance, or I will deploy later”). VCF Operations can be deferred only short-term for custom network placement: the Management Components Custom Networking toggle (Network Options → Customize) defers VCF Operations + Automation — along with their cloud proxy and license server — until you run the wizard’s third deployment path, Deploy deferred components, onto the prepared vDS / NSX segment.
  • Decide up front whether an external load-balancer VIP fronts the cluster (optional — without one you reach the cluster via the node FQDNs; there is no built-in cluster/floating IP) — VCF never provides the LB for Operations, so provision an external LB and add its FQDN to the cert SAN first if you want a VIP.
  • The Installer warns (soft-stop) when the hosts leave less than 20% resource headroom over the deployment’s requirement, and it auto-generates all component passwords — capture them via Review Passwords during/after the deploy.
  • Acceptance: bring-up completes; vCenter, SDDC Manager, NSX, and VCF Operations healthy; vSAN datastore online; auto-generated component passwords captured in the password vault.
• Story 5.4 — Verify VCF Management Services, License Server & Cloud Proxy. These are part of the automatic bring-up in VCF 9.1 — the Installer deploys VCF Management Services (VCF services runtime, identity broker, fleet & SDDC lifecycle, software depot, telemetry) with the instance, a unified Cloud Proxy is “configured by default by the VCF Installer”, and a License Server is “automatically deployed as part of the installation”. So plan their FQDNs/IPs before bring-up, and after bring-up verify them in VCF Operations. (The manual “deploy VCF Management Services and License Server” TechDocs procedure applies to the 9.0 → 9.1 upgrade path only.) Refs: Cloud Proxies in VCF Operations, License Server.
  • The License Server needs a unique FQDN resolving to an IP outside the VCF services-runtime range (IPv4 only). The Cloud Proxy stays on the VM-Management network and needs ports 443 / 4505 / 4506 to VCF Operations (see 07-firewall-ports.md §E). Licenses are applied fleet-wide later (E8 8.5) — within the 90-day evaluation period that starts at bring-up.
  • Acceptance: VCF Management Services + License Server up and healthy after bring-up; the License Server FQDN resolves to an IP outside the services-runtime range; the Cloud Proxy is collecting.

E6 — Management domain configuration · Owner: Platform + Network + Security

• Story 6.1 — NSX north-south connectivity (choice: Centralized or Distributed). Pick the model in the export tool; it writes the right steps.
  • Centralized — deploy the NSX Edge cluster + Tier-0 gateway; establish BGP peering to the ToRs; verify north-south routes. (A stretched Edge is only possible under Centralized — see 03-multi-az-prep.md §D.) Ref: Set up Centralized Connectivity with Edge Clusters.
  • Distributed — the Distributed Transit Gateway (DTGW) distributes routing to the hypervisors (no centralized Edge cluster, no Tier-0, no BGP). Attach the DTGW to the external VLAN planned in 1.2 — the VLAN every ESX host in the domain reaches — with its gateway CIDR routed by the physical fabric, and the routable external IP block advertised upstream. Configure the private transit-gateway block (/16 in 9.1). Then deploy the Virtual Network Appliance (VNA) cluster — 2 appliances minimum for HA, each with an FQDN + static IP on the ESX Management subnet — which is what gives the DTGW its stateful services (NAT/SNAT); enable default outbound NAT against it if planned. A VNA cluster is not a small Edge cluster: no Tier-0 or Tier-1 runs on it. Ref: Set up Distributed Network Connectivity.
  • Acceptance: the chosen model is up — Centralized: Edge cluster + Tier-0 + BGP routes reachable. Distributed: the DTGW is up on the external VLAN, the fabric routes its gateway CIDR and advertises the external IP block, the VNA cluster is healthy on 2+ nodes, and north-south including stateful services (NAT/SNAT) is reachable end to end.
• Story 6.2 — Certificates (optional / partial here). You can replace certificates for the components deployed so far now, but the full CA-signed replacement is usually done once all components exist — after the Day-2 fleet — so the whole fleet is certified in one pass (see E8 story 8.5).
• Story 6.3 — Identity & roles (optional, not recommended at this stage). You can bind vCenter SSO directly to AD/LDAP now for early management access, but the recommended path is fleet-wide SSO via the VCF Identity Broker — already deployed at bring-up with the management services, configured Day-2 (see E8 8.5 / 05-day2-deployments.md). Prefer deferring identity to Day-2; only bind vCenter SSO here if you genuinely need AD admin access before the fleet is up, and map admin/operator/viewer groups if you do.
• Story 6.4 — Backup & lifecycle. Configure SFTP backups — including each vCenter’s file-based backup, set manually in that vCenter’s management interface (VAMI); VCF does not configure it for you (see 08-backup-target.md). Connect the depot for fleet lifecycle (SDDC Manager already has its own depot from bring-up — this is the fleet-wide LCM depot, not a re-do). Ref: File-Based Backups for SDDC Manager, NSX Manager and vCenter.
  • Acceptance: a test SFTP backup completes — for SDDC Manager and for every vCenter (VAMI schedule set); fleet-lifecycle depot connected. (North-south routing is verified in 6.1; certificates, identity & licensing are finalized Day-2 — see E8 8.5.)

Variant epics (add per scope)

Order runs core config → management stretch (E7) → Day-2 (E8) → workload domains (E9, one per WLD) → handover (E10).

E7 — Stretch the management domain · Owner: Network + Architect + Storage

Ref: 03-multi-az-prep.md

Stretch sequence: inter-AZ fabric → commission second-AZ hosts → witness → stretch (the same order a stretched workload domain follows in E9).

Edge cluster before or after the stretch? Either works — it’s a choice, not a constraint. Stretching a cluster that already hosts the Edge cluster is a first-class path (the stretch spec carries isEdgeClusterConfiguredForMultiAZ for exactly this), and deploying an Edge cluster onto an already-stretched cluster is equally supported — “VMware Cloud Foundation 4.5 and later support deploying an NSX Edge cluster on a vSphere cluster that is stretched”, with new edge nodes placed on AZ1 hosts. This plan’s default order (E6 edges → E7 stretch) simply verifies north-south while the environment is still single-AZ. Either way the stretched Edge Overlay + Uplink networks must exist first (03-multi-az-prep.md §D — Centralized connectivity only).

• Story 7.1 — Inter-AZ fabric. Verify <5 ms RTT, ≥10 Gbps, MTU 9000, HA L3 gateway between AZs.
  • Acceptance: inter-AZ link measured under 5 ms RTT, at least 10 Gbps, MTU 9000 end-to-end; HA L3 gateway between AZs verified.
• Story 7.2 — Install, configure & commission the second-AZ hosts. Image the AZ2 hosts with the supported ESXi ISO (see VCFHostPreparation to prep + commission hosts quickly); configure the per-AZ management network (IP / VLAN / gateway), DNS, NTP, and root; then commission them into SDDC Manager, ready for the stretch.
  • Acceptance: AZ2 hosts reachable on their per-AZ management network with the matched ESXi build; commissioned and available in SDDC Manager.
• Story 7.3 — Witness site (management). Deploy the vSAN witness appliance for the management cluster at the third site (its own — a vSAN witness serves only one stretched cluster); route it to both AZ ESX-management networks. Ref: Deploying a Witness Appliance.
  • Acceptance: management witness appliance deployed at the third site and reachable from both AZ ESX-management networks.
• Story 7.4 — Stretch the cluster. SDDC Manager does the stretch for you — submit a stretch JSON spec via the SDDC Manager API and VCF builds the fault domains (AZ1 preferred / AZ2 secondary / witness), balances hosts across the AZs, and flips the datastore storage policy to site mirroring (stretched, ~2× capacity). You just supply the inputs from 7.1–7.3: an AZ2 network pool, the commissioned AZ2 hosts (equal count per AZ), and the witness. It won’t stretch if the cluster shares a vSAN storage policy with another cluster, has DPU-backed hosts, or has L3-different subnets within an AZ. If the cluster already hosts an NSX Edge cluster (E6 6.1, Centralized), set isEdgeClusterConfiguredForMultiAZ: true in the stretch spec — wrong, and the edge-specific AZ configuration is skipped. Optionally build the clusterStretchSpec with VCFJsonSpecCreators’s New-VCFvSANStretchSpec.ps1, which assembles, validates, and PATCHes the spec and sets isEdgeClusterConfiguredForMultiAZ for you. Ref: Broadcom — Stretching vSAN Clusters · Stretch a vSAN ESA or OSA Cluster Using the SDDC Manager API · 03-multi-az-prep.md.
  • Acceptance: SDDC Manager reports the cluster stretched; vSAN healthy and storage-policy compliant (site mirroring); isolating one AZ keeps VMs running on the surviving site.

E8 — Day-2 fleet deployment · Owner: Platform

Ref: 05-day2-deployments.md

VCF Operations (+ fleet management, incl. the Identity Broker) is deployed at bring-up (E5 5.3), not here — in VCF 9.1 only VCF Automation can be deferred to Day-N. This epic covers the components you defer or add after bring-up, plus Day-2 configuration of bring-up components (fleet SSO, certificates, licensing).

• Story 8.1 — Network placement. Decide Shared / Dedicated / NSX Overlay / NSX VLAN Segment for the Day-2 components; build the network if non-shared. Ref: Fleet-Level Components Networking Detailed Design · custom-networking deployment guidance.
  • Acceptance: chosen placement built (or the shared network confirmed); the segment/VLAN is reachable and the fleet FQDNs resolve.
• Story 8.2 — VCF Automation. Choices (pick them in the export tool and it writes the exact steps):
  • Deploy it? — VCF Automation is the one fleet component you can defer from bring-up to Day-N.
  • Deployment model — single-node (no load balancer) or an HA cluster (three nodes behind a cluster VIP served by VCF Automation’s built-in load balancer — no external load balancer required; the built-in LB is automatically configured for both models, per the TechDocs design library’s VCF Automation Load Balancing Design).
  • Network placement — Shared Management (nodes come from the mgmt /29, intake B5; simplest, no new network), or a non-shared placement (Dedicated Management / NSX Overlay Segment / NSX VLAN Segment) that builds the network first — see 05-day2-deployments.md §C. The NSX Overlay Segment placement needs an Edge cluster + Tier-0 — under Distributed connectivity (no centralized Edge) deploy one for the fleet segment first, or pick a VLAN-backed placement.
  • Avi in front? — optional; ticking it adds Story 8.3 below.
  • Deploy via SDDC Manager API or via VCF Operations; set the services-runtime cluster CIDR.
  • Acceptance: VCF Automation deployed and healthy; the services-runtime cluster CIDR is set and non-overlapping.
• Story 8.3 — Avi Load Balancer in front of VCF Automation (optional). Deploy the Avi controller cluster in the management domain via VCF Operations (lifecycle-managed; its IPs/FQDNs/passwords are captured up front in prerequisites.md → Avi Load Balancer and intake E16/F11), then configure the virtual service in front of VCF Automation. An external LB is an optional post-deployment addition — its pool points at the cluster VIP of Automation’s built-in load balancer, which stays the ingress. The built-in LB is L4-only, so Avi in front is what adds SSL termination and keeps user/tenant access off the management network. Ref: Deploy Avi Load Balancer from VCF Operations.
  • Licensing is its own appliance. Avi is licensed through License Hub, deployed from the SSP Installer — not the License Server from bring-up (story 5.4); the two coexist. It is three VMs and ~9 IPs, and air-gapped sites need a manual license file import every six months. Plan it with this story, not at first expiry: prerequisites.md → License Hub, intake E17.
  • Acceptance: Avi controller cluster healthy; License Hub deployed and the Avi licenses registered (and, if disconnected, the six-month re-import owner named); the virtual service fronts VCF Automation and its published FQDN resolves to the Avi VIP.
• Story 8.4 — Optional fleet components. Deploy the remaining fleet components as needed: Log Management and VCF Operations for Networks. Each is individually selectable in the export tool — the generated story lists only the selected ones. (The Identity Broker is not deployed here — it arrives at bring-up with the management services; whether to use it for fleet SSO is the 8.5 choice, and if broker-based fleet SSO is out of scope, E6 6.3 becomes the identity path.)
  • Acceptance: each selected Day-2 component healthy; the fleet-management health (synthetic) check passes.
• Story 8.5 — Certificates, identity & licensing (full fleet). Now that all components exist, do the full CA-signed certificate replacement across the whole fleet in one pass, complete fleet SSO via the VCF Identity Broker (configuration, not deployment — the broker has been running since bring-up; this is the recommended identity path, deferred from E6 6.3 — prep the AD/LDAP identity source and its gotchas first: prerequisites.md → Identity source for the VCF Identity Broker), and apply licensing across the fleet (via VCF Operations). Ref: Configure a Certificate Authority · Configure an Identity Provider.
  • Acceptance: every fleet endpoint presents a CA-signed cert with no trust warnings; AD/LDAP SSO via the Identity Broker works; licensing applied.

E9 — Workload domain · Owner: Platform + Network (+ Storage if stretched)

Ref: 02-intake.md section H (+ 03-multi-az-prep.md if stretched)

Repeat this epic per workload domain. Each WLD is independently non-stretched or stretched — a stretched WLD gets its own second-AZ hosts and its own vSAN witness (a witness serves only one stretched cluster, so each has a dedicated one; shared-witness is 2-node-cluster only, not stretched), and follows the same hosts → witness → stretch order as the management stretch (E7). A stretched WLD also requires the management domain to be stretched first (E7).

NSX connectivity is per workload domain (intake H4) — Centralized (this domain’s Edge cluster + Tier-0 + BGP) or Distributed (Distributed Transit Gateway + VNA cluster) — and is chosen independently of the management domain’s model, so the export tool asks it per WLD. It drives the WLD connectivity story (9.4 / 9.6 below).

vSphere Supervisor (optional, per WLD): tick Supervisor in the export tool to add an Enable vSphere Supervisor story to that WLD. Activation requires that domain’s north-south connectivity to already be up, so with Supervisor enabled the WLD connectivity story becomes an explicit prerequisite and also carries the Supervisor-specific reservations — Centralized: the Edge cluster + Tier-0 plus the Supervisor ingress / egress CIDRs; Distributed: the Transit Gateway + VNA plus the routable external IP block and the /16 private transit-gateway block (9.1). Activation also needs a load balancer, chosen per WLD in the export tool:

• Built-in NSX/VPC LB (default) — the NSX / VPC networking paths bring their own load balancer; no extra appliance.
• Foundation Load Balancer — the platform-packaged lightweight L4 LB (one or two VMs in an active/passive pair) for Supervisors on VDS networking; adds a deploy step to the enablement story.
• Avi Load Balancer — the premium option on every networking stack; choosing it adds its own story ahead of the enablement: deploy the controller cluster into the management domain — controllers always live there, never in the workload domain, and a set is scoped to the NSX instance, so a WLD sharing an existing NSX instance reuses that set rather than getting a new one — via VCF Operations (lifecycle-managed; Avi 32.1.1+ binaries must be in the depot; controller IPs/FQDN/passwords per prerequisites.md → Avi Load Balancer and intake E16/F11; a local content library for the Service Engine images), then the networking integration — the cloud connector (NSX Cloud with VPC mode under Distributed/VPC: SE management on an overlay segment behind a Tier-1 with DHCP, VIPs from the VPC external IP blocks; NSX Cloud, or a vCenter cloud for VDS networking, otherwise: SE management on a VLAN or overlay segment, VIP network + IPAM profile) and the Service Engines, which run per cluster in the workload domain (minimum 2 per cluster for HA). Avi also needs License Hub (SSP Installer; separate from bring-up’s License Server, they coexist — prerequisites.md → License Hub, intake E17). Per the Avi-for-VCF 9.1 requirements, all of it must exist before Supervisor activation.

Plus a control-plane size (Small / Medium / Large). The full prerequisite checklist — 5 consecutive control-plane IPs, API FQDN + DNS, per-path IP blocks (9.1: VPC transit-gateway block must be a /16), DRS/HA, storage policies, Kubernetes content — is in prerequisites.md → vSphere Supervisor. Ref: vSphere Supervisor Platform · Requirements for Deploying Avi Load Balancer (VCF 9.1).

Non-stretched WLD:

• Story 9.1 — WLD network prep. Provision the per-WLD VLANs/subnets (Step 1) and the 5 IPs the WLD consumes on the mgmt VM-mgmt subnet.
  • Acceptance: per-WLD VLANs/subnets provisioned; the 5 mgmt-subnet IPs reserved; DNS in place.
• Story 9.2 — Prepare & commission the WLD hosts. Image the WLD hosts with the supported ESXi ISO (see VCFHostPreparation); configure the management network, DNS, NTP; then commission them into SDDC Manager.
  • Acceptance: WLD hosts reachable, matched ESXi build, commissioned in SDDC Manager.
• Story 9.3 — Deploy the WLD. vCenter + NSX (shared or dedicated) + first cluster. Optionally build the domain spec with VCFJsonSpecCreators (New-VCFWorkloadDomain.ps1; New-VCFNetworkPool.ps1 for the domain’s network pool, New-VCFClusterSpec.ps1 to add further clusters), which validates each payload against SDDC Manager before submit.
  • Acceptance: WLD deployed; its vCenter + NSX healthy; first cluster online in SDDC Manager.
• Story 9.4 — WLD connectivity (Centralized / Distributed). Build this domain’s north-south per its own connectivity model (H4) — chosen independently of the management domain’s.
  • Centralized: deploy this domain’s Edge cluster + Tier-0, peer BGP to the ToRs (Edge AS, ToR AS, peer IPs, BFD), verify north-south routes.
  • Distributed: build the Distributed Transit Gateway on this domain’s external VLAN — every ESX host in this domain must attach to it — with its gateway CIDR routed by the fabric and a routable external IP block advertised upstream; configure the private transit block (/16); deploy this domain’s VNA cluster (2+ appliances, FQDN + IP each, ESX Management subnet) for stateful services (NAT/SNAT). These are per-domain inputs — a second Distributed WLD needs its own external VLAN, IP block and VNA cluster, not a share of the management domain’s.
  • With Supervisor enabled this story is its prerequisite and also reserves the Supervisor CIDRs / IP blocks (see the Supervisor note above).
  • Acceptance: WLD healthy in SDDC Manager; north-south reachable — Centralized: Tier-0 + BGP routes; Distributed: DTGW on the external VLAN, fabric routing confirmed, VNA cluster healthy on 2+ nodes, NAT/SNAT working. Workloads can be placed (and, with Supervisor, its connectivity prerequisites are met).

Stretched WLD (multi-AZ set):

• Story 9.1 — WLD network prep (per-AZ). Provision the per-WLD VLANs/subnets across both AZs (per-AZ networks) and the 5 mgmt-subnet IPs.
  • Acceptance: per-WLD VLANs/subnets provisioned across both AZs; the 5 mgmt-subnet IPs reserved; DNS in place.
• Story 9.2 — Prepare & commission the WLD hosts (both AZs). Image the WLD hosts in both AZs (see VCFHostPreparation); configure the per-AZ management networks, DNS, NTP; then commission them into SDDC Manager.
  • Acceptance: WLD hosts in both AZs reachable, matched ESXi build, commissioned in SDDC Manager.
• Story 9.3 — Deploy the WLD. vCenter + NSX (shared or dedicated) + first cluster. Optionally build the domain spec with VCFJsonSpecCreators (New-VCFWorkloadDomain.ps1; New-VCFNetworkPool.ps1 for the domain’s network pool, New-VCFClusterSpec.ps1 to add further clusters), which validates each payload against SDDC Manager before submit.
  • Acceptance: WLD deployed; its vCenter + NSX healthy; first cluster online in SDDC Manager.
• Story 9.4 — WLD witness. Deploy a dedicated vSAN witness for this WLD at the third site. A witness serves only one stretched cluster, so each stretched WLD needs its own, separate from the management witness (the shared-witness feature is 2-node-cluster only, not stretched). Route it to both AZ ESX-management networks. Ref: Deploying a Witness Appliance.
  • Acceptance: dedicated WLD witness deployed at the third site and reachable from both AZ ESX-management networks.
• Story 9.5 — Stretch the WLD cluster. Same as the management stretch — SDDC Manager stretches it for you from a JSON spec via the API: it builds the fault domains, balances the per-AZ hosts, and sets the site-mirroring storage policy. Supply the AZ2 network pool, the commissioned WLD hosts (equal per AZ), and this WLD’s witness. The management domain must already be stretched (E7) before any workload-domain cluster can be stretched. Edge stretched only under NSX Centralized connectivity. Optionally build the spec with VCFJsonSpecCreators’s New-VCFvSANStretchSpec.ps1 (set networkProfiles[].isDefault = false for a workload domain — true is the management domain). Ref: Broadcom — Stretching vSAN Clusters.
  • Acceptance: SDDC Manager reports the WLD stretched; vSAN healthy and storage-policy compliant (site mirroring); isolating one AZ keeps VMs running on the surviving site.
• Story 9.6 — WLD connectivity (Centralized / Distributed). As story 9.4 above, for this stretched WLD: build north-south per its own connectivity model (H4), and with Supervisor enabled it is the activation prerequisite (plus the Supervisor CIDRs / IP blocks).
  • Acceptance: WLD healthy in SDDC Manager; north-south reachable; workloads can be placed (and, with Supervisor, its connectivity prerequisites are met).

Final epic (always last)

E10 — Validation & handover · Owner: Architect + all teams

A core epic that always runs after E6 and any variant epics (stretch / Day-2 / workload domains) — it validates and hands over the complete environment.

• Story 10.1 — Health check. Run a post-deploy health check of the live environment.
  • Acceptance: post-deploy health check run; no critical findings (or all triaged).
• Story 10.2 — As-built. Capture the as-built (FQDNs, IPs, VLANs, passwords in the secret store).
  • Acceptance: as-built captured — FQDNs, IPs, VLANs recorded; passwords stored in the secret store.
• Story 10.3 — Handover. Walk the operations team through the platform and hand over.
  • Acceptance: health check clean; as-built delivered; operations sign-off received.

Using this in your backlog

• Treat E1–E10 as epics, the Story lines as stories, and the bullets under them as tasks; carry the Acceptance line into the story’s acceptance criteria.
• Add the stretch (E7) / Day-2 (E8) blocks and one E9 per workload domain you need (see the scope table up top); order runs core → management stretch → Day-2 → workload domains → handover.
• Sequence is roughly top-to-bottom; E1–E3 are planning (parallelisable across role teams), E4 is the readiness gate (must be all-green before bring-up), E5 onward is the build.
• This page is generic — replace the linked detail pages’ placeholder values with your real plan during E2/E3.