Rocket.Chat 7 to 8 upgrade

Choose the 8.5 or 8.9 LTS line by working out how long the release must stay supported and when your team can schedule the next upgrade. Rocket.Chat 8.9.0 was published on GitHub on October 5, 2026, and patch releases such as 8.5.4 and 8.6.3 followed on October 16, 2026 for older supported lines. LTS releases are supported for 12 months, but each line's clock depends on its own release history, so the two lines will not necessarily end on the same date. Treat the comparison as a dated check, not an assumption.

Start with the version durability documentation. Record the support end date for each line and note the date you checked it. Then confirm the current patch level of each line on the Rocket.Chat GitHub releases page. A line that already carries later patches gives you fixes you would otherwise have to wait for, and that difference matters if you go live close to a cutover window. Keep the captured dates and patch versions in your upgrade record so the decision can be reviewed later.

Next, read the changelog between the two lines. Focus on the items that affect a 7.10 LTS to 8.x move: removed or changed API endpoints, settings that were renamed, and features your users depend on. Compare what 8.9 adds beyond 8.5 and decide whether any of those additions are needed in your deployment. Check the changelog entries against your own feature and integration list, including identity providers, video conferencing links, Omnichannel use, Marketplace apps, and any API clients that call the server directly.

Map your integration list to a support decision. For each integration, confirm with its vendor or documentation whether it is certified or tested against the candidate line. Unsupported versions also lose cloud services such as the push notification gateway and can stop working with the official mobile and desktop clients, so an unsupported target creates user-facing risk, not just security risk. If a dependency is only validated on one line, that often settles the choice. Ask your upgrade partner to confirm this in writing as part of the scope.

Finally, tie the choice to your calendar. If your next upgrade window is already fixed, pick the line whose support end date leaves room for that window plus testing time. If you cannot yet name the next window, favor the line with more remaining support at cutover, and write down who owns the decision to upgrade again. Record the chosen line, the exact patch version to deploy, the documentation date, and the owner. Revisit the record when a new patch or a changed support date is published.

Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so the database must reach that level before the application changes. The order matters. A 7.x application runs against the database it was built for, and the new release will not start against a database that does not meet its requirements. Plan the MongoDB change as the first step of the cutover, with the Rocket.Chat application still on 7.x while the database moves. Before you schedule anything, read the current Rocket.Chat system requirements for your target release and record the MongoDB versions it names. That record becomes the reference for your change plan. Assign one owner to the decision about when the database moves, because the change affects every client connected to the workspace.

Start with a replica set check. Rocket.Chat 8.x needs MongoDB running as a replica set, so confirm that your current deployment is a replica set and not a standalone server. Check that every member reports a healthy state, that a primary is elected, and that replication lag is low and stable across members. Record the member count and the host each member runs on. The system requirements recommend three members for high availability. If your deployment has one or two members, treat adding members as a separate change with its own testing, and decide before the upgrade whether to add them first or afterward. A two-member set cannot keep a majority when one member fails, so the team should understand that risk before the window opens.

Node.js does not need separate management when you run Rocket.Chat from the official Docker image or the official Helm chart, because the runtime is bundled in the image. Patching and upgrading the application image covers it. This matters for scope. Teams that build their own images, or that run the application from a source checkout on their own hosts, must manage the Node.js runtime themselves and confirm the version the target release expects. Write that down in the change plan, along with who owns the image pipeline and how a rebuilt image is tested. Also confirm that the database connection string and any replica set name in your deployment values match the MongoDB configuration, since a mismatch can stop the application from connecting after a change.

Confirm the MongoDB upgrade path and the feature compatibility setting in MongoDB's own documentation before you commit to a sequence. Use MongoDB's published guidance to check which starting versions can be upgraded to 8.0 directly, what the procedure is for a replica set, and how the feature compatibility version is set and raised. Raising that setting is usually a separate decision with its own consequences, so find out from the documentation whether it can be reversed and what a downgrade would require. Follow the steps MongoDB publishes for your starting version, and treat any summary, including this one, as a pointer to the source rather than a replacement for it.

Treat the database upgrade as its own change with its own rollback point. Take and verify a backup before the first member changes, and record the point after which going back requires a data restore, which is a heavier step than reverting a binary. Test the full sequence in staging first, using a recent copy of production data where your data handling policy allows it. In staging, run the 7.x application against the upgraded database and check sign-in, message history, file access and scheduled jobs before you move to the application upgrade. Agree the go or no-go criteria and the owner of each decision before the window, so the team is not making those calls under pressure.

