Mattermost upgrades and support services

What Mattermost upgrades and support involve

Upgrades and support for a self-hosted Mattermost server mean planning each version change, testing your custom components against it, and keeping the server supported after go-live. Mattermost releases a new server version in binary form on the 16th of each month, and it also publishes Extended Support Releases (ESRs) for teams that want fewer upgrades. Your first decision is which track the server follows: the monthly train, which requires an upgrade roughly every month to stay within support, or the ESR track, which trades newer features for a longer support window.

Teams usually start planning an upgrade when a version nears end of support. Current dates from the Mattermost server releases page include v11.11, with support ending 2026-12-15, the ESR v11.7, with support ending 2027-05-15, and v10.11, which reached end of life on 2026-08-15. Security fixes and plugin breakage are the other common triggers. Check the release notes and your plugin list before each change, because a server upgrade can break a custom plugin even when the core product works.

Most organizations with only the default feature set handle routine upgrades in-house, using a staging copy of the server and a documented rollback. Organizations that run several custom plugins, integrations or identity connectors usually bring in a partner for the first few upgrades, because each custom component needs its own test pass. Whether your team can carry this work alone depends mainly on how many custom components the server carries, and on how many people can test them.

Ask any partner for a written scope that lists which release track is covered, which plugins and integrations are tested before each upgrade, how staging and rollback are handled, and whether post-go-live support is a fixed-scope engagement or a recurring retainer. Confirm the current support dates and the upgrade path with Mattermost before you commit, since the dates above are the ones on the release page at the time of writing.

What the service includes

Setup work such as choosing a release track and writing the upgrade path is done once and revisited as versions change. Staging, compatibility testing and the production runbook repeat for every upgrade, and the optional retainer covers ongoing work after go-live.

Release track selection

One-time decision, revisited each planning cycle. Mattermost publishes server releases in binary form on the 16th of each month, and Extended Support Releases such as v11.7 (released 2026-05-15, support ending 2027-05-15) carry a longer support window. Document the choice with reasoning: how quickly your plugins and identity integrations need new features, and how much change your change process can absorb.

Upgrade path document

One-time per target version, updated for each release. It maps every version step from your current build to the target, lists the database migrations each step runs, and records configuration changes. Installations still on v10.11, which reached end of life on 2026-08-15, need a supported path. Confirm the hop order against the release notes before committing to it.

Staging rehearsal and restore test

Recurring, once per upgrade. Run the full upgrade on a copy of production data with matching PostgreSQL, file storage and identity settings. Time each step, capture migration output and restore a production backup into staging to prove the rollback path works. The restore should cover both the database and file storage, since attachments live outside the database.

Plugin and integration compatibility testing

Recurring, once per upgrade. Test every installed plugin, slash command, webhook, bot and external integration against the target version in staging. Check plugin version constraints, API changes and any integration that depends on a changed or removed endpoint. Keep a current inventory with a named owner for each item so compatibility work has someone to answer for it.

Production runbook and post-upgrade checks

Recurring, once per upgrade. The runbook sets the change window, the pre-upgrade backup step, the upgrade commands, the rollback triggers and who makes the rollback decision. Post-upgrade checks cover SSO sign-in, posting, file upload and download, search, notifications, plugin health and scheduled jobs. Record the results so the next upgrade starts from evidence.

Optional support retainer

Recurring and optional. A retainer covers ongoing upgrades on your chosen track, compatibility testing for each release and incident response after go-live. Scope, response expectations and included hours are set in the written agreement, so ask for them in writing. Fees are quoted from the agreed scope and confirmed in that same document.

What drives effort and duration

This table lists the factors that change how large a Mattermost upgrade or support engagement is, why each one matters, and how to keep it down.

