How to migrate your TrendMiner installation to a different server?
This guide describes the supported path for migrating a TrendMiner installation from one server (the old / source server) to another (the new / destination server) using remote backup and restore. The migration relies on off-site, S3-compatible blob storage and preserves all data, including tag index data.
Three storage back-ends are supported:
Azure Blob Storage
AWS S3
On-premises S3-compatible storage
such as MinIO (local)
Overview and recommended approach
The first step in any server migration is to set up a new TrendMiner instance to replace the existing one. The installation process is covered in the installation guide, which also explains how to install a new TrendMiner instance.
The recommended approach is to set up the new server alongside the existing one. This lets you prepare and test the new server without downtime for users and without time pressure.
When following this approach, keep the following in mind.
Server name and DNS
The host name does not affect the correct functioning of TrendMiner, but the TrendMiner server name (FQDN) must be set to the URL that users browse to when using TrendMiner. Typically a DNS record is created that points to the TrendMiner IP address.
The SSL certificate is also based on this DNS name. You may choose any server_name you like; however, do not reuse the name of the old server, because the two domains will interfere with each other. For example:
Server | Host name | DNS record / |
|---|---|---|
Old | tm-test01 | test.trendminer.com |
New | tm-test02 | test-new.trendminer.com |
On the new server, upload an SSL certificate that includes both server names as subject alternative names (SANs). SSL then works on https://test-new.trendminer.com immediately, and — because the certificate already covers the old name — it will also work on https://test.trendminer.com after the DNS swap, with no need to request a new certificate.
After the migration, switch the DNS records so that users still browse to test.trendminer.com while being served by the new server in the back end. At the same time, update the TrendMiner server name field in Edge Manager to reflect the DNS swap.
System requirements
Set up the new server according to the current system requirements.
Important. System requirements can change between releases. Always verify the values below against the requirements published for your target TrendMiner version and provision the new server accordingly.
Resource | Minimum | Minimum with Embedded Notebooks & ML Model functionality | Recommended | Notes |
|---|---|---|---|---|
vCPU | 16 | 1 core per 4 active kernels (per user) + 1 core per 8 notebook tiles (per user per dashboard) | 16 | On servers with high indexing activity, available CPUs should at least match the configured simultaneous indexing threads. |
RAM | 64 GB | 1 GB per active kernel (per user) + 256 MB per notebook tile (per user per dashboard) | 96 GB | Memory requirements may increase between versions. Check the requirements for your target version. |
Disk | SSD, 10 GB on root volume; 200 GB + 300 GB on | Same as Minimum | Same as Minimum | Slow disks can severely degrade the user experience or cause failures. Verify disk speed using the Linux commands in Prepare the Installation. |
Important — memory-to-CPU ratio. In addition to the values above, TrendMiner requires memory to scale with CPUs at a ratio of at least 1:2, and preferably 1:4. In practice this means 128 GB RAM for a 32-CPU server and 256 GB RAM for a 64-CPU server.
Reserve at least the same amount of disk space on the new server as on the old one. If the disk was running full on the old server, use this opportunity to add more space on the new server.
Note — custom K3S IP ranges. If your current installation uses custom K3S IP addresses, these must be configured again manually before installing the TrendMiner software on the new server (as instructed in the installation guide). If in doubt, contact TrendMiner Support.
Matching TrendMiner versions
For the final migration step, the old and new servers must run exactly the same TrendMiner version, including the patch number — for example, 2026.R2.0-08.
If the new server was installed with an earlier patch than the current production server (for example, the new server is on 2026.R2.0-05 while production has been upgraded to 2026.R2.0-08), the backup from the old server cannot be restored onto the new server until the new server is upgraded to the matching version.
Upgrading the existing server to match the new server follows the same upgrade process as any previous upgrade and is described in the upgrade notes. Be sure to select the correct target version in the top-right corner of that page.
Configuration steps
Because a backup will be restored onto the new server, not every configuration step from the installation guide is required for a migration. The following steps can be omitted:
Uploading a license
— the existing license is transferred automatically to the new server.
Connectivity and access management
— configured data sources are migrated automatically, or can be updated as a post-migration step if needed.
Connector / Plant Integration installation
— after the migration you can (and should) connect to the already-installed connector(s).
User management
— configured IDPs are migrated automatically, or can be updated as a post-migration step if needed.
All other configuration steps (SSL configuration, NTP configuration, and so on) should be carried out by following the installation guide.
Tip. For SSL configuration on the new server, upload a certificate that includes both server names (old and new) as subject alternative names, so the same certificate is valid before and after the DNS switch as described above.
After installation, validate that all services are running: in Edge Manager, go to DASHBOARD → Services and confirm every service shows a green status.
Once the new server is set up correctly and the old server has been upgraded to the exact same 2026.R2.0-XX version, you can migrate the data.
Migrating data via remote backup and restore
Once the new server is configured and both servers run the exact same TrendMiner version (for example, 2026.R2.0-08), migrate the data using the remote backup/restore feature.
Remote backup/restore uses off-site, S3-compatible blob storage (Azure Blob Storage, AWS S3, or a local S3 provider) to create a full backup of the TrendMiner installation — including all databases, settings, index data, and Kubernetes resources — and restore it on the new server. This is the strongly recommended migration path because it migrates all data, including tag indexes.
Note — what a remote backup contains. A remote backup includes everything needed to restore a fully working TrendMiner installation on a different server, excluding server-specific settings such as host name and SSL certificates, but including the index data. This is what distinguishes it from a local (database-only) backup, where tag indexes are lost and must be rebuilt.
Tip — test-migrate first. To avoid downtime, perform a test migration before the final one. After restoring a full backup onto the new server and confirming it runs correctly, schedule the final migration. This also speeds up the final cutover: the second backup taken on the old server is an incremental backup and completes much faster than the first.
Prerequisites
Before starting the backup/restore migration, ensure the following:
Both source and destination servers run the exact same TrendMiner version, including the patch number (for example,
2026.R2.0-08).A VM snapshot of the new server has been taken before the restore, so you can roll back and retry if something goes wrong. Use your virtualization tools for this.
SSL is properly configured on the new server.
A proper NTP server is configured on the new server.
A mail relay is configured on the new server (this is not migrated from the old server).
If custom K3S IP ranges are in use, they are configured identically on both servers. If in doubt, contact TrendMiner Support.
Remote options only:
the customer has provisioned an Azure Blob Storage account or an AWS S3 bucket that is reachable from both servers.
Local S3 option only:
an on-premises, S3 API (v4)-compatible storage location is reachable from both servers.
Remote options only:
Outbound access on port 443 (HTTPS) to the cloud storage endpoint is allowed from both servers. No inbound connections from the storage location are required.
Important. The TrendMiner installation on the new server is unavailable during the restore. All services stop automatically and restart once the restore completes. Every restore first deletes all existing data and then restores the complete state, so a restore always takes roughly the same amount of time regardless of whether the source backup was full or incremental.
Supported options
Option | Storage | Notes |
|---|---|---|
Remote backup/restore | Azure Blob Storage | Recommended |
Remote backup/restore | AWS S3 | Recommended |
Local backup/restore | On-premises S3-compatible (for example, MinIO) | Use when neither cloud option is viable |
Migration with Azure Blob Storage
Configure your storage location in Azure: https://documentation.trendminer.com/en/full.html#UUID-bc040cff-6f92-b870-e51f-8166f0fe3689
Configure the Azure storage provider in Edge Manager on both instances: https://documentation.trendminer.com/en/full.html#UUID-5a2f9420-811e-061d-3729-1cdd31344404
Create a full backup on the old instance: https://documentation.trendminer.com/en/full.html#UUID-1f49ccad-ce32-6576-6dce-28e308fcc4dc
Initiate and validate the restore on the new instance: https://documentation.trendminer.com/en/full.html#UUID-5e236adb-8db3-2815-20dd-751a29a39922
Migration with AWS S3
Configure your storage location in AWS: https://documentation.trendminer.com/en/full.html#UUID-64c82926-e1c2-4e3e-a107-54fc7259f76e
Configure the AWS storage provider in Edge Manager on both instances: https://documentation.trendminer.com/en/full.html#UUID-4004a696-3eac-34a8-d387-f3945c5c8ec6
Create a full backup on the old instance: https://documentation.trendminer.com/en/full.html#UUID-1f49ccad-ce32-6576-6dce-28e308fcc4dc
Initiate and validate the restore on the new instance: https://documentation.trendminer.com/en/full.html#UUID-5e236adb-8db3-2815-20dd-751a29a39922
Migration with a custom or MinIO S3 provider
Configure your custom or MinIO S3 provider in Edge Manager (see the Custom S3 provider and MinIO S3 procedures):
Create a full backup on the old instance.
Create a full backup on the old instance: https://documentation.trendminer.com/en/full.html#UUID-1f49ccad-ce32-6576-6dce-28e308fcc4dc
Initiate and validate the restore on the new instance: https://documentation.trendminer.com/en/full.html#UUID-5e236adb-8db3-2815-20dd-751a29a39922
DNS switch and final cutover
Once the new server is fully validated:
Switch the DNS records so that the production FQDN (for example,
test.trendminer.com) now points to the new server's IP address.Update the TrendMiner server name field in Edge Manager to reflect the new DNS (if it was changed during setup).
Power down the old VM to avoid any mix-up with the new one. Do not delete or decommission the old VM yet — keep it as a fallback in case issues surface later.
Reconfigure the remote/local storage backup path on the new server to use a new, dedicated path for ongoing backups.
Create a new full backup on the new server to establish a fresh baseline.
Warning — backup retention. Remote backups have a retention period of 30 days and are deleted automatically after that, whether created manually or on a schedule. After cutover, enable scheduled backups on the new server (and continue taking regular VM snapshots) so that a valid backup is always available for disaster recovery.
Decommission the old server
After the new server has run successfully in production for a sufficient period — at least two weeks is recommended — the old server can be safely decommissioned.