Skip to main content
Use your production Tensor9 account and a CLI whose tensor9 adapt cloud upgrade --help lists these options.
An upgrade changes the software serving an existing installation while retaining its infrastructure state. Keep the installation directory: it identifies the installation, its saved configuration, and any upgrade that needs to finish.

​
Prepare the installation

Use the original installation directory and cloud identity authorized to manage that installation. Keep its saved state and private configuration available. The directory supplies the hosting cloud, placement, installed service configuration and installation identity. Authenticate to the original Tensor9 Account using T9_API_KEY or an imported account profile. GCP uses your original customer Application Default Credentials or a credential file supplied with --gcpCredentials FILE. Azure uses the original customer’s az login identity. The command checks the current signed license’s term and coverage; it does not issue another license automatically. Choose a maintenance window appropriate to your application. Retaining resources does not establish uninterrupted request serving. Run a representative set of your application’s SDK requests before the upgrade so you can compare their behavior afterward.

​
Review a verified release

Choose the exact release you intend to install and use the original installation directory:
This verifies the complete signed release and reviews the selected version without publishing images to your registry or applying a cloud upgrade. The output identifies the installation’s original release and the selected release. Record the selected release before applying it. The upgrade uses the installation’s retained configuration; arbitrary image and configuration overrides are not accepted.

​
Apply the selected release

Use the exact release you reviewed:
--autoApprove authorizes the installer to plan and apply the upgrade. During the upgrade, it checks saved infrastructure plans before applying them and refuses changes that would delete or replace protected installation resources. Resolve any refusal before retrying. A change that needs resource replacement requires a separate migration procedure; these checks do not replace your application’s data-migration planning. Keep the command running until the installed services have been checked and the private connection receipt has been updated in the installation directory.

​
Verify application behavior

After the installer completes, rerun your real SDK tests against the installation, including the operations, credentials, and data paths your application uses. Compare returned data and errors with your pre-upgrade results. The installer’s service checks and your application’s compatibility checks answer different questions.

​
Resume an incomplete upgrade

An upgrade can stop after applying only part of its changes. Preserve the original directory, resolve the reported problem, and retry the same command. The pending upgrade retains its exact selected artifact, including after an uncertain apply; a retry does not switch to the latest release. If a different CLI began the pending upgrade, use that original CLI or explicitly adopt the pending work with the current CLI’s protected plans:
Use the pending upgrade’s retained release for EXACT_RELEASE. Adoption does not bypass protected-resource checks. An unsuccessful upgrade does not promise automatic rollback of the cloud installation. Continue the recorded upgrade before treating the installation as fully upgraded.