> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.12/onboard-cortex-xsoar/onboarding-in-cortex-xsoar/high-availability/migrate-a-multi-tenant-deployment-for-high-availability.md). # Migrate a Multi-Tenant Deployment for High Availability To migrate a multi-tenant deployment from BoltDB to Elasticsearch with High Availability, there are two steps. First, you use the Cortex XSOAR migration tool to migrate the databases. Then you set up additional app servers to achieve high availability. {% hint style="info" %} ### Note In a multi-tenant, high availability configuration, if you purge an Elasticsearch-based environment, Cortex XSOAR's lib directory is not deleted unless you pass the purge-mount flag to the installer or you agree to delete the lib directory by not passing the --y flag during the purge process. {% endhint %} **Migration** The migration tool migrates Cortex XSOAR objects to an Elasticsearch database. When you run the migration tool, the contents of the Cortex XSOAR database are read, and a corresponding object is created in Elasticsearch. The migration tool is run from the main machine and each host machine. Migrate the main account on the main host, then the tenants on the main host, and then proceed to other hosts and tenant accounts. For complex environments with multiple host machines, we recommend migrating all tenants on a host before proceeding to the next host. {% hint style="info" %} ### Note You cannot run more than one migration tool process at a time. {% endhint %} When you run the migration tool, parameter values identified in the **`demisto.conf`** file override values supplied for tool flags and default values. If no value exists in the **`demisto.conf`** file, values supplied in the tool flags override default values, but do not write the values to the **`demisto.config`** file. For example, if the db-path is identified in the configuration file, the tool will use the value in that file, not the value supplied or the default value, when running the tool. If you are upgrading from Cortex XSOAR v6.0 and you have indicators and audits stored in Elasticsearch in Cortex XSOAR v6.0, upgrade from Cortex XSOAR v6.0 before the migration. Do NOT start the server. Then follow the migration instructions below. Before you begin, ensure the following: * All app servers have network access to port 9200 for communication with Elasticsearch. * All app servers have network access to each other over port 443. In the BoltDB, data related to incidents and indicators is stored by month in partitions. To minimize downtime during migration, we recommend creating a copy of the database and migrating data that is older than three months from the copied database. This enables you to continue to work in your current environment. When the initial migration completes, migrate the remaining months. 1. Copy the **`demisto.lic`** file from the **`/usr/local/demisto`** directory on the main host to the **`/var/lib/demisto`** directory. 2. Add the following entry in the **`demisto.conf`** file: **`license.file.path:"/var/lib/demisto"`** 3. Follow the [migration instructions](/xsoar-6-administrator-guide/6.12/onboard-cortex-xsoar/onboarding-in-cortex-xsoar/elasticsearch/migration/migrate-objects-to-elasticsearch-for-multi-tenant.md) for multi-tenant deployments. If you used Elasticsearch to store indicators and audits in Cortex XSOAR v6.0 prior to upgrade, ensure the **`demisto.conf`** file is up-to-date with the Elasticsearch object before migration. To avoid overwriting indicators that might already exist in Elasticsearch, you must run the migration with the **`-objects-to-ignore "newInsights"`** flag. If you already migrated audits in a previous version, you must run the migration with the **`-objects-to-ignore "newInsights, audits"`** flag. **Migration Tool Flags** | Flag | Type | Description | Required | | ---------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | **`accounts`** (multi-tenant only) | String | A comma-separated list of accounts to migrate. If not specified, all accounts are migrated. | Optional | | **`config-path`** | String | The path to the configuration file for the server. Default: /etc/demisto.conf. | Optional | | **`db-path`** | String | The path to the database directory. Default: /var/lib/demisto. | Optional | | **`elastic-batch-size`** | Integer | The number of indicators per batch to write to Elasticsearch indexes. Default: 700. | Optional | | **`elastic-index-prefix`** | String | The index prefix used in Elasticsearch. | Optional | | **`elastic-key`** | String | The API key to connect to Elasticsearch. | Required (unless a username and password are used) | | **`elastic-password`** | String | The password to connect to Elasticsearch. | Required (unless API key is used) | | **`elastic-url`** | String | The URL of your Elasticsearch environment. Default: . | Required | | **`elastic-username`** | String | The username to connect to Elasticsearch. | Required (unless API key is used) | | **`ignore-ids-path`** | String | The path to the file with the IDs to ignore, per object. | Optional | | **`log-level`** | String | The log level to display. Default: info. | Optional | | **`logfile`** | String | The location of the log file.Default: /var/log/demisto/elastic\_migration.log | Optional | | **`log-failed-items`** | Integer |

Log individual failed items, either in a single meta file, or file per item failure. Values:

0: Does not log failed items (default).

1: Logs failed items metadata in a single file.

2: Logs each failed item in an individual file under the log folder. For more information, see Troubleshoot Elasticsearch.

| Optional | | **`migrate-all`** | true | By default, the Elasticsearch tool checks existing indexes and migrates only the ones that are new. Using this flag, the Elasticsearch tool migrates all indexes even if they currently exist. This is useful, for example, if there was an error or invalid data that was fixed. When used, the objects-to-migrate and objects-to-ignore flags are ignored. | Optional | | **`objects-to-ignore`** | String | Comma-separated list of objects not to migrate. When the migrate-all flag is used, this flag is ignored. | Optional | | **`objects-to-migrate`** | String | Comma-separated list of objects to migrate. When the migrate-all flag is used, this flag is ignored. | Optional | | **`partitions`** | String | Comma-separated list of partitions to migrate. If no partitions are specified, all partitions are migrated. | Optional | | **`partitions-to-ignore`** | String | Comma-separated list of partitions to exclude. | Optional | | **`previous-results`** | | Show results of the previous migration. | Optional | | **`skip-existing-indicators`** | false | Existing indicators are not modified during the migration. | Optional | | **`object-max-size`** | Integer | The maximum size, in megabytes, of objects that will be migrated to Elasticsearch. The default is 100 MB. | | | **`retry-large-objects`** | Boolean | Retry the migration of large objects when re-running the migration tool. With this flag, the entire bucket that contains the skipped large object is migrated again, which may include data that was previously migrated. If new data has been added in Elasticsearch since the earlier migration, this data will be overwritten. | | | **`force-main`** | Boolean | When the partitions flag is used, the **`-force-main`** flag forces the migration of the main partition as well as the specific list of partitions. | | | **`partitions-back`** | Integer | Provides an option to migrate X number of partitions back. For example, migrating 3 partitions back migrates the current month and the previous two months. If set to 0 or not used, all partitions are migrated. | | | **`only-old-partitions`** | Boolean | Can only be used with the partitions-back flag. Migrates all partitions other than the most recent partitions specified with partitions-back. For example, **`-partitions-back 3 -only-old-partitions`** migrates all partitions besides the current month and the two previous months. Should be used within the same calendar month as the previous migration. | | | **`version`** | | Prints the migration tool version. | Optional | | **`y`** | false | Answers yes to all questions, unless there is an error. | Optional | **High Availability - Main Host** The main account cannot be High Availability if it has tenant accounts. Move any tenant accounts from the main host to another host before proceeding. 1. Edit the **`demisto.conf`** file to set the app server’s hostname: Under the Server object, set the value of the **`inClusterHostname`** parameter to the desired hostname. The hostname should be the internal address used for communication with the other app servers. 2. (Optional) [Apply a certificate](/xsoar-6-administrator-guide/6.12/onboard-cortex-xsoar/onboarding-in-cortex-xsoar/high-availability/use-a-signed-certificate.md). 3. (Optional) Install [additional app servers](/xsoar-6-administrator-guide/6.12/onboard-cortex-xsoar/onboarding-in-cortex-xsoar/high-availability/install-additional-app-servers.md). Verify that the clocks on the app servers are synchronized with an NTP server. **High Availability - Hosts** Add hosts to a HA group: {% hint style="info" %} ### Note All hosts in the HA Group must have the same hardware specifications. {% endhint %} 1. When working in a high availability configuration, you must mount **`/var/lib/demisto/`** on a shared file system, to allow application servers to share files such as license, artifacts, and attachments. When migrating an existing file system to a shared file system, move the **`/var/lib/demisto`** folder without the **`/var/lib/demisto/temp`** subdirectory to the shared directory. If you are using a location that is different from the default **`/var/lib/demisto`**, you must install the additional hosts using the **`-data-dir`** flag. For the existing host, follow instructions to [Move Data Folders to Another Location on the Server](/xsoar-6-administrator-guide/6.12/configure-cortex-xsoar/customize-and-configure-cortex-xsoar/manage-data/move-data-folders-to-another-location-on-the-server.md). 2. The **`temp`** directory must be local and not shared. To change the location of the **`temp`** directory, edit the **`folders.temp`** key in the **`demisto.conf`** file for the host and also edit the **`folders.temp`** key for each tenant on each host. The tenant conf file can be found at **`/usr/local/demisto/tenants/acc_{`*****`tenant_name`*****`}/server.conf`**. 3. In the Main host, navigate to the Hosts page, under Settings → **Account Management**. A list of all of the hosts, including those you have migrated, will be displayed. 4. Select the Host for which you want to create an HA group and click **Make Host Highly Available**. 5. In the window that appears, click **Download Host Installer**. 6. Use this dedicated installer for installing additional hosts to this HA group. The new hosts will automatically be configured to connect to the relevant Elasticsearch index. **Purge an Elasticsearch Environment** In an multi-tenant, high availability configuration, if you purge an Elasticsearch-based environment, Cortex XSOAR's lib directory is not deleted unless you pass the **`purge-mount`** flag to the installer or you agree to delete the lib directory by not passing the **`--y`** flag during the purge process. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.12/onboard-cortex-xsoar/onboarding-in-cortex-xsoar/high-availability/migrate-a-multi-tenant-deployment-for-high-availability.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.