Upgrade the Workload API¶

Back up and restore¶

Workload API state lives in MongoDB, so the standard database backup and restore already covers workloads. Running workloads are Long Running Services (LRS); for LRS-specific options—including restoring by rehydrating workloads from MongoDB—see Back up long running services.

Migrate Workload API data from the admin database¶

This migration is rarely needed. It applies only if you used the Workload API during its Private Preview (in 11.9 or 11.10), are now upgrading to a later version, and run external PCS with a full MONGODB_URI override whose connection string targeted the admin database. In that case, Workload API data (workloads, protons, artifacts, and related collections) accumulated in admin, and this one-off Helm job relocates it to the correct database:

workload-api:
  component:
    mongo:
      migrateFromAdmin:
        enabled: true   # run with dryRun: true first; disable again afterward

The job is detection-first and insert-only (idempotent), so re-running is safe. Leave component.mongo.jobsAppendTimestampSuffix at its default (false) so the job name stays deterministic—enabling it appends a timestamp so each apply spawns a new job, which is only useful for repeated CI runs in one environment. If your installation isn't affected, leave the migration disabled. For where this fits in the overall upgrade, see Upgrade from 11.x to the latest version.