Inventorying the Legacy Estate: Decide What to Migrate, Retain, or Retire

Exporting the VM Apps deployment list quickly produces a reassuring spreadsheet. Yet that spreadsheet does not say who depends on webshop-db-01, which team may approve an outage, or whether the certificate, license, and backup process will survive a rebuild. A resource inventory is not yet a migration plan.

The right unit of decision is the application service. This article joins the VCF Automation view with network, data, identity, and operations dependencies, then places every service into one of five strategies. The deliverable is not “migrate everything.” It is 100% of services carrying a justified decision, visible blockers, and a verifiable wave.

TL;DR

• Decision: inventory the complete service contract, then assign retain, retire, rebuild, repackage, or modernize to every application.
• The costly trade-off: an average score hides critical dependencies; one red data or rollback gate must block the wave.
• Monday morning: export objects read-only, name an owner for each service, and run a dependency workshop with Network, IAM, Backup, and Operations.

A VM is not a migration unit

WebShop looks simple in the portal: three VMs created from one Cloud Template. To its consumer, however, the service includes an endpoint, a business transaction, a PostgreSQL database, identities, certificates, network rules, a load balancer, backups, alerts, and several automation objects.

Original diagram: the register joins the platform graph to the application graph.

A wave does not succeed because webshop-web-01 boots in All Apps. It succeeds when the expected endpoint works, the reference transaction completes, data is consistent, on-call receives an actionable alert, and a reverse path remains available for the agreed window.

Build that view by joining two graphs:

1. Platform graph — organization, project, catalog item, template version, deployment, resources, Day‑2 actions, and technical owner.
2. Application graph — service, components, flows, data, identities, external systems, teams, and recovery objectives.

The register should retain source and target identifiers. Names alone are not enough: webshop-prod can identify a catalog item, deployment, CMDB record, or business service even though those objects do not share a lifecycle.

Extract four truths without changing the source

Discovery starts with read-only collection. From VCF Automation, gather organizations, projects, members, cloud accounts, zones, mappings, Blueprints or Cloud Templates, versions, catalog items, Custom Forms, deployments, leases, policies, subscriptions, Orchestrator workflows, ABX actions, and Custom Resources. For each object, record at least its ID, scope, version, owner, last observed use, dependencies, and export timestamp.

The platform view must be checked against three other sources:

Source	What it contributes	Common blind spot
VCF Automation	managed objects, template, owner, lifecycle	off-platform calls and business data
vCenter/NSX	placement, NICs, segments, rules, traffic	business intent and catalog contract
CMDB, monitoring, backup	ownership, health, restore coverage	drift or stale records
application workshop	dependencies, windows, tolerance	technical IDs and actually active flows

Do not resolve a discrepancy by averaging sources. If NSX observes a flow the owner does not recognize, that flow becomes an investigation. If the CMDB assigns the service to a team that no longer exists, the application has no reliable owner and cannot enter the pilot.

Do not store passwords, tokens, or private keys in this register. Record the vault reference and rotation owner. Migration is an opportunity to recreate secrets and avoid carrying a historical identity into the target.

Define the WebShop contract before designing the target

The contract states what must remain true regardless of deployment mechanism. This example is deliberately specific about names and cautious about results:

service_contract:
  id: webshop-prod
  consumer_endpoint: webshop.corp.example
  business_owner_role: ecommerce-owner
  functional_checks:
    - GET /healthz returns 200
    - GET /readyz returns 200 when dependencies are ready
    - reference checkout transaction succeeds
  data:
    technology: PostgreSQL
    rpo: required-before-wave
    rto: required-before-wave
    reconciliation: required-before-wave
  operations:
    monitoring_owner: platform-observability
    backup_owner: data-protection
    incident_route: ecommerce-on-call
  security:
    flow_review: required-before-wave
    identity_rotation: required-before-cutover
  evidence_status: design-example
  execution_status: not-executed

The /healthz and /readyz paths need different semantics: the first proves that the process is alive; the second succeeds only when required dependencies are ready. Add a representative business transaction because an HTTP 200 on the home page validates neither database writes, identity, nor calls to an external service.

The contract later becomes the cutover parity matrix. Even when the target uses another Blueprint and new IDs, it must satisfy the same behavior unless the program has explicitly approved a functional modernization.

Assign one of five decisions

The portfolio does not need to reach 100% migrated. It needs to reach 100% governed decisions. A retain application with a durable destination and review date is healthier than an application marked “to migrate” that has had no owner for six months.

