VM Apps to All Apps: The Decision Framework Before Migration

The upgrade to VCF Automation 9.1 has just completed. Historical deployments are still running, teams are already discussing All Apps, and an apparently simple question reaches the architecture board: “How do we convert our VM Apps organization?” That is the wrong question. Public documentation describes coexistence followed by migration, not an automatic transformation of the existing organization.

This article provides a decision framework for a brownfield environment originating from Aria Automation 8.18.1 or later. It separates transition topology, the strategy for each service, and the conditions for retiring the legacy estate. The running example is WebShop, a three-tier application still operated in acme-vmapps-legacy and intended to be rebuilt in a separate All Apps organization.

TL;DR

• The upgrade preserves the historical model inside VM Apps; it does not turn its objects into All Apps objects. The target is a new organization with separate identities, projects, quotas, Namespaces, VPCs, and identifiers.
• The expensive part is not creating the target organization. It is rebuilding the service contract: networking, data, policies, extensibility, observability, and external dependencies.
• Start with a written decision on three axes—topology, application strategy, and exit—then choose a stateless pilot whose rollback is a traffic switch, not an organization deletion.

Replace the conversion question with three decisions

The lack of a public in-place conversion procedure does not prove that such an operation is technically impossible in every situation. It supports a more defensible engineering rule: never make the program depend on an undocumented mechanism. If a customer believes a conversion exists for its build and topology, obtain written GSS confirmation that states the exact object and support scope.

The decision pack must answer three independent questions. First, which infrastructure will host All Apps during coexistence? Second, what happens to every application service? Third, which evidence will authorize the catalog freeze, deactivation, and possible deletion of VM Apps? Combining these answers creates unsafe shortcuts, such as assuming separate clusters solve management-plane isolation or that a YAML export moves deployment state.

decision_record:
  evidence_status: reconstructed_design
  transition_topology: separate_clusters_shared_vcenter_nsx
  application_strategy:
    webshop: rebuild_in_all_apps
    legacy_batch: retire_after_usage_review
  retirement_condition:
    - no_new_vm_apps_requests
    - no_unaccepted_external_dependency
    - rollback_window_closed_by_owner
  in_place_conversion: excluded_without_written_gss_confirmation

This YAML is not a VCF Automation configuration. It is a versionable architecture contract: platform, network, security, operations, and application owners must approve each value.

Choose a transition topology, not only a destination

Broadcom’s 9.1 documentation describes a bimodal model where VM Apps and All Apps can share vCenter and NSX under Mixed Tenancy conditions. Sequence matters: VM Apps must be configured before the All Apps Region on the shared pair. The reverse sequence is documented as unsupported. Sharing is therefore a controlled bridge, not a capability to assume after the target already exists.

Option	When it makes sense	Structural cost or limitation
VM Apps only	short deferral with a review date	no All Apps adoption; legacy debt continues
same shared cluster	low-criticality pilot with available capacity	contention, common blast radius, non-strict isolation
separate clusters, common vCenter/NSX	enterprise transition with compute isolation	management-plane visibility and APIs remain shared
dedicated All Apps infrastructure	regulated production or strong security boundary	capacity, networking, and operations temporarily duplicated
dedicated VCF Instance or fleet	sovereign workloads or maximum separation	highest cost and operational complexity

A security test is mandatory before selecting Mixed Tenancy. Broadcom warns that read visibility of All Apps resources from VM Apps may exist and that the mode is unsuitable when production requires strict multi-tenancy. If that behavior conflicts with the threat model, the discussion is over: the target must be dedicated even when the preferred budget assumes sharing.

Capacity deserves the same honesty. Two clusters under the same vCenter and NSX reduce compute contention, but they do not remove pressure on APIs and the management plane. Record a baseline, define local thresholds, and reserve migration windows. Generic sizing numbers cannot replace those observations.

Migrate a service, not an isolated VM

For WebShop, the useful unit includes all three tiers, their flows, DNS resolution, the load balancer, machine accounts, IPAM reservations, CMDB configuration items, backup, monitoring, and application data. Moving a VM without that graph may produce a green object in the interface while leaving consumers with a broken service.

Assign each service an explicit strategy:

