Skip to main content
  1. CloudM
  2. Migrate
  3. FAQs

Can I move my CloudM Migrate infrastructure to a new server setup?

Updated

Summary

This article outlines the limitations, risks, and necessary steps if you intend to move your CloudM Migrate Self-Hosted installation to a completely new server environment (i.e. a new Primary server and associated Secondary servers).

⚠️ Important Warning: Moving an existing CloudM Migrate infrastructure to a new server is not recommended.

Due to encryption dependencies and database architecture, you cannot "lift and shift" your existing installation. If you must move to a new server environment (for example, to comply with different or new internal policies or firewall rules), you must treat this as a fresh installation and restart the migration process.

Note: This article applies to creating a new migration infrastructure in a new server environment, not adding/removing secondary migration servers to an existing migration infrastructure. Please see our Multi-Server Installation guide for more information on this.

Key Limitations

If you proceed with moving to a new server environment, be aware of the following:

  • Database Loss: You cannot migrate your existing PostgreSQL or Redis databases (whether local or on a dedicated server) to the new instance. The databases must be recreated from scratch on the new infrastructure.

  • Loss of Migration Reports, Logs, and Traces: Historical migration reports, and migration logs/traces will not be available in the new instance.

  • Loss of Migration History: Migration History will not be available.

    • Performance Impact: Without Migration History, re-migrations in the new server environment may take longer. CloudM Migrate must scan the destination live environment for every item to verify its existence, rather than relying on previous local records.

Data Integrity & Licensing

Despite the "fresh install" requirement, CloudM Migrate has safeguards to protect your data integrity.

  • No Duplicate Data: Even without migration history, we prevent duplicates by checking metadata at the destination (e.g. unique Message-IDs for emails, file metadata, and custom CloudM metadata applied during previous migration runs).

  • Licensing: You can re-apply your existing CloudM Migrate license key. The CloudM Licensing Portal tracks usage centrally; re-migrating entities that have already been accounted for will not consume additional licenses. Only new, previously unmigrated entities may require additional licenses.

Infrastructure Transition Process

To transition your migration infrastructure to a new server environment safely, follow this checklist:

1. Archive Your Previous Migration Records (Old Server)

Before decommissioning your old server, save your migration records manually, as they cannot be imported into the new server.

  • Migration Reports: Go to Batch > Progress > View Report History to export reports for your records.

  • Migration Logs & Trace Files: You may zip up migration logs and trace files from the CloudTechnologySolutions folder, though these are rarely needed for historical reference. 

2. Export Configurations (Old Server)

You can save time by exporting your user lists and settings.

  • Export Batch Configurations: Export your batch configurations to ensure your settings remain consistent.

  • 'Items to migrate' and 'Address replacements' CSVs: Copy all Items to migrate and Address replacements CSVs for import to your new infrastructure.

  • Save Certificates: Copy any P12 or JSON key files (used for Google) or PFX certificates (used for Microsoft) required for connection authentication. These can be reused on the new infrastructure.

3. Setup New Server Environment

  • Create your new primary and secondary servers.

  • If using dedicated SQL and/or Redis servers, these should be recreated also.

4. Setup New Infrastructure

  • Install CloudM Migrate afresh on the new server environment.

  • Recreate your Projects, Source and Destination Connections.

    • Note regarding Authentication: Google and Microsoft certificates can be reused. Other platforms (E.G., Dropbox) may require re-authentication.

5. Import & Validation

  • Import Batches: Import the batch configuration files, Items to migrate, and Address Replacements CSVs you exported in Step 2.

⚠️ Important Warning: Do Not Change Settings
It is critical that you do not change batch configuration options during this move. Changing settings between migration runs (whether changing server environment or not) will cause data integrity issues.

6. Test Strategy

Before running a full migration, you must validate the new setup.

Related Articles

Was this article helpful?
0 out of 0 found this helpful