From time to time, you will need to upgrade Glasswall Halo to stay up to date with the latest fixes, features, and releases.

## Upgrading Glasswall Halo

### 1. Set the default Kubernetes namespace

Ensure your current Kubernetes context is set to the `cdrplatform` namespace:

```bash
kubectl config set-context --current --namespace=cdrplatform
```

### 2. Identify the latest image and chart versions

Use the Azure CLI to list available image tags in the Glasswall Artifact Registry:

```bash
az acr repository show-tags   --repository <repository>   --name glasswallhub   --username "${token_ID}"   --password "${token}"   --orderby time_desc
```

Replace `<repository>` with the appropriate image repository name.

### 3. Authenticate to the Helm registry

Log in to the Glasswall Helm registry using your credentials:

```bash
helm registry login glasswallhub.azurecr.io   --username "${token_ID}"   --password "${token}"
```

### 4. Pull the latest Helm chart

Download and extract the required Helm chart version:

```bash
helm pull oci://glasswallhub.azurecr.io/helm/<repository>   --version "${version}"   --untar   --untardir .
```

Replace `<repository>` with the chart repository name and `${version}` with the desired chart version.

### 5. Upgrade the Helm release

Run the Helm upgrade command using the required image tag and repository:

```bash
helm upgrade --install <chart-name> <chart-name>   --set image.tag=<tag>   --set image.repository=glasswallhub.azurecr.io/<repository>
```

Replace the placeholders with the appropriate chart name, image tag, and repository.

**Note:**  always review the release notes before upgrading to ensure compatibility and to understand any breaking changes.

## After upgrading: historical data and reporting

Reporting data shown in the portal (processed-file history, risk reports, ICAP reports) is stored in **MongoDB**, while files in flight are held on the persistent volume. An upgrade migrates the platform services; it does not by itself move or reprocess historical reporting records.

Set expectations accordingly after an upgrade:

- **Historical records remain in MongoDB.** The portal reads reporting data through the `cdrplatform-metrics-projection` service. If historical files are not visible immediately after an upgrade, confirm that MongoDB and the metrics-projection service are running and have completed reconciliation before assuming data loss.
- **Schema or projection changes** between distant versions can mean that records created on the old version are reprojected before they reappear in the portal. Allow time for this to complete.
- **Large version jumps** (for example, upgrading across several minor versions at once) are higher risk. Where possible, upgrade incrementally and review the release notes for each intervening version for data-migration notes.

If historical records are still not visible after the platform is healthy and reconciliation has completed, do not delete or recreate volumes—contact [Glasswall Support](https://www.glasswall.com/support) with your source and target versions so the migration can be investigated.