Driver	Why it changes effort	How to keep it down
Custom plugins and their state	Each custom plugin must be rebuilt, tested and checked against every new server version. Plugins that are unmaintained or built against old APIs can block an upgrade until they are fixed.	Keep the plugin count small, record the Mattermost version each plugin was built for, and retire plugins nobody owns. Ask for a plugin inventory before quoting.
Integrations (webhooks, bots, SSO, connected systems)	Every webhook, bot and identity link needs a regression check after an upgrade. SSO and directory sync failures are often the slowest to diagnose because they affect login for all users.	Document each integration with its owner, endpoint and test steps. Confirm which identity provider and directory sync setup is in use, since SSO behavior is documented per provider.
Database size and migration complexity	Larger PostgreSQL databases take longer to back up, migrate and verify, and schema changes in a release can require a longer maintenance window. Heavy custom data changes add test cases.	Clean up retention settings before the upgrade, take a verified backup, and rehearse the migration on a copy of production. Ask the partner how restore testing is scheduled.
Single node or high availability cluster	A cluster adds redundant application servers, database replicas and load balancers, and each node must be upgraded and checked in order. Shared file storage on S3, an S3-compatible service or NAS must also be verified on every node. High availability is available only on Enterprise and Enterprise Advanced plans.	Confirm the topology and plan before scoping. Agree on a rolling upgrade order and a failure test for the cluster. Verify that file storage is shared, not local.
Number of environments (development, staging, production)	Each environment needs the same upgrade, plugin rebuild and test pass. Drift between environments creates extra work to find and close differences before production.	Keep staging close to production in version, configuration and plugins. Limit the number of environments to those the organization actually uses and automate the deployment steps.
Commercial plan and support terms	Support scope, response expectations and access to vendor guidance depend on the subscription. Plan features such as SSO, high availability and FIPS-compliant images also change which configuration must be tested.	Confirm the plan, the seat count and the support terms in writing before scoping. Ask the vendor which features are included at your tier so the test plan matches what you have licensed.
Compliance requirements for each change	Frameworks and internal policies may require a change record, test evidence, approval and a rollback plan for every upgrade. Assessors also expect evidence that changes were tested before production. DeployOpen prepares this evidence but does not issue audit reports or certifications.	Agree the evidence list before the first upgrade, such as change tickets, test results, backup proof and approvals. Reuse the same templates for each monthly or ESR upgrade. Confirm the requirements with your assessor.
Gap between current and target version	Mattermost releases a new server version in binary form on the 16th of each month. Upgrading across several releases means more changed behavior, more plugin compatibility checks and more release notes to review. Support windows also matter: v11.11 support ends 2026-12-15, and v10.11 reached end of life on 2026-08-15.	Stay on a supported release, either the monthly train or the Extended Support Release (ESR) line, and upgrade regularly rather than letting the gap grow. Plan the target release against the published support end dates.

Project phases and outputs

The engagement moves from an inventory of the current install through a planned upgrade path, a rehearsal on staging, a controlled production cutover, and a handover that leaves your team with a runbook and a support cadence.

Assess the current installation
DeployOpen reviews the installed Mattermost version, plugins, integrations, PostgreSQL database, and file storage configuration, along with how the server is deployed and reverse-proxied. The client receives a current-state inventory that lists each component, its version, its owner, and any custom code or integration that depends on it. The step closes when the client has confirmed the inventory matches their environment.
Choose the release track and plan the upgrade path
Together, the client and DeployOpen decide whether to stay on the monthly release train or move to an Extended Support Release, based on the support end dates published for each version. The team then maps the sequence of intermediate versions and database steps needed to reach the target. The client receives a written upgrade path with target version, support dates, rollback approach, and open decisions. Confirm current release dates on the Mattermost release page before signing off.
Rehearse the upgrade on staging with plugin tests
DeployOpen builds a staging copy from a recent production backup and runs the planned upgrade steps on it. Each plugin, integration, and SSO login is tested against the target version, and any breaking changes are logged with a fix or a decision. The client receives a rehearsal record with timings observed on staging, a list of plugin results, and a go or no-go recommendation. Timing in production depends on the scope agreed in writing.
Execute the production change window and cutover
In an agreed change window, DeployOpen takes a verified backup, applies the upgrade steps exactly as rehearsed, restarts services, and confirms the application responds through the load balancer or proxy. If a check fails, the team follows the rollback plan agreed in the upgrade path. The client receives the change log with start and end times, the backup reference, and the sign-off record from the client's change approver.
Verify the upgraded environment
After cutover, DeployOpen checks sign-in through SSO, message posting, file upload and download, search, notifications, plugin behavior, and integration webhooks against a written test list. Logs and the admin console are reviewed for errors. The client receives a verification report that records each test, its result, and any issues left open with an owner. The step is complete when the client accepts the report.
Hand over the runbook and support cadence
DeployOpen delivers a runbook covering the upgrade procedure, backup and restore steps, plugin update checks, and escalation contacts, then walks the client's operations staff through it. The agreed support cadence, such as regular release reviews and patch windows, is documented with responsibilities for each side. The client receives the runbook, the cadence document, and a record of the handover session. Support fees and their scope follow from the written agreement.