Strategy	Decision	WebShop example
retain	immediate change risk outweighs the benefit	keep the historical database during the first wave
retire	no continuing use can be demonstrated	archive and remove an old batch server after owner approval
rebuild	same function, new All Apps contract	redeploy the Web and App tiers in the target Namespace
repackage	an image or OVF/OVA becomes the starting point	move a difficult appliance without claiming its history transfers
modernize	the runtime or platform service also changes	move the database to DSM in a later wave

The running example recommends rebuild before modernize. Simultaneously changing tenancy, networking, runtime, and data engine multiplies the hypotheses to investigate during the return window. Modernization remains a valid outcome, but it deserves a separate wave after the service is reproducible in All Apps.

Measure portability across four dimensions

“We can export it” is not enough. For each object, distinguish source export, target import, semantic compatibility, and runtime-state transfer. An exportable Custom Form may still reference identifiers, external actions, and dynamic values that do not exist in the new organization. An importable Orchestrator package does not automatically carry endpoints, certificates, credentials, or previous workflow runs.

Object	Cautious default treatment
projects, groups, and roles	recreate, remap, and test with non-admin users
Cloud Templates containing Cloud.*	rebuild against the All Apps resource model
Custom Forms	export as an aid, rebind every dependency, then retest
subscriptions and policies	recreate using topics, payloads, scopes, and roles observed on the target
active deployments and history	retain and drain, or redeploy; no generic state transfer is documented
secrets, tokens, and credentials	recreate and rotate; never copy them from an export

Semantics are the decisive dimension. formatVersion: 1 alone does not identify a legacy Blueprint; the Cloud.* types, profiles, actions, and dependencies determine the rewrite. Likewise, sharing vCenter and NSX avoids moving parts of the infrastructure plane, but it does not convert a legacy segment into a VPC or a cloud zone into a Region Quota.

Design rollback before the pilot

Program rollback lives at the service level. Before cutover, the target can be corrected or removed without touching legacy WebShop. After the switch but before new writes, traffic can return to the source. After writes have reached the target, return requires a freeze, reverse replication, or a previously rehearsed restore.

That distinction determines the right pilot. A low-criticality stateless application with few extensions and a controlled DNS or load-balancer switch exposes tenancy problems without immediately adding an irreversible data migration. The pilot must exercise the complete lifecycle: provisioning, role checks, Day-2, failure, traffic return, and cleanup of external records.

What the decision board should receive

A useful meeting does not end with “All Apps is the destination.” It produces a source-and-target diagram, a topology decision, the expected visibility-test result, a capacity hypothesis, a service matrix, one owner per external dependency, and measurable exit conditions. It also names who can issue go/no-go and who can trigger rollback.

For WebShop, a reasonable first proposal is to retain the database in VM Apps while rebuilding the Web and App tiers in All Apps, then move data in a separate wave with a tested reverse path. This is not a product truth. It is a design hypothesis that limits simultaneous change.

Hidden costs belong in the same decision: duplicated capacity during blue-green, Supervisor and VPC networking, Content Library storage, two catalogs, new security rules, workflow and reporting changes, backup tests, training, and retention of two identifier sets. Without that budget line, “temporary” coexistence tends to become permanent.

Pitfalls & things to watch

• Do not create All Apps on a shared pair until you have verified the applicable Mixed Tenancy order.
• Do not allow VM Apps and All Apps to write the same DNS, IPAM, AD, CMDB, or load-balancer record during dual run.
• Do not publish an RPO, RTO, cost, or duration until it has been measured in the customer context.
• Do not delete VM Apps to reclaim infrastructure before the return window has been formally closed.

Official Broadcom sources

• Bimodal Consumption Design for VM Apps and All Apps Workloads
• Managing Regions in VCF Automation
• Create a VCF Automation Organization for All Applications
• Tenancy Deployment Models with VMware Cloud Foundation
• KB 443541 — Unable to Add a Cloud Account on Shared Infrastructure
• KB 444058 — Configuring a Shared vCenter and NSX Manager

Conclusion

A sustainable path is neither a big bang nor a promise of universal conversion. It stabilizes VM Apps, builds a separate target, migrates by service, proves rollback, and gradually retires the legacy estate. The next article establishes the post-upgrade VM Apps baseline before any All Apps construction begins.