RocketChat/Rocket.Chat · critical · Error
UPGRADE NOT SUPPORTED! It seems you're trying to upgrade fr
Error message
UPGRADE NOT SUPPORTED! It seems you're trying to upgrade from an unsupported version! To be able to update to version 7.x.y you need to update to version 6.x first. Read more: https://go.rocket.chat/i/how-to-upgrade
What it means
Migration 292 is a sentinel: it was the first migration added in Rocket.Chat 6.0, so if the migrations framework reaches it during upgrade, the database's control version predates 6.x. Instead of attempting an unsupported multi-hop upgrade to 7.x, the migration deliberately throws a plain Error with upgrade instructions (update to 6.x first). This halts the migration run and therefore server startup.
Source
Thrown at apps/meteor/server/startup/migrations/minimumVersion.ts:8
import { addMigration } from '../../lib/migrations';
// this was the first migration added on version 6.0, so if this needs to run,
// it means the server was never updated to 6.x, which is not supported.
addMigration({
version: 292,
up() {
throw new Error(
[
'UPGRADE NOT SUPPORTED!',
'',
`It seems you're trying to upgrade from an unsupported version!`,
'',
'To be able to update to version 7.x.y you need to update to version 6.x first.',
'',
'Read more: https://go.rocket.chat/i/how-to-upgrade',
].join('\n'),
);
},
});
View on GitHub (pinned to b2c16d5842)
Solutions
- Deploy an intermediate 6.x release first, let migrations complete, then upgrade to 7.x (follow https://go.rocket.chat/i/how-to-upgrade).
- If the data is disposable, start with a fresh database instead of migrating.
- Verify the current control version in the _migrations collection to confirm how far behind the database is.
Example fix
# before: 5.x database started on 7.x image -> migration 292 throws
# after: stepwise upgrade
docker run rocket.chat:6.x # let migrations finish, check logs
# then
docker run rocket.chat:7.x # now migration 292 is already passed
# inspect control version:
mongosh rock_chat --eval 'db.getCollection("_migrations").findOne()' Defensive patterns
Strategy: validation
Validate before calling
// Before upgrading, inspect the migration control version
mongosh rock_chat --eval 'db.getCollection("_migrations").findOne()'
// if version < 292: first deploy a 6.x release, then 7.x Prevention
- Never skip major versions; upgrade sequentially (5.x -> 6.x -> 7.x).
- Back up the database before every major upgrade.
- Automate version checks in deployment scripts using the _migrations collection.
When it happens
Trigger: Starting a 7.x build against a database whose _migrations control version is below 292 (server last ran a pre-6.0 release, e.g. 5.x), so the migration chain tries to execute version 292's up().
Common situations: Skipping major versions during upgrade (5.x -> 7.x); restoring an old backup onto a new binary; Docker image tag jumps multiple majors; snap/channel upgrades.
Related errors
- Import operation not initialized.
- The value of the setting 'LDAP background synchronization in
- The value of the setting 'CROWD background synchronization i
- The default value of the setting 'Login Terms' has changed t
- The default value of the setting has changed. Please review
AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18).
Data as JSON: /api/errors/08334b7bcbbb156f.
Report an issue: GitHub.