VCF Upgrade Failure: Cannot Upgrade VCF 5.2.2 to 9.0.1 or 9.0.2 Due to NSX Back-in-Time Error (NSX 4.2.3.3)
search cancel

VCF Upgrade Failure: Cannot Upgrade VCF 5.2.2 to 9.0.1 or 9.0.2 Due to NSX Back-in-Time Error (NSX 4.2.3.3)

book

Article ID: 430825

calendar_today

Updated On:

Products

VMware SDDC Manager / VCF Installer VMware Cloud Foundation

Issue/Introduction

  • When attempting to upgrade VMware Cloud Foundation (VCF) from version 5.2.2 to 9.0.1 or 9.0.2, the NSX upgrade pre-checks fail. In VCF Operations, when selecting the Target Version as 9.0.1.0 or 9.0.2.0, the Next button is greyed out.

  • You will see the following error message preventing the upgrade 
    You cannot select this target version for the following reasons. Select a different target version to proceed.
Cannot upgrade to VCF version 9.0.1.0 for domain [Domain-ID] in a compatible way: not upgradable: NSX_T_MANAGER 4.2.3.3.0.25171318 -> NSX_T_MANAGER 9.0.1.0.24952111; not interoperable: . If you have Standalone Host(s), please follow https://knowledge.broadcom.com/external/article?articleNumber=384976 to upgrade/patch them out of band through vCenter Server."

     

    Cannot upgrade to VCF version 9.0.2.0 for domain [Domain ID] in a compatible way: not upgradable: NSX_T_MANAGER 4.2.3.3.0.25171318 -> NSX_T_MANAGER 9.0.2.0.25150386; not interoperable: . If you have Standalone Host(s), please follow https://knowledge.broadcom.com/external/article?articleNumber=384976 to upgrade/patch them out of band through vCenter Server.

     

  • This issue typically occurs in environments where a brownfield vSphere 8.x vCenter (without an existing NSX deployment) was recently imported/converted into VCF 5.2.2. During this onboarding process, NSX 4.2.3.3 is deployed as the default available option.

Environment

  • Source: VMware Cloud Foundation (VCF) 5.2.2
  • Target: VMware Cloud Foundation (VCF) 9.0.1/9.0.2
  • Current NSX Version: VMware NSX 4.2.3.3
  • Target NSX Version: VMware NSX 9.0.1.0/9.0.2.0

Cause

This failure is caused by a "Back-in-Time" upgrade restriction. By design, VMware does not support upgrading a newer software build to an older software build, even if the major version number (9.x vs 4.x) suggests an upward trajectory.

         VMware NSX 9.0.2.0: Released January 20, 2026 (Build 25150912)

Because NSX 4.2.3.3 was released after the VCF 9.0.1/9.0.2 bundle (and specifically the NSX 9.0.1.0/9.0.2.0 build), the system flags this as an unsupported back-in-time operation and blocks the upgrade path.

Resolution

You have two options to resolve this blocker. Option 1 is the least disruptive, while Option 2 provides a workaround if an immediate upgrade to VCF 9.0.1/9.0.2 is required.

Option 1: Wait for the Next VCF Release (Recommended)

If there is no strict business deadline to upgrade to 9.0.1/9.0.2, the safest path is to wait for the next VCF release. The NSX version bundled with the next VCF release will have a newer build date than NSX 4.2.3.3, allowing for a standard, supported upgrade path.

 

Option 2: Un-prepare NSX, Remove Domain, and Redeploy (Workaround)

If you must upgrade to VCF 9.0.1/9.0.2 immediately, you can unprepare the vCenter clusters for NSX, remove the domain from the SDDC Manager inventory, and re-import the vCenter using a custom, compatible NSX version.

Please check the interoperability matrix here for the compatible VMware NSX Versions for VMware vCenter versions. 

Please check the upgrade compatibility matrix here for VMware NSX if upgrade is planned after the Brownfield import.

 