What teams keep in-house and what they outsource

This table shows which upgrade and support tasks usually stay with the client's own staff and which are commonly handed to a partner, with the skills each task needs, so readers can see where their own team has gaps.

Part of the work	Usually kept in-house	Commonly outsourced	Skills needed
Change window approval	Yes, the operations or change board approves each window and its risk	No, the partner proposes timing but the client approves it	Change management, knowledge of business peak periods
Business owner sign-off	Yes, the owner of each team using Mattermost accepts the upgrade and any downtime	No, the partner supplies test evidence for the owner to review	Business ownership, risk acceptance, communication with leadership
Day-to-day administration	Yes, the internal team manages users, channels, teams and routine server tasks	No, unless a retainer covers administration on the client's behalf	Linux administration, Mattermost System Console, mmctl
User communication	Yes, internal staff announce maintenance, new features and changes in workflow	No, the partner can draft notices but the client sends them	Internal communications, change messaging, support desk handover
Release assessment	Client reviews the partner's findings and decides whether to adopt a release	Yes, the partner reads release notes and maps changes to the client's configuration and plugins	Mattermost release model, Go and React awareness, Extended Support Release policy
Upgrade path design	Client confirms the target version and acceptable downtime	Yes, the partner plans the route, including any stops needed from the current version	PostgreSQL operations, Mattermost version compatibility, Linux administration
Plugin compatibility testing	Client supplies plugin owners and approves any plugin removal	Yes, the partner builds test cases and checks each custom or third-party plugin against the target version	Go or React plugin development, API knowledge, regression testing
Staging rehearsal and runbook writing	Client provides a staging environment that matches production and signs off the runbook	Yes, the partner rehearses the upgrade, records timings and writes the step-by-step runbook and rollback steps	PostgreSQL backup and restore, Linux administration, scripted deployment
Post-upgrade checks and retainer monitoring	Client confirms business functions work and monitors daily use	Yes, the partner runs post-upgrade checks and, under a retainer, monitors server health and logs	Observability tooling, PostgreSQL performance tuning, incident response

What goes wrong and how to prevent it

Most Mattermost upgrade problems come from timing, untested changes and missing recovery steps. Each risk below has a prevention step your team can check before and after every upgrade.

Running past end of support

Monthly releases and Extended Support Releases both stop receiving support on fixed dates. For example, v11.11 supports through 2026-12-15 and the v11.7 ESR through 2027-05-15. Record each version's end date in your upgrade calendar, and choose the next target before the current version reaches its date. Confirm dates on the official releases page.

Plugins that break on new servers

Custom and third-party plugins can fail to load, stop working or change behavior after a server upgrade. Keep an inventory listing each plugin's source, owner and current version. Before each upgrade, test every plugin against the target server version in staging, and confirm that its maintainer has published a release for that version.

Migrations without a tested rollback

Database migrations in a new server version may not be reversible, so a verified backup is often the only way back. Take a fresh PostgreSQL backup immediately before the upgrade, and restore it to a separate host to prove it works. Confirm in the official documentation for each target version whether its migrations can be reversed, and write the restore steps down before the window opens.

Skipping staging rehearsal

Upgrading production first leaves no place to find plugin conflicts, configuration changes or slow migrations. Copy production's database and file storage into staging, run the full upgrade there, and test SSO sign-in, file uploads, integrations and mobile clients. Record how long each step takes, and base the production window on those measurements.

Upgrading cluster nodes out of sequence

In a high availability cluster, nodes running different server versions can behave inconsistently or fail during migrations. Follow the node order in the official upgrade guidance for your target version, and upgrade one node at a time. Confirm that each node reports the target version and passes health checks before you move to the next. Check the documented mixed-version rules for your release.

Treating custom builds as stock binaries

Mattermost licenses its compiled binaries under MIT, but source code for custom builds falls under AGPL v3.0 unless you hold a commercial agreement with Mattermost, Inc. Track every patch and fork so you can rebuild from the exact source. Ask counsel to confirm what your modifications and hosting arrangement require before you offer the build to users.

How the work changes by starting point

Mattermost publishes a new server version in binary form on the 16th of each month, so a monthly track means a steady cadence of small upgrades rather than occasional large ones. Each cycle is smaller in scope, but it still needs a planned window.

Plugin test cycle: Each monthly release needs a check of every installed plugin and custom integration against the new version before production.
Recent release dates: v11.11 was released on 2026-09-16 with support ending 2026-12-15, and v12.0 was released on 2026-10-16 with support ending 2027-01-15.
Short support windows: Confirm with your team how long each monthly version stays supported, because the window determines how soon you must move.
Staffing: Assign a named owner for the monthly check so it does not depend on whoever is available that week.
Pre-upgrade backup: Take and test a database and file backup before each upgrade window.

What the client needs to provide

Before any upgrade or support work begins, the client must supply a set of access rights, records and decisions. Without them, the first weeks of an engagement go to discovery instead of change, and a fixed-scope timeline cannot hold. The items below are the ones we need in writing before scope is signed.

Access and records. The client's platform or infrastructure team owns administrator access to the production and staging Mattermost servers, the PostgreSQL database and the file storage backend. Staging should run the same Mattermost version and plugin set as production so that upgrade testing is meaningful. Ask your team to confirm that the staging environment is a true copy, and to name who holds the database credentials and the file storage keys.

Next, the client owns a current inventory of installed plugins and integrations, each with a named technical owner and a business owner. Plugins are the most common cause of blocked upgrades, so this list drives the compatibility test plan. The client also supplies a recent backup and a documented restore record showing that the backup was restored successfully on a separate system. A backup that has never been restored is not evidence.

Finally, the client confirms its Mattermost subscription or license status and support entitlement, including the plan tier and seat count. Entitlement determines whether Extended Support Release tracks are available and what vendor support can be used during an upgrade. Procurement or the account owner should also name a business owner who approves change windows, and share the maintenance window policy and the decision on release track, either the monthly release or an Extended Support Release. If any item is missing, we flag it as a scope risk, pause the upgrade plan at the discovery stage, and agree in writing who will close the gap and by when.

Questions buyers ask before hiring help

How much does a Mattermost upgrade cost and what affects the quote?

The cost follows from the work in scope, and DeployOpen does not publish a price list. A quote is built from a written, fixed-scope statement of work. The main components are upgrade planning, a staging rehearsal, plugin and integration testing, the production change with rollback preparation, and post-upgrade verification. Costs rise with the number of servers, custom plugins, SSO and cluster configuration, and the number of environments that need testing. Ask for each component to be priced separately, and ask which items are one-time and which recur. Mattermost subscription fees are a separate cost, quoted by Mattermost sales.

How long does a Mattermost upgrade take from start to finish?

