Article Type: Recommendation, Best Practice

At some point, you may need to migrate your application's data and configuration from an existing cluster (source cluster) to a new cluster (destination cluster).

This migration can be done in several ways:

• Backup and restore approach - where you take a full backup of your source Database and perform a restore on the destination Database
• Hybrid-cluster approach -  where you add new nodes to the source cluster, rebalance/distribute forest data across all the nodes, retire the old forests to let the data completely move over to the new nodes, and finally remove the old nodes
• Backup/Restore and Database Replication approach - where you create a new destination cluster, perform a full backup of the source cluster, restore the resulting backup on the destination cluster, setup database replication between the source and destination clusters (source cluster being the primary). Once both the clusters are in sync, you'd then switch over to the destination cluster making it the new primary

Among the three approaches listed above, we recommend the backup/restore and database replication approach because this approach:

• Is safer as your source cluster remains in a known good state.
• Is easier because if something goes wrong, you can return to your known good state by simply disabling database replication 
• Supports disaster recovery by providing an active copy of your source cluster
• Gives you enough time to build trust in the destination cluster before switching over to it from the source cluster to complete the migration

No matter which one of the above approaches you take, we highly recommend testing your chosen migration process first in your lower environments before implementing this in your production environment.