The recommended (and most throughly tested & documented) approach is an in-place upgrade which minimises downtime and gives you opportunity to test for compatibility issues before upgrading to the next major release.
In-place upgrades require upgrading via successive major releases (so from 3.2 => 3.4, 3.4 => 3.6, etc). All members of a replica set or sharded cluster must be completely upgraded to the same version before continuing to the next major version upgrade.
There are a few ways you can fast track a migration through multiple major version upgrades.
Preparation
As @chris noted in one of your other discussion topics, you should upgrade your clients/drivers for compatibility with your target server version. I would test and implement driver upgrades before commencing any server upgrades. Given the age of your original deployment, newer drivers may have API compatibility changes requiring an update to your application code. Drivers are generally backward compatible with a great range of MongoDB server versions, but older drivers will be missing support for newer APIs and authentication mechanisms.
Be sure to review the relevant Release Notes and Compatibility Changes information in the MongoDB manual, and follow any version-specific Upgrade procedures. There have been a lot of changes since MongoDB 3.2 was released in 2015!
Regardless of the upgrade approach you take, be sure to take backups of your deployment so you have a straightforward recovery path in the unlikely event that something goes dramatically amiss.
Upgrade with Automation
This is the safest upgrade path:
-
Use Cloud Manager Automation (currently supports MongoDB 3.4+) to migrate your on-premise deployment to a supported version of MongoDB. There’s a 30-day free trial of Cloud Manager automation which will probably cover your migration period.
-
Use MongoDB Atlas Live Migration (currently supports MongoDB 2.6+) to upgrade to a modern version of MongoDB hosted in the cloud. You can either restore a backup from your Atlas deployment on-premise, or consider using Atlas as a more convenient management solution going forward.
Upgrade with Backups & Downtime
If downtime is acceptable and you have a large number of major releases to upgrade through, you can also consider a migration using mongodump and mongorestore.
This approach will require more testing and patience because you are still subject to major version compatibility changes and will encounter different issues depending on the provenance of your data. This approach will also not support upgrading user & auth schema, which is supported via the usual in-place upgrade path.
Unlike an in-place upgrade, dump & restore will recreate all data files and indexes so you may run into some (fixable) errors. The most likely complaints will be due to stricter validation of index and collection options which would not cause an issue for an in-place upgrade. I definitely recommend testing this procedure in a staging/QA environment with a copy of your production data to ensure there are no unexpected issues that might otherwise delay your production upgrade.
Regards,
Stennie