Upgrading MongoDB 4.4, 5.0 or 6.0 to 7.0 or 8.0: The Version-by-Version Path

The short answer

You cannot skip a major release. MongoDB's upgrade procedures require the deployment to be on the previous release series before each step: 5.0 needs 4.4, 6.0 needs 5.0, 7.0 needs 6.0 and 8.0 needs 7.0. Going from 4.4 to 7.0 is three full upgrades of every replica set and sharded cluster, and 4.4 to 8.0 is four. Each one ends by raising featureCompatibilityVersion (FCV) to the new release, and the next upgrade will not start until that is done.

Two checks come before any of it. Every host that will run 5.0 or later needs a CPU that exposes AVX, and every application needs a driver that supports the release you are moving to. Both are covered below.

The dates, from MongoDB's lifecycle schedule: 4.4 reached end of life on 29 February 2024, 5.0 on 31 October 2024 and 6.0 on 31 July 2025. 7.0 is supported until 31 August 2027 and 8.0 until 31 October 2029. If you are starting from 4.4 or 5.0 today, 7.0 leaves you less than a year before the next upgrade is due, so most teams should plan for 8.0 and treat 7.0 as a waypoint.

The path at a glance

From 7.0 onwards the command fails unless you pass confirm: true. Scripts written for earlier upgrades need that change.

Before the first step

Check AVX on every host

MongoDB 5.0 and later need the AVX instruction set on x86_64. A 4.4 replica set runs fine on hardware without it, then the first member started on 5.0 binaries does not come up. Check every host, including arbiters, hidden members, delayed members and the machines you restore backups to. Run the check inside the guest, because a hypervisor CPU model that hides AVX is a more common cause than old hardware.

grep -o -w avx /proc/cpuinfo | head -1

No output means no AVX. MongoDB 5.0+ requires a CPU with AVX covers the Proxmox, KVM and VMware fixes, and what to do when the hardware itself is the problem.

Upgrade the drivers first

Each upgrade page tells you to confirm the driver supports the target release before you start, and warns that incompatible drivers can produce unexpected or undefined behaviour. Check the compatibility table in your driver's documentation for every service that connects, including batch jobs and reporting tools that nobody owns. Two removals make this more than a formality:

• MongoDB 6.0 removed the legacy wire protocol opcodes OP_INSERT, OP_UPDATE, OP_DELETE, OP_GET_MORE, OP_KILL_CURSORS and OP_QUERY for finds. Drivers have used OP_MSG since 3.6, but old pinned driver versions in forgotten services still use the legacy ones, and they stop working.
• The legacy mongo shell was deprecated in 5.0 and removed in 6.0. Any operational script that calls mongo needs to move to mongosh.

Find out where you are

// on each member, in mongosh
db.version()
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

A cluster that was upgraded binaries-only in the past may report an FCV one release behind its binaries. Fix that first: run the setFeatureCompatibilityVersion command for the current release on the primary (or on mongos for a sharded cluster), with a majority of data-bearing members available.

Breaking changes at each release

These come from MongoDB's compatibility notes for each version. They are the ones most likely to break an application or an operational script; read the full notes for your release as well.

To find TTL indexes with a NaN expiry before the 5.0 step:

db.adminCommand({ listDatabases: 1 }).databases.forEach(function (d) {
  var sdb = db.getSiblingDB(d.name);
  sdb.getCollectionNames().forEach(function (c) {
    sdb.getCollection(c).getIndexes().forEach(function (i) {
      if (i.expireAfterSeconds !== undefined && isNaN(i.expireAfterSeconds)) {
        print(d.name + "." + c + " " + i.name);
      }
    });
  });
});

Running each step on a replica set

1. Take a backup you have restored before. A filesystem snapshot or a mongodump, tested on a staging host.
2. Confirm the FCV is the current release on every member, and that no member is in ROLLBACK or RECOVERING.
3. Upgrade the secondaries one at a time. Shut the member down with db.adminCommand( { shutdown: 1 } ), replace the binary, start it, and wait for it to return to SECONDARY before moving on.
4. Step down the primary with rs.stepDown(), then upgrade it the same way.
5. Run on the new binaries with the old FCV for a while. MongoDB recommends a burn-in period first, because enabling backwards-incompatible features makes a downgrade harder.
6. Raise the FCV on the primary once you are confident: db.adminCommand( { setFeatureCompatibilityVersion: "7.0", confirm: true } ) for the 7.0 step. Make sure no initial sync is running, because the command restarts it.

For a sharded cluster the order is: stop the balancer with sh.stopBalancer(), upgrade the config server replica set, upgrade each shard replica set, upgrade the mongos instances, restart the balancer, then set the FCV through mongos.

Repeat the whole sequence for each release. Do not run 5.0 binaries against a 4.4 FCV for months and then try to jump: the next step checks the FCV and refuses to start.

Test plan

• Restore production into staging and run every step there first, timing each one. The step duration in staging is the best estimate of your maintenance windows.
• Run the application test suites at two points per step: new binaries with the old FCV, then new binaries with the new FCV. Some behaviour changes only appear after the FCV change.
• Search code and scripts for removed helpers: save(, ensureIndex(, secondaryOk, getLastError, $query and calls to the mongo binary.
• Compare query plans for the slowest and most frequent queries with explain("executionStats") before and after. Planner changes between releases can move an index choice.
• Exercise failover on the upgraded set: step down the primary under load and check that every driver reconnects.
• Restore a backup taken on the new release, so you know your backup tooling supports it before you need it.
• For the 8.0 step, test queries that compare against null and any maintenance script that connects straight to a shard.

Rollback

Before the FCV change, a step is reversible: the data files are still compatible with the previous release, so you can stop each member and start it on the old binary. That is the reason for the burn-in period.

After the FCV change it gets harder. For the 4.4 to 5.0 and 5.0 to 6.0 steps, MongoDB documents a downgrade that sets the FCV back, removes any persisted backwards-incompatible features, then swaps the binaries. For 7.0 and 8.0, the manuals published with those releases state that you cannot downgrade the binary version without assistance from MongoDB Support. The current manual says single-version downgrades are supported starting in MongoDB 8.3, which does not help a 7.0 or 8.0 target. For a self-managed Community deployment without a support contract, plan the rollback for those two steps as a restore from the backup taken just before the step, and size the maintenance window for that restore.

If you cannot finish before the next deadline

Three upgrades of every cluster, each with its own driver audit, is months of work for a large estate, and the AVX requirement can turn a software upgrade into a hardware refresh. OSSeva ships patched builds of MongoDB Community Server 4.2, 4.4, 5.0 and 6.0, with security fixes backported to mongod, mongos and the bundled tools, including 4.2 and 4.4 builds for hosts without AVX. Patched packages and container images are signed and come with SBOMs. Assure adds the featureCompatibilityVersion upgrade plan, a driver compatibility audit, VEX attestation for scanner findings and SOC 2 or PCI DSS evidence. Operate adds 24/7 monitoring of replica sets and clusters, a 15-minute P1 response and executed major version upgrades. See MongoDB support and MongoDB extended support.

Related

• MongoDB end-of-life dates
• MongoDB 4.4 end of life
• MongoDB 5.0 end of life
• MongoDB 6.0 end of life
• MongoDB 5.0+ requires a CPU with AVX support