Frequently Asked Questions
Question: Is it possible to execute the migration before the release of 2024.R2.0?
Answer: No, the migration will be part of the 2024.R2.0 release. However, you can already prepare for the migration by upgrading your current TrendMiner server to a 2024.R1.X version and provisioning a new server instance that meets the new requirements which are listed in the section on Create and configure the new TrendMiner Server.
To enable the remote backup, you can already make sure an Amazon S3 bucket or Azure Blob storage account is provisioned and accessible.
Question: Is it possible to migrate with an on-prem local S3 storage?
Answer: No, we only support remote AWS S3 or Microsoft BLOB storage.
Question: Is it possible to load all data in the blob storage, deploy the new OS on the existing server and then download the data from blob again?
Answer: Since the new server will run on a new Operating System, it is not possible to truly “install over”. To avoid downtime, TrendMiner recommends preparing the new server in advance of the migration, and therefore does not recommend this approach. However, it is technically possible to avoid having 2 servers/VMs online in parallel by following this high-level procedure:
Upgrade the current system to 2024.R2.0 and perform the remote backup
Turn off the existing server (if it's a VM: do not delete it!)
Create a new server with at least the minimum system requirements and power it on
Install TrendMiner 2024.R2.0 on the new server
Restore the remote backup on the new server
Validate the setup
This way, the systems will not run simultaneously side-by-side, reducing the temporary increased overall system resources required. However, note that during this transition period, TrendMiner will be unavailable to end users.
Warning
Please note that if you opt to delete the existing VM, and something goes wrong with the remote backup (e.g. some data gets corrupted during upload), there is no fallback scenario possible and all work will be lost! Therefore, TrendMiner strongly discourages this option.
Question: Can we reuse the same IP and hostname for the new VM?
Answer: Yes, but it comes with a number of clear drawbacks that you should take into account:
You can only set up the new VM when the old one is powered off
You can't do a dry-run without downtime
You can only validate while the production system is down
Question: What can we do today to prepare for this migration?
Answer: Today you can already prepare for the OS migration by:
Ordering/provisioning a new server which meets the new AlmaLinux/RHEL9-based system hardware requirements. Also ensure that the new server has at minimal the same amount of disk space available on the current VM.
Informing the right people about the upcoming migration:
End users should be informed about upcoming downtime. How much downtime can be expected mainly depends on the chosen migration process and will be detailed in the migration instructions shipped with the 2024.R2.0 release.
Colleague administrators can be contacted upfront to inform them about the upcoming requests:
In case you use SSO to authenticate (Azure/Entra AD or OKTA) a new metadata file will need to be uploaded on the IDP side after the migration.
Optionally get a new IP and a new hostname for the new VM
After the migration a new SSL certificate will need to be uploaded
Firewall changes might be required for users to be able to access the new VM
Question: After provisioning and a clean install of TrendMiner on the new server, which steps will still be needed?
Answer: Next to the migration of the application data, 3 separate configuration phases are foreseen:
After provisioning the new VM and before installation of TrendMiner on the new VM: In case you have custom appliance IP addresses configured these will need to be reconfigured on the new VM with the help of TrendMiner support. More details can be found here: Appliance IP requirements FAQs. When in doubt, contact TrendMiner support.
After installation of TrendMiner and before the restore of the backup:
Network settings (IP Address, TrendMiner server name, NTP, DNS, …)
SSL and certificates
Mail server
Time zone setting
After the restore of the backup: In case you have an SSO integration (SAML/OKTA) the metadata file will need to be updated in your IDP config.
Question: For the new virtual appliance deployment is it possible to start with system resources (CPUs, RAM, SSD) below the minimum requirements?
Answer: No, installations should always meet the minimal system requirements. To avoid incurring additional costs, it is possible to deploy and configure the new virtual machine but keep it powered off until you are ready to continue the migration.
Question: with the local backup & restore option, what exactly will not be included? Are there best practices on how to handle this?
Answer: The local backup solution only takes a backup of the database, while the remote backup solution will include all components of the Trendminer installation. The remote backup solution can be used as a real disaster recovery solution also.Additional work/configuration for the local backup solution compared to the remote backup solution includes:
Re-indexing all tags (including the preparation work like extraction of a list of indexed tags and some other manual actions)
Manual reconfiguration of custom specific configuration like memory and timeout setting overrides with the help of TrendMiner support
Manual reconfiguration of the 'simultaneous index operations' setting
For MLHub customers: manually copying over the PMML models
Detailed migration instructions will be provided with the 2024.R2.0 release.