Check featureCompatibilityVersion (fCV) and the major upgrade sequence

Command

// 1) Current fCV (must be the same on all members; targetVersion appears if a transition is incomplete):
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })
// 2) Upgrade binaries in a rolling fashion (secondaries -> stepDown -> old primary); fCV stays old
db.version()
// 3) After the observation period, raise fCV on the primary (on mongos in a sharded cluster):
db.adminCommand({ setFeatureCompatibilityVersion: "7.0", confirm: true })
// 4) If a rollback is needed, fCV is lowered BEFORE the binaries:
db.adminCommand({ setFeatureCompatibilityVersion: "6.0", confirm: true })

What it does

Shows the running fCV; gives the order in which the binary upgrade and the fCV upgrade, which are separate steps, are performed.

When to use it

When planning a major version upgrade (e.g. 6.0 -> 7.0), when new features are unavailable after an upgrade, or before moving to the next major.

Caution

Major versions cannot be skipped: for 5.0 -> 7.0 first move to 6.0 and set fCV to 6.0. After fCV is raised, data files may switch to the new format and binary downgrade becomes harder; raise fCV only after the new version has run cleanly for a few days. Binary downgrade is not officially supported on 7.0+ Community; base the fallback plan on a backup. Check driver compatibility before upgrading.