Important  reasons why we should switch from MongoDB 2.x to 3.x:

Below are our most important  reasons why we should switch from MongoDB 2.x to 3.x:

1. Safer Database

MongoDB 3.x uses more secure algorithms keeping your business-critical data safer when compared to the previous versions. Below are the details:
a. The default value of the WriteConcern parameter in MongoDB 3.x is {w:1}, while in 2.x it is {w:0}.
b. MongoDB 3.x uses the more secure algorithm SCRAM-SHA-1 for authentication, in place of the default MONGODB-CR used in 2.x.
c. MongoDB 3.x supports encryption engines to encrypt stored data(only for enterprise edtion)

2. Higher Service Performance

The table below outlines the MongoDB version-wise details for MMAPv1 and WiredTiger from the performance perspective.

Version	MMAPv1	WiredTiger
2.x	DB-level lock	Not supported
3.x	Set-level lock	Document-level lock

The performance problem while using MongoDB 2.x for high concurrency is mostly solved after upgrading MongoDB to MongoDB 3.x. MMAPv1 in 3.x provides a Set-Level lock, which enhances concurrency.
In fact, for enhanced concurrency, MongoDB 3.x also supports WiredTiger, with Document-level lock. This locking technique ensures that only a particular document gets locked during active operations while allowing other users to access the rest of the documents present in the same database.

3. Lower Storage Costs

The table below outlines the MongoDB version-wise details for MMAPv1 and WiredTiger from the storage perspective.

Version	MMAPv1	WiredTiger
2.x	Data compression not supported	Not supported
3.x	Data compression not supported	Snappy and zlib compression supported

Many users may be surprised to find a much smaller utilized data size after upgrading from MongoDB 2.x to MongoDB 3.x with WiredTiger. For example, 100G of data shrink to 30G after the update. Data shrinkage occurs because WiredTiger adopts Snappy compression by default, which cuts down the storage cost by 70-90 percent when compared to MMAPv1.

4. Faster Replication

MongoDB 3.x achieves fully streamlined OpLog pulling and playback with a higher efficiency while synchronizing incremental data.

5. Improvements in Full Data Synchronization

All indexes are created during data copying (only the _id index is created at data synchronization in previous versions).
The secondary node continues to pull a new OpLog while copying data, which leads to higher synchronization efficiency, avoiding synchronization failure due to the OpLog.

6. Simpler and More Efficient Sharding Cluster

From MongoDB 3.2, the config server of the sharding cluster is also a replica set, facilitating the maintenance, while there are multiple independent MongoDB nodes in previous versions.
From MongoDB 3.4, the config server will take on the migration of sharded clusters. Also, migration tasks can be initiated at the same time, with higher migration efficiency.

• MongoDB 3.x also incorporates other useful features, such as:
• Partial index, which can reduce the index space
• Document validation in flexible document models
• Collation, supporting sorting by localization languages
• Read-only views to easily write complicated queries
• More robust support for aggregation

  Recommended Steps to Upgrade

  MongoDB 3.x has come up with new enhancements when compared to MongoDB 2.x. It is recommended to upgrade to MongoDB 3.0 before upgrading to other higher versions using this guide. Please note that MongoDB can be upgraded from 2.x to 3.x without stopping or interrupting running services. Follow the steps below to upgrade from 2.x to 3.x safely:
• Create a new 3.x replica set
• Use mongodump in 2.x to backup data from the set
• Wait for the 3.x service to stabilize and remove the 2.x replica set

  Upgrade Suggestions for Other Versions

  For other versions, we recommend the following upgrades: For 2.x and 3.0 versions, we strongly recommend upgrading to version 3.2. For 3.2 and 3.4 versions, we recommend continue using the same version.