Use gates, never a reassuring average

An 82% score can hide a complete lack of reverse path for the database. Truly blocking criteria must stay individually visible:

Gate	Green	Amber	Blocking red
Owner	available decision-maker	named interim	unknown
Dependencies	mapped and testable	minor gaps open	unknown critical flow
Image/runtime	supported, boot tested	adaptation defined	unsupported
Data	transfer and return tested	method not rehearsed	no reverse path
Network	flows and DNS/LB approved	governed temporary rule	impossible dependency
Identity	groups, accounts, certificates managed	rotation planned	uncontrolled secret
Extensions	target mapping tested	substantial rework	irreplaceable dependency
License	dual run/rehost permitted	legal review open	prohibited use
Rollback	trigger, authority, sequence exercised	exercise scheduled	no path

One critical red gate blocks the wave, even if every other row is green. An amber gate has an owner and due date; it does not turn green merely because the committee wants to preserve the schedule.

For the webshop-web-nonprod pilot, the absence of business data reduces risk, but the service still needs to be representative: VPC, identity, catalog, monitoring, a Day‑2 action, and delete should all be exercised. A “hello world” validates access to the platform, not its operating model.

Classify automation objects separately

The application decision does not say how every VCF Automation artifact should be treated. Add a separate disposition:

Treatment	Use	WebShop example
reuse under conditions	underlying object retained, new allocation	Content Library validated for target use
export, adapt, import	portable source, dependencies rebound	Cloud Template logic rewritten
recreate	target scope or ID differs	project, policies, rotated secrets
retain then drain	active object remains managed by VM Apps	deployment webshop-prod-042
archive only	historical evidence, no target object	old approval history

Do not promise that export means semantic portability. VM Apps and All Apps expose different resource models. A form can be transportable as a file while it still relies on an action, ID, or endpoint that must be recreated and rebound.

Build waves around evidence

A reasonable sequence for the study is:

1. Wave 0 — foundation: Region, organization, project, Namespace, VPC, images, identity, and policies; no business workload.
2. Wave 1 — pilot: stateless non-production WebShop; create, functional, Day‑2, observability, delete, and rollback checks.
3. Wave 2 — production stateless: Web and App tiers in All Apps, database still legacy, governed temporary flow.
4. Wave 3 — data: target database, replication, reconciliation, and an exercised reverse path before cutover.
5. Wave 4 — tail: remaining eligible services, retirements, and formal exceptions.
6. Wave 5 — exit: drain, observed deactivation, then VM Apps retirement once accepted dependencies reach zero.

Every wave has entry and exit conditions, a change owner, and a rollback authority. The source stays operable until business acceptance and closure of the reverse window. This controlled strangler pattern avoids coupling platform reconstruction, data migration, and functional modernization in one big bang.

Assess App Stack Formation separately

All Apps eligibility and App Stack Formation eligibility are different questions. An application can be rebuilt in All Apps even when its Namespace cannot be captured as a Stateful Blueprint.

For a possible later capture, record the self-service Namespace, VM Group, project Content Library, hard-coded addresses or hostnames, startup and shutdown order, and data consistency requirements. The VCF Automation 9.1 documentation for Working with Stateful Blueprints also describes capture blockers, including VKS, an Avi Load Balancer, or vSphere Pods in the Namespace. Revalidate that list against the target build before preflight.

An App Stack blocker must not turn the entire application red in the main register. It closes one packaging method; it does not prove that an All Apps migration is impossible.

Pitfalls & things to watch

• Keep pagination, role, and timestamp with every export; a UI/API discrepancy can be a visibility-scope issue.
• Version decisions instead of overwriting their history.
• Treat unknown as a blocking question, never as proof that a dependency is absent.
• Follow relationships by ID when a template looks unused but still has deployments.
• Allow no mass deletion during discovery.

Official sources

• Broadcom TechDocs — Bimodal Consumption Design for VM Apps and All Apps Workloads
• Broadcom TechDocs — Understanding the All Apps Organization Multi-Tenancy Model
• Broadcom TechDocs — Working with Stateful Blueprints
• Broadcom TechDocs — Import or Export a Stateful Blueprint

Conclusion

A useful inventory does more than count objects: it connects a service, its evidence, and a decision. WebShop becomes eligible when its dependencies are known, its owner accepts the contract, every critical gate is green, and the wave has a demonstrable reverse path. Until then, the honest status remains blocked or not executed.

The next step can rebuild Cloud Templates, Custom Forms, and extensions in the All Apps model.