> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes.
> xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal.
> Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can.
> Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames.
> Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing.

# Upgrading to Version 11.0.X

> Upgrade xorlab across major and minor releases, including the configuration files to review for each release.

xorlab follows semantic versioning using the `Major.Minor.Patch` format. For example, `X.Y.2` means patch no. 2 to minor release Y of major version X of the software.

<Warning>
  **Prerequisites**

  * Read the [Changelog](/changelog) to see the list of all changes.
  * Have a recent backup available, see [Manual backup](/latest/backup-recovery#manual-backup) and [Patch rollback](/latest/backup-recovery#patch-rollback).
</Warning>

xorlab follows semantic versioning using the `Major.Minor.Patch` format. To apply only a patch increment, see [Upgrading to a Patch Release](/latest/patch-upgrade) instead.

<Warning>
  **Wait for Release Announcement**

  Releases are always rolled out gradually to SaaS customers first and are closely monitored for any unexpected issues. For xorlab on-prem, please wait to upgrade until the release has been officially announced via email.
</Warning>

## Release support lifecycle

xorlab follows a time-based release support lifecycle. Each major release is supported for 9 months after its initial public release. Customers are expected to upgrade xorlab at least twice per year to remain within a supported release.

Please refer to the [Release Lifecycle Support](/latest/release-lifecycle-support) page to verify support timelines and end-of-support dates.

## Reading the changelog

Before starting with the upgrade, read through the most important parts of the Changelog:

1. Read the [Highlights](/changelog#highlights)

2. Read the [Breaking Changes](/changelog#breaking-changes)

## Upgrade xorlab

To upgrade xorlab, run the following command as the `admin` user on all xorlab hosts in the provided order:

```shell theme={null}
# Replace X.Y.Z with the version number you would like to upgrade to, e.g. 11.0.2
xorlab-upgrade X.Y.Z
```

Upgrade order:

1. Sandbox (only applicable for on-prem DANA appliances)
2. XCC
3. MTA

After you ran the command on all hosts, the upgrade is finished. You can use `docker ps` on each host to verify that the new version is running.

## Post-upgrade check

After the upgrade, review the migration logs for any warnings or errors that may occur. To do this, use the following link (be sure to replace `<xcc_domain:xcc.customer.tld>` with your actual XCC domain in the browser):

```html theme={null}
https://<xcc_domain:xcc.customer.tld>/monitoring/explore?panes=%7B%22ZU4%22:%7B%22datasource%22:%22loki_monitoring_cbef60b6%22,%22queries%22:%5B%7B%22refId%22:%22A%22,%22expr%22:%22%7Blevel%3D~%5C%22WARN%7CERROR%5C%22,%20container_name%3D%5C%22xcc_backend%5C%22%7D%20%7C%3D%20%60MigrationLogger%60%22,%22queryType%22:%22range%22,%22datasource%22:%7B%22type%22:%22loki%22,%22uid%22:%22loki_monitoring_cbef60b6%22%7D,%22editorMode%22:%22builder%22%7D%5D,%22range%22:%7B%22from%22:%22now-24h%22,%22to%22:%22now%22%7D%7D%7D&schemaVersion=1&orgId=1
```

## New features configuration

After upgrading, review the documentation pages below for the new features introduced in this release and apply configurations as needed.

* The SSQ now supports archiving emails. By default, all SSQ users get access to this functionality. However, if you use custom roles, make sure to add the permission `xcc_quarantine_archive` to any role that should have access to this feature.

* By default, all analyst users have access to the retrospective email scanning feature. If you use custom roles, add the `xcc_mail_import_read` permission to let users view the status of import jobs, or `xcc_mail_import_update` to let them manage import jobs.

## Troubleshooting

If you experience issues or have questions, refer to the support documentation or contact our support team at [support@xorlab.com](mailto:support@xorlab.com).