Follow the steps below to perform the workaround:

  1. Gather Required IDs
    1. Open the SDDC Manager UI.
    2. Navigate to Inventory > Workload Domains and select your target domain.
    3. Note the Domain ID from the browser URL.



    4. Go to the Services tab and record the exact FQDNs for both your vCenter and NSX Manager.

  2. Un-prepare vCenter Clusters

    1. Log in to the NSX Manager UI.
    2. Navigate to System > Fabric > Hosts.
    3. Under the Clusters tab, select the clusters associated with the specified vCenter.
    4. Click Remove NSX and confirm the prompt. Wait for the uninstallation to complete (hosts will show as Not Configured).

      Note: You may need to put the host(s) in Maintenance mode. 

       

    5. Log in to the vSphere Client UI.
    6. Navigate to Cluster > Updates > Hosts > Image > Check Compliance. Remediate the cluster if it shows as non-compliant.

  3. Remove Compute Manager and Delete NSX VMs

    1. In the NSX Manager UI, navigate to System > Fabric > Compute Managers.
    2. Click the three vertical dots next to the target vCenter's compute manager and select Delete.



    3. Log in to the vCenter UI.
    4. Locate the NSX Manager VM(s), right-click, and select Power > Power Off.
    5. Once powered off, right-click the NSX Manager VM(s) and select Delete from Disk.

  4. Clean Up SDDC Manager Inventory via API:

    You must clear the NSX cluster, hosts, and domain from the SDDC Manager database.

    1. Remove NSX-T Cluster for the Domain (Note: Only run this if the NSX Manager is used exclusively by this domain.) 
      curl -i -X DELETE http://localhost/inventory/extensions/vi/nsxtclusterdomains/<domain-id from Step 1(c)>
    2. Remove hosts for the domain

      1. Generate API Token 
        TOKEN=$(curl -H 'Content-Type:application/json' https://localhost/v1/tokens -d '{"username" : "<SSO_USERNAME>","password":"<SSO_Password>"}' -k | jq -r '.accessToken')

         

      2. Retrieve and Note Host IDs 
        curl -k -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -X GET https://localhost/v1/hosts?domainId=<domain-id from Step 1(c)> | json_pp

        Sample output

        Alternatively, go to SDDC Manager UI > Inventory > Hosts, select the hosts, and note their IDs from the URL.



      3. Create a file named ESXiIds.json on the SDDC Manager appliance containing the host IDs: 
        [
  {
    "id": "<ID of the host from step#4(b)(ii)>"
  },
  {
    "id": "<ID of the host from step#4(b)(ii)>"
  },
  {
    "id": "<ID of the host from step#4(b)(ii)>"
  },
  {
    "id": "<ID of the host from step#4(b)(ii)>"  
  }
]

         

      4. Execute the decommission trigger: 
        curl -s -X DELETE http://localhost/inventory/extensions/decommission/hosts -H "Content-Type: application/json" -d @ESXiIds.json
      5. Delete the Domain 
        curl -s -X DELETE http://localhost/inventory/extensions/vi/domains/<domain-id from Step 1(c)>


  5. Clean Up vCenter MOB and Re-import

    1. Navigate to https://<vCenter-FQDN>/mob and log in with vCenter administrator credentials. 

      Note: If vCenter MOB is disabled the follow KB 401669 to enable it.

    2. Click Content > ExtensionManager.
    3. Under the Properties section, verify that extensionList ["com.vmware.sddcManager"] is present in the VALUE column.



    4. Scroll to the Methods section and click UnregisterExtension.
    5. Enter com.vmware.sddcManager in the parameters value box.



    6. Click Invoke Method in the bottom right corner. Close the pop-up and refresh the ExtensionManager page to ensure it is removed.
    7. Follow the steps in KB 429205 to update SDDC Manager application configs for deploying a custom NSX version during import.
    8. Retry the vCenter Import/Convert process in VCF Operations using an NSX version that supports a forward upgrade to 9.0.1/9.0.2.
Powered by Wolken Software