The most reliable way to find upgrade breakage in the Rocket.Chat REST and realtime APIs is to inventory every caller before the cutover date. The web client is only one consumer. Build the list from several sources: bots, custom scripts on the server, middleware and API gateways, identity sync jobs that create, update or deactivate users, helpdesk and ticketing connectors, and apps installed from the Marketplace. For each consumer, ask the owner which service account it uses, which REST endpoints and realtime methods it calls, and how often it runs. Confirm the list against server logs and reverse proxy logs covering a long enough period. A monthly reconciliation job will not appear in a two-day sample.

Next, match each recorded call against the endpoints that the 8.x release notes list as removed or changed for your target version. Use the release notes for the exact version you plan to run, and keep a copy with the upgrade record. For every match, document the caller, the endpoint, the change, the replacement the release notes name, and whether the caller will fail loudly or silently. Silent failures carry the most risk. A sync job that receives a success response but skips records can run for weeks before anyone notices. A path can also stay the same while request or response fields change, so compare the payloads your integrations send and read, not only the URLs.

Test each finding in staging using a service account that matches a production account in roles, permissions and authentication settings. A broader administrator account can hide permission problems that will appear after cutover. Restore a recent production backup into staging, then run each integration's real workflows: posting messages, creating channels, syncing users, opening tickets and installing or updating apps. Compare the results with the behavior you recorded on 7.10. Staging needs its own copies of integration credentials, and tokens used for testing should be rotated or revoked after the exercise so that test secrets do not remain in circulation.

Some clients will need changes. Bots, scripts and connectors that your team owns may need code updates, reviews and a release through your normal change process, so add that work to the plan with named owners. Third-party apps depend on their vendors. Ask each vendor in writing whether the current version supports the target release and when a compatible version will be available. If a vendor cannot confirm support, decide in advance whether the integration will be paused, replaced or kept on a documented fallback. Schedule cutover so that every integration owner is available for the post-upgrade checks and a rollback path has been agreed.

Official mobile and desktop clients should be verified against the chosen target version rather than assumed to keep working. Rocket.Chat notes that unsupported versions may lose the ability to connect with its official clients, so check compatibility for the target release in the Rocket.Chat documentation and in your own test run. Test the client builds your users actually run, including older builds that are still installed on managed devices, against the staging server. Record which versions connect, which features fail, and which users need an update. Then set a minimum client version and a date for communicating it to users before the production cutover.

Before the cutover window opens, run a written test plan against a copy of production in a separate environment, and agree in advance which results allow the upgrade to proceed. For a Rocket.Chat 7 to 8 upgrade moving off the end-of-support 7.10 LTS line, the plan has to cover the paths users and systems touch every day, not only whether the server starts. Give each test an owner, a pass condition, and a record of the exact Rocket.Chat and MongoDB versions it ran against. Run the full plan on the 8.x LTS release you chose, whether 8.5 or 8.9, because results on one line say little about the other.

Start with sign-in. Test every identity path you use, whether LDAP or Active Directory, single sign-on, or multi-factor authentication, with test accounts that include administrators, standard users, and any account whose roles come from group mapping. Then test message and file flows: post, edit, and delete messages in public channels, private channels, and direct messages, and upload and download files from a second account. If end-to-end encryption is in use, confirm that existing users can unlock their keys and that encrypted rooms still read and write after the upgrade. For retention, seed a test room with messages of known age and confirm that the configured policies still purge them as expected.

Next, test what sits outside the web interface. Send notifications through the push gateway to iOS and Android test devices and confirm delivery, because cloud services such as the push gateway stop working once a version reaches end of life. Verify every integration, webhook, and API client your teams rely on against the 8.x release notes, since removed endpoints can break a client without an obvious error. Connect the official mobile and desktop clients to the upgraded server with a fresh login. Finally, restore the production backup into a separate environment, start the target version against it, and confirm the restored data is usable. A backup that has never been restored is an assumption.

Set go and no-go criteria before the window, in writing, and have the service owner and security lead sign them. A go decision should require that every critical test passes, the restore rehearsal completed, the rollback steps were rehearsed on the test copy, and the MongoDB deployment meets the replica set requirements for the 8.x release. Treat any failed sign-in path, lost access to encryption keys, or broken push delivery as a no-go unless the decision owner accepts the risk in writing. Name the person who makes the call and the point at which the team stops and rolls back, so that decision is made before pressure builds during the window.

Rollback has two branches. Restore the database backup when a migration changed data in a way the previous application cannot read, or when data written during the window must be reverted. Redeploy the previous application version when the database is intact and only the new application fails. Before choosing either path, confirm that the previous version and the current database state are compatible, because rolling the application back onto a database it cannot read can make recovery harder. Keep a backup taken immediately before cutover. Take the exact rollback commands and sequence from the official Rocket.Chat and MongoDB documentation for your versions, and run them on the test copy before the window.