The duration is set once the scope is known, and the drivers are clear. They include the number of nodes, database size, custom plugins that need retesting, the cluster and file storage layout, and how quickly your team approves test results and change windows. To keep the schedule moving, provide a copy of your environment for testing, named approvers, a maintenance window, a list of active plugins and integrations, and recent backups of the database and file storage. Mattermost publishes server releases on the 16th of each month, so your timing also depends on the target version and how far behind you are.

Can our own team upgrade Mattermost without a partner?

Yes, for a simple single-node server with no custom plugins, a capable Linux administrator can usually handle the upgrade using the release notes and a staging copy. The skills needed are Linux service administration, PostgreSQL backup and restore, reverse proxy and TLS configuration, and reading release notes for breaking changes. The risks are a failed database migration, a lost file storage mount, plugins that stop loading, and no tested rollback. Bring in a partner for high availability clusters, custom plugins, SSO changes or several environments, because each adds failure points that need testing.

Which Mattermost release track should we choose, monthly or ESR?

Choose the monthly track if your team can absorb frequent upgrades and wants new features sooner. Choose an Extended Support Release if you need a longer support window and fewer upgrade cycles. Monthly server versions are released on the 16th of each month, and each has a published support end date. As illustrative examples from the release calendar, v11.11 was released on 2026-09-16 with support ending 2026-12-15, and v12.0 was released on 2026-10-16 with support ending 2027-01-15. The ESR v11.7 was released on 2026-05-15 with support ending 2027-05-15. Check the current release table before deciding, because support dates follow the published calendar.

What does ongoing Mattermost support cover compared with a one-off upgrade?

A one-off upgrade covers one agreed change: planning, testing, the production move and handover. Ongoing support is a retainer for work that recurs. It can include applying each monthly or ESR release on your schedule, retesting plugins and integrations, reviewing backups and running restore tests, and handling incidents under agreed terms. DeployOpen offers retainers for continuous support, and their scope and terms are set in writing before work starts. Ask for the list of included tasks, what is excluded, and how requests outside that list are quoted.

Is DeployOpen an official Mattermost partner?

No. DeployOpen is a Chainscore Labs company that plans, implements, customizes, hardens, backs up, upgrades and supports self-hosted open-source platforms inside the client's own infrastructure, and Mattermost is one of those platforms. DeployOpen does not hold official Mattermost partner status. Confirm any vendor status claim directly with Mattermost before you sign, and ask your potential partner to show the written scope for the work you need.

How DeployOpen scopes, delivers and supports this work

DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including Mattermost upgrades on the monthly release train or on Extended Support Releases. Every engagement starts from a written scope that sets out the upgrade path, the plugins in use and what support covers after go-live.

How we scope

We confirm your current Mattermost server version, release channel and whether you follow monthly releases or an Extended Support Release.
We inventory plugins, integrations, identity settings and database and file storage so each one is covered by the upgrade test plan.
Engagements are fixed-scope, so the written scope names the target version, the environments included and the deliverables before work starts.

How we build

We plan the upgrade path against the published Mattermost support end dates for the versions involved, then sequence each step in a staging copy.
We test each plugin and custom integration against the target version before any production change, and record the results for your team.
We back up the PostgreSQL database and file storage before each upgrade step, and document the rollback procedure we run during testing.

How we hand over

You receive an upgrade runbook covering pre-checks, the upgrade steps, post-upgrade verification and the rollback path for your environment.
Test results, plugin compatibility notes and configuration changes are documented so your administrators can repeat the process without us.
We walk your operations and administration staff through the runbook and confirm which upgrade tasks stay with your team after handover.

How we support

Ongoing support, upgrades and testing after go-live are available as a retainer, with the covered versions and response arrangements written into the agreement.
Retainer support can cover planning the next monthly or ESR upgrade, retesting plugins and reviewing release notes against your configuration.
Confirm with us what the retainer includes, which environments it covers and how urgent production issues are raised before you sign.

Mattermost upgrades and support