> 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.15/onboard-cortex-xsoar/elasticsearch/migration/validate-the-migration-to-elasticsearch.md). # Validate the Migration to Elasticsearch Validate a Cortex XSOAR 6.15 migration to Elasticsearch and identify incomplete or failed migrated objects. After completing the migration process, you should verify that the migration completed successfully. Part of this validation should be done before you start the system, and part can only be done once you start the system. 1. After completing the migration, navigate to the directory in which your logs are stored. By default, this is `/var/log/demisto`. 2. Open the `elastic.migration.log` file. 3. Review the summary at the end of each object migration.

To view the migration results in a user-friendly format, run the migration with previous-results the flag.

The following example shows that all 14725 objects in the tenant's main database migrated successfully: `info === file /var/lib/demisto/tenants/acc_/data/demisto.db migrated 14725 out of 14725 objects in 6.311s` If an object fails to migrate, the summary resembles the following example: `info successfully migrated: insight: 3024 | 1 failed to migrate, took 1.884s` If you receive this error, contact your support representative. 4. (Optional) Review objects larger than 100 MB that the migration skipped. By default, the migration tool skips these objects. The migration summary lists each skipped large object. Determine whether each object is still required. To migrate a required object, run the migration tool again. Set the `object-max-size` flag to a higher limit. Include the `retry-large-objects` flag. The `retry-large-objects` flag migrates the entire bucket again. It includes items that may already have migrated. If data was added in Elasticsearch after the earlier migration, the migration overwrites that data. `sudo ./elasticMigrator -config-path /usr/local/dev/copy_of_demisto.conf -db-path /usr/local/dev/lib_demisto_copy/data -object-max-size 200 -retry-large-objects` 5. (Optional) If using Kibana, validate the migration in Kibana. Verify cluster status is green and verify Cortex XSOAR indices are green. 6. Query the Elasticsearch API to verify incident ID offset, cluster health, number of shards, etc. | Example | Description | | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `curl -k -u username:password https://readyxsoarone:9200/dmst-common-incidentidtrack/_doc/thisistheid` | Retrieves the Incident ID offset, which should match the latest Incident ID in your system prior to the migration. The ID is in the ‘offset’ key, and it is critical that this ID be equal to the ID of the last Incident in the Bolt database. If data was not migrated in the correct order, the ID will not be equal. Do not restart the Cortex XSOAR server if it is not equal. | | `curl -k -u username:password https://readyxsoarone:9200/_cluster/health` | Get cluster health | | `curl -k -u username:password https://readyxsoarone:9200/_cat/indices` | GET XSOAR indices | | `curl -k -u username:password https://readyxsoarone:9200/_cat/indices?h=health,status,indices` | GET only the health, status, and index | 7. If no errors were found, start the Cortex XSOAR server. 8. Perform a basic sanity check on your system. For example, ensure that your content and incidents were migrated. 9. In the event that there are any errors when starting the server, or if you see that data was not migrated, contact your support representative. --- # 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 following URL with the `ask` and `goal` query parameters: ``` GET https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.15/onboard-cortex-xsoar/elasticsearch/migration/validate-the-migration-to-elasticsearch.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. 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.