Upgrade a customer-managed deployment

Plan the update as a complete release: infrastructure, services, database scripts, portals, SDK compatibility, and configuration.

Update components independently only when the release notes and validation evidence support that combination.

Upgrade process

Review the release inputs

Read the release notes and identify required changes to infrastructure, database scripts, configuration, and SDK versions. Review security findings and recovery conditions before scheduling the update.

Capture the current state

Record deployed versions, effective configuration, database version, proof provider, portal artifacts, and active incidents.

Protect recovery paths

Complete the backups and snapshots named by the runbook. Verify that required keys, storage artifacts, and protected ledger digests have an approved recovery path.

Test the release in a validation environment

Use the supplied infrastructure templates, service artifacts, database scripts, and portal build. Do not layer compatibility changes that are absent from the current release.

Validate the affected workflows

Use the release’s required checks for identity, authorization, ingest, policy, review, outcomes, exports, proof verification, background work, monitoring, and recovery. Keep results tied to the exact artifacts tested.

Promote the same candidate

Promote the same tested artifacts. Record environment-specific configuration separately and validate its identities, endpoints, and secret references in the target environment.

Monitor and close

Monitor errors, queues, database health, callbacks, and proof submission. Close the change only after the agreed observation period and evidence review.

Run the upgrade command (Private Enterprise)

For a Private Enterprise installation, Invoke-PrivateEnterpriseUpgrade.ps1 in the release’s installation folder runs the process above as five gated steps. It runs in your tenant with your Azure CLI or Azure PowerShell sign-in, and sends nothing to VeriProof.

Step	What it checks or does
`capture`	Inventories the managed resource group, records the installed release, workloads, and signing slots, and checks the move against the target release’s `upgrade-compatibility.json`
`backup`	Confirms PostgreSQL point-in-time restore and Key Vault purge protection, then takes a PostgreSQL on-demand backup and waits for it to finish
`validate`	Requires live readiness evidence from your validation environment for the same release and manifest, runs Azure Resource Manager validation and what-if, and fails on any planned deletion
`promote`	Deploys the validated template to the managed resource group in incremental mode and saves the new installation evidence
`observe`	Reconciles readiness for all five workloads, confirms which signing keys sign, takes a health summary, and waits out the observation period


pwsh ./installation/Invoke-PrivateEnterpriseUpgrade.ps1 `
  -SubscriptionId <subscription-id> `
  -ManagedResourceGroup <managed-resource-group> `
  -TargetReleaseId <release-id> `
  -TemplateFile ./mainTemplate.json `
  -TemplateParameterFile ./installation-parameters.json `
  -ValidationEvidencePath ./validation/runtime-readiness.json `
  -StateDirectory ./upgrade-<release-id> `
  -ObservationHours 24

Each step prints its checks and asks before it runs. A failed check stops the command. Fix the cause and run the same command again: it resumes at the first step that hasn’t passed and doesn’t repeat finished steps, so the backup and deployment run once. The step results, backup name, effective parameters, and readiness evidence stay in the state directory as your change record.

Add -WhatIf to run the read-only checks and stop before the backup.
Add -Confirm:$false to run without prompts from a pipeline. Failed checks still stop it.
If the observation period hasn’t passed, the command stops at observe and tells you when to run it again.

The command stops at capture when the target release doesn’t list your installed release as a supported source. Running the same release again is accepted as a reconciliation. The command needs Python 3 for the compatibility check; Azure Cloud Shell includes it.

The deployment carries the current signing slots forward, so an upgrade doesn’t undo a key rotation. See Key and secret management.

Export a health summary

Export-PrivateEnterpriseHealthSummary.ps1 writes a JSON summary for your own Azure Monitor or SIEM ingestion. It runs only when you call it, for example from your own scheduler, and sends nothing to VeriProof.


pwsh ./installation/Export-PrivateEnterpriseHealthSummary.ps1 `
  -InstallationEvidencePath ./installation-evidence.json `
  -OutputPath ./health/health-summary.json

The summary covers:

readiness and Azure availability for each workload;
queued messages and dead-letter arrivals;
the last successful run and recent failures of each background job;
signing key age, expiry, and the next rotation step;
whether every Key Vault reference on each Function app resolves, by setting name;
served and App Service certificate expiry;
PostgreSQL state, storage use, CPU, connections, and backup retention.

Each section reports ok, attention, or unavailable with the reason, so a missing permission on one resource doesn’t hide the rest. The summary reads metadata, counts, and timestamps only: no secret values, application data, or log record bodies.

Rollback

Use the release-specific rollback plan. Do not assume that a database script is reversible or that an older service can read a changed schema.

Stop before deployment if the release lacks an approved recovery plan for a critical change.

A successful build or Azure deployment does not confirm that customer workflows work. Use the recorded workflow and recovery results to accept the release.