Migrate the analytics data

You must perform this operation on the new API Gateway instance. For a cluster setup, you must do this on each node.

Note: If the analytics data volume is high, migrate only the core data using the APIs provided earlier, and migrate the analytics data using the backup and restore command.

The steps to migrate the analytics data using backup and restore command is as follows:

Take a backup of the analytics data from the source API Gateway instance using the following command:
```
<SOURCE>\IntegrationServer\instances\default\packages\WmAPIGateway\cli\bin\apigatewayUtil
create backup -include analytics -name <backup_file_name>
```
For more information on taking backup, see Creating API Data Store Backup.
Copy the backup file to the target API Gateway instance path.repo folder configured under <TARGET>\IntegrationServer\InternalDataStore\config\elasticsearch.yml.

Restore the backup data in the target API Gateway instance using the following command:

<TARGET>\IntegrationServer\instances\default\packages\WmAPIGateway\cli\bin\apigatewayUtil 
restore backup -include analytics -name <backup_file_name>.

For more information on restoring backup, see Restoring Data Store Backup.

Ignore the following step if you have chosen to migrate the analytics data using the backup and restore command.

Once you complete the quiesce mode for all in the old API Gateway instance, the analytics data can be migrated to the new instance. You can invoke the following request in the new API Gateway instance to migrate the data.

The source tenant name is assumed as default. But, if the source API Gateway has multiple tenants, this property can be used to specify the tenant name from which the data has to be migrated to the target tenant. For more details, see Upgrade configurations.

POST /rest/apigateway/migration

{
    "action": "reindex",
    "indicesType": "analyticsandlogs",
    "sourceElasticsearch": {
        "url": "http://localhost:9200",
        "username": "username",
        "password": "password"
    },
    "properties": {
    	"apigateway.migration.srcTenantName": "default",
        "apigateway.migration.batchSize": 100,
        "apigateway.migration.logLevel": "info",
        "apigateway.migration.reindex.status.check.sleep.interval": 5000,
        "apigateway.migration.batchSize.gateway_{0}_apis": 50,
        "apigateway.migration.batchSize.gateway_{0}_log": 100,
        "apigateway.migration.batchSize.gateway_{0}_audit_auditlogs": 50,
        "apigateway.migration.batchSize.gateway_{0}_analytics_transactionalevents": 50
    }
}

After this, the runtime data is added to the existing runtime data. The upgrade is complete with this step.

If the migration of the analytics data fails with an error or the status returned with a failure, then troubleshoot the problem by looking at the logs. You can find the logs at the target directory <TARGET>/profiles/IS_profile name/logs/wrapper.log. If the error persists, contact Software AG support team for help with all the relevant logs for further analysis.

Note: These are the logs and events indices in the Elasticsearch or API Data Store.

gateway_tenantId_quotaAccumulator, gateway_tenantId_analytics_performanceMetrics, 
gateway_tenantId_analytics_threatProtectionEvents, gateway_tenantId_analytics_lifecycleEvents, 
gateway_tenantId_analytics_errorEvents, gateway_tenantId_analytics_transactionalEvents, 
gateway_tenantId_analytics_policyViolationEvents, gateway_tenantId_analytics_monitorEvents, 
gateway_tenantId_license_licenseMetrics, gateway_tenantId_license_notifications, 
gateway_tenantId_log and gateway_tenantId_audit_auditlogs.