Sizing Your Clusters

☐ Consider your current and future cluster topology such as Replica Set to Replica Set or Replica Set to Sharded Cluster.

☐ Start thinking about sizing hardware resources (CPU, RAM, IOPS) for your migration, as well as your Oplog collection.

Keep in mind that if your data size and index size are large, it's better to consult our Professional Services team – especially if you cannot tolerate any downtime.

☐ Compare your source cluster to the target and consider whether your application is optimized for reads or writes, and if your source cluster is adequately provisioned.

Note that if your source cluster is under-provisioned, you'll need a larger target cluster in Atlas.

☐ Check out the extent of your disk in your current setup and perform any necessary failover tests to make sure your cluster is sized appropriately.

☐ Log in to MongoDB Compass to visually explore your data, review and test your queries/indexes, and see your database’s performance metrics.

Be sure to let your MongoDB team know if you require guidance on cluster sizing!

Migration Pre-Requisites

☐ Check out the Atlas Migration Learning Toolkit – a one-stop-shop for our most helpful onboarding resources. 

☐ Before you begin, make sure that your app drivers are all up-to-date – this is crucial for a successful migration!

Note that if you have a standalone server with data that you want to use in production, you'll want to convert the standalone server to a replica set first.

☐ Consider how much downtime you can tolerate, how easily you can change your connection string, and what security restrictions are in place.

☐ Check to see if your connectivity/networking/access/security rules are applied and your backup policy is defined.

☐ Talk with your MongoDB support team to polish off any schema design review and testing (queries and indexes).

☐ Make sure your scaling testing is performed and your rollback strategy is defined (if these are applicable to you).

☐ On the application level, ensure your connection string points to the new Atlas cluster.

Best practice is to do so in a rolling fashion in the service/app layer.

Pre-Migration

☐ Review the various migration tools available and choose the one right for you:

The right tool for your migration will depend on your downtime requirements, MongoDB versions, managed vs self managed options, data volume, and more.

• Live migration (<5 minutes downtime): 
  • Atlas Live Migrator - Source & Destination clusters on 6.0+ or 7.0+
    
  • Self-managed Mongosync - Source & Destination clusters on 6.0+ or 7.0+
    
    Note that if you have a standalone server with data that you want to use in production, you'll want to convert the standalone server to a replica set first.
    
    Instructions on how to do so are provided here. Additionally, the source cluster can't be on a shared or serverless cluster.
    
    
• Self-managed (Some downtime tolerable):
  • Mongomirror - MDB ver 4.4 to 6.0.13
  • Mongodump/mongorestore
    

☐ Develop and document a clear migration plan, outlining key milestones and timelines.

Version Upgrades

☐ Review your current server version and destination server version to determine your migration process and tooling.

☐ Check out any new features of MongoDB that might benefit your app, and incorporate into your upgrade plan as is fitting.

☐ Conduct some testing & dry-runs to ensure compatibility.

Post-Migration

☐ Validate the migration was successful by comparing the number of documents at the source VS the destination.

☐ Exhale. Congrats – your migration should be successfully finished. Well done!