Team chat RFP questions for vendors and partners

How to run a team chat RFP for a self-hosted platform

A regulated organization that needs internal chat it controls has to answer two different questions: which platform fits its requirements, and which implementation partner can deploy, harden and support it inside the organization's own infrastructure. An RFP that mixes these together tends to reward the vendor with the best demo and leave the operating model unexamined. Send the same written questions to each platform vendor and to each implementation partner, and ask for answers that name your environment: your identity provider, your database and storage choices, your network zones, and your retention obligations. Generic answers about features are a signal to press further.

This page covers four areas: why Mattermost, Rocket.Chat or Matrix is the right platform for your case, which features require a paid plan, how Slack history is migrated and how mobile push works when the network is restricted, and how retention, export and monthly or otherwise scheduled releases are handled over the life of the system. Treat every paid-plan feature as unconfirmed until the vendor states in writing which edition includes it, which licence terms apply, and what changes if you move between editions. Ask partners to put their responses into the statement of work so that delivery is measured against the same commitments. DeployOpen implements, customizes, hardens, backs up, upgrades and supports self-hosted platforms in the client's environment, and runs security testing and compliance readiness work. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so your RFP should also ask each partner which evidence they produce and which assessor will review it.

Asking which platform fits and why

Mattermost is an open core, self-hosted collaboration platform written in Go and React that runs as a single Linux binary with PostgreSQL as its database. Its compiled binaries are licensed under MIT, while source code for custom builds falls under AGPL v3.0 with a commercial alternative from Mattermost, Inc. Ask the partner which license applies to the exact build you will run and whether any custom plugins change that position.

Licensing: Confirm which component is under MIT, which under AGPL v3.0 and which under the commercial terms, and whether admin tools and configuration files are covered separately.
Edition: Map each requirement to the plan that includes it. SSO and AD/LDAP sync start at Professional, high availability clustering and FIPS 140-3 compliance start at Enterprise, and air-gapped deployment is listed for Enterprise Advanced.
Scaling model: High availability needs redundant application servers, database servers and load balancers, plus shared file storage on S3, an S3-compatible service or NAS mounted on each node. Local storage is not supported.
Read scaling: Ask how database read replicas and search replicas will be sized and monitored, since writes still go to the primary database.
Release cadence: Mattermost publishes a server version on the 16th of each month. Ask which release line the partner will run, for example v11.7 as the Extended Support Release, and how upgrades are scheduled against the support end dates.

Before you sign, ask for the edition list and the support dates in writing, and confirm them against the current pricing and release pages.

Questions to ask on editions, paid features, migration, mobile push, retention and upgrades

Which Mattermost or Rocket.Chat edition do we need for SSO and directory sync?

For Mattermost, SSO (SAML, OIDC, OAuth) and AD/LDAP user sync start at the Professional plan according to its pricing page, while high availability clustering and FIPS 140-3 compliance start at Enterprise. For Rocket.Chat, the free Starter plan includes LDAP, Active Directory, single sign-on and multi-factor authentication, but LDAP and SAML user group mapping and tamper-evident audit trails are listed on its paid plans. A good answer names the exact edition, the documented control for each requirement, and the version tested. Ask the partner to confirm the current tier in writing, because plan contents change and neither vendor publishes prices. Ask the vendor sales team for the quote that follows from that tier.

Can we run the platform ourselves, or do we need a partner for each upgrade?

You can run it yourselves if your team can operate a Linux service, PostgreSQL or MongoDB, and the upgrade cycle. Mattermost ships a new server version in binary form on the 16th of each month, and Rocket.Chat standard releases are supported for 6 months while LTS releases get 12 months. A partner's answer should separate one-time work (planning, build, integration, hardening, documentation) from recurring work (monthly or quarterly upgrades, backups, monitoring, security patching). Ask who performs each step, which staging environment is used to test upgrades, and whether support is fixed-scope or a retainer. DeployOpen plans, implements, upgrades and supports self-hosted platforms in your own infrastructure under written scope.

How do we migrate Slack history into a self-hosted chat platform?

Migration depends on what Slack exports contain and which import tool the target supports. Rocket.Chat's import tools accept full Slack workspace exports, Slack users from CSV, and a CSV importer for other sources. For Mattermost, the migration guide covers the Slack path, and data from other systems is typically converted to the CSV format. A strong answer lists which data moves (channels, messages, files, users, reactions, threads), which does not (integrations, bots, some app data, edited history), and how attachments are stored. Ask the partner to run a dry run on a copy of a real export, record the counts that do not match, and show how users map to directory identities before cutover.

How does mobile push work when the network blocks public push gateways?

Mobile push depends on the vendor's push gateway, and that gateway is a dependency to confirm before you commit. Rocket.Chat notes that cloud services such as the push notification gateway stop working after a version reaches end of life, so push is tied to supported versions. Ask the partner to document whether push leaves your network, what metadata is sent to the gateway, whether message content is withheld from the notification, and how the mobile app connects to your server in a restricted network. Also ask which client versions are compatible with your server release. Test push on a segment that matches your real egress rules before go-live, and record the result.

How do retention and legal hold settings meet regulator export requirements?

Retention is set in the platform, but meeting a regulator's rule depends on the policy, the storage design and the export format. For broker-dealers, the SEC's Rule 17a-4(b)(4) requires preserving originals of communications relating to the business for not less than three years, which means retention must be configured, tested and backed by immutable or archived storage where your policy needs it. Ask the partner which edition provides retention and compliance export, how legal hold works, whether deleted messages and edits are preserved, and how exports are verified. Request a documented restore test. DeployOpen prepares controls and evidence for assessments but does not issue audit reports or certifications.

What does a high availability chat cluster need for storage and databases?

A Mattermost high availability cluster needs redundant application servers, redundant database servers and redundant load balancers, and it is available only on Enterprise and Enterprise Advanced. It also needs shared file storage on Amazon S3, an S3-compatible service or NAS mounted on each node, because local file system storage will not work correctly and risks corrupting files. Database read replicas and search replicas can spread load, with writes going to the primary. Rocket.Chat 8.x requires MongoDB 8.0 or later as a replica set, and its reference architectures move to multiple instances above 500 concurrent users. Ask the partner to show the failover test plan and the recovery results before go-live.

How does federation between organizations get restricted or turned off?

Federation is the setting that decides which other servers your users can talk to. In Synapse, the federation_domain_whitelist setting restricts federation to listed domains, an empty list disables federation, and the documentation recommends also firewalling the federation listener, which defaults to port 8448. Ask the partner to show the allow-list in configuration, the firewall rule that enforces it, and the test that proves a non-listed domain is refused. Also ask how server_name is set, because it fixes how users and rooms are identified and is hard to change later. Matrix federation is a Matrix feature, so Mattermost and Rocket.Chat deployments need their own answer.

How do we keep up with monthly releases and long-term support versions?

Plan for a release calendar with a named owner, a staging environment and a rollback path. Mattermost publishes server versions monthly and lists support end dates for each, including an Extended Support Release, v11.7, with support ending 2027-05-15. Synapse warns that rolling back can be difficult because of database schema changes, and that it drops support for Python and PostgreSQL versions once they reach upstream end of life. Ask the partner which release line is deployed, which versions are tested, how long a release takes to validate, and who signs off the production change. Ask for the written upgrade runbook and the recovery steps if an upgrade fails.

Which features need a paid plan and how to confirm them

Several features that RFP respondents often list as included are tied to specific editions, and the tie differs by platform. On Mattermost, the public pricing page places SSO (SAML, OIDC, OAuth) and AD/LDAP user sync from the Professional plan, high availability clustering and FIPS 140-3 compliance from Enterprise, and air-gapped deployment in Enterprise Advanced. On Rocket.Chat, the free Starter plan includes LDAP and Active Directory authentication, single sign-on, MFA and retention, but air-gapped deployment, multi-instance designs and microservices are paid-plan capabilities, and the reference architectures state that multi-instance and microservice designs require a paid plan. Matrix with Synapse is open source under AGPL-3.0, but clustering through workers, commercial support and some enterprise packaging come from Element as separate offerings, so the edition question is about the support and packaging you buy, not a license gate. The plan names, included features and prices on these pages change, so a statement from a sales call or an older brochure is not evidence.

Require a written feature matrix that names the exact edition and version quoted, and map each requirement from your own list to a line in that matrix: SSO protocol, directory sync, high availability, FIPS mode, air-gapped operation, retention and audit trail depth, and any multi-instance or clustered design you intend to run. Ask the vendor to state which items are included, which are add-ons, and which are only in a higher tier. Request the price as a quote built from that matrix, with seat or user counts stated, and keep the quote tied to the same edition. Ask whether the vendor will confirm each entitlement in writing for your license term, and who verifies it at renewal. Your partner should check that the quoted edition can be installed in your environment before you sign, because some features depend on infrastructure you must also provide, such as shared file storage for Mattermost high availability or a replica set for Rocket.Chat.

Then ask what happens if a feature moves to another tier or is removed from one. Ask whether the vendor guarantees feature parity for the term of your agreement, how much notice is given, and whether a downgrade or lapse disables SSO, MFA, audit logging or clustering on a running system, or only blocks new purchases. Ask how a lapsed subscription affects patches, support access and the ability to upgrade, since Rocket.Chat states that unsupported versions can lose connection to official mobile and desktop clients. Write the answers into the contract or the statement of work. Your partner should record the entitlements in the deployment runbook and set a review date before each renewal, so that a licensing change is found in planning, not during an incident or an audit.

Answers that should worry you in a team chat RFP

Several vendor and partner answers sound reasonable until you test them against an edition, a migration path or a regulator's question. The cards below show where vague replies hide cost, risk or a stalled rollout. Use them to push for named editions, written scope and evidence before you shortlist.

Air-gap or HA without an edition

A proposal that promises air-gapped operation or high availability but does not name the edition or plan that includes it is leaving out the most expensive line. Mattermost ties high availability clustering to its Enterprise plans and air-gapped deployment to Enterprise Advanced, while Rocket.Chat keeps air-gapped deployment on paid plans. Ask which edition is quoted, which features are included in that edition, and what shared file storage and database replicas the design requires.

Slack migration as a one-click import

Treating a Slack migration as a single import ignores that bots, apps and integrations do not move with message history. Rocket.Chat's importers accept full Slack workspace exports and user CSVs, and Mattermost offers its own Slack migration path, but neither carries over custom integrations. Ask for an inventory of bots and webhooks, a rebuild plan for each one, and a test import into a non-production workspace before cutover.

Mobile push design left vague

Push notifications in restricted networks depend on how the mobile apps reach a gateway, and that path is often the hidden dependency of an air-gapped or regulated deployment. Rocket.Chat states that cloud services such as its push notification gateway stop working after a version reaches end of life, so push depends on the vendor's service and on a supported version. Ask how push reaches devices from inside your network, which component carries message content, and what happens when the gateway is unreachable.

Retention described without legal hold

A retention answer that lists a number of days but never mentions legal hold, export format or who can run an export does not meet recordkeeping or discovery needs. For broker-dealers, SEC Rule 17a-4(b)(4) requires preserving communications for not less than three years, so the platform must hold records by policy and export them in a form a reviewer can use. Ask which edition provides retention and legal hold, whether exports are complete for messages, files and edits, and who signs off on each export.

No upgrade plan for short support windows

A chat platform that falls out of support stops receiving security fixes and may stop working with official clients, so the upgrade cadence is an operating cost, not an afterthought. Mattermost publishes a new server version each month, and its Extended Support Releases carry longer support windows than standard releases. Rocket.Chat standard releases get 6 months of support and LTS releases get 12 months. Ask for the named release train, the test environment used before each upgrade, the offline upgrade procedure, and who performs it.

Federation promised without a domain allow-list

Offering Matrix federation or cross-organization chat without a domain allow-list or a firewalled federation listener can expose internal rooms and identities to servers you did not choose. Synapse restricts federation through its federation_domain_whitelist setting, and an empty list disables it, but the proposal must say which setting is used and who maintains the list. Ask how federation is limited to named partners, how user identity is resolved across servers, and how a partner's departure is handled.

How to score answers across vendors and partners

Give each answer a weight before the responses arrive, so vendors and partners are judged on the same criteria. Score the platform and the partner separately, because a strong product can still be delivered poorly, and a capable partner cannot fix a platform that lacks the edition feature you need.

Edition fit and paid features

Score whether each vendor names the exact edition that includes every requirement, such as SSO, LDAP group sync, high availability or air-gapped deployment. Vague answers that say a feature is available without naming a plan should lose points. Mattermost lists SSO and AD/LDAP sync from the Professional plan, while Rocket.Chat's Starter plan includes LDAP, SSO and retention but air-gapped deployment requires a paid plan. Ask for the price basis in writing, since both vendors price by quote.

Migration evidence

Score answers on what gets moved and what does not: channels, users, files, threads, integrations and bots. Ask the partner to show how a Slack workspace export is converted and imported, and which Slack apps stop working after cutover. A response that promises full history without naming the import method and its limits should score low.

Mobile push in restricted networks

Score how push notifications reach devices when the network blocks public gateways. Ask whether the vendor relies on a cloud push gateway, what the platform sends in the notification payload, and whether message content stays on the server. Rocket.Chat notes that its push notification gateway stops working after a version reaches end of life, so ask how that dependency is handled in a closed network.

Retention and export evidence

Score how retention settings, legal hold and export map to the regulation the client must meet. Strong answers name the export format, who can run it, whether exports are tamper-evident and how audit trails of messages, files and sessions are kept. For broker-dealers, check the three-year preservation period in 17 CFR 240.17a-4 against the proposed retention setting.

Upgrade and support cadence

Score the release plan, the support window for each version and the rollback path. Mattermost publishes server releases monthly and marks some as Extended Support Releases, while Rocket.Chat standard releases get 6 months of support and LTS releases get 12 months. Ask the partner how they test each release, how long they hold a version and what happens to mobile client compatibility when a version expires.

Partner delivery and accountability

Score the partner on its own delivery record, separate from the platform. Ask who runs high availability tests, who owns the database and shared file storage, how backups are restored and who responds when a release breaks chat. Require a written scope with named deliverables, acceptance tests and a support model that states response ownership. A partner should explain its own limits, not just the product's strengths.

What a partner should answer that a vendor cannot

A platform vendor can tell you what its software does. An implementation partner has to tell you what your organization will be doing with it after go-live, who does it, and what evidence exists when someone asks. When you score RFP responses, separate the two. Ask the vendor about feature availability and edition boundaries, then ask the partner how they will harden the deployment, test failover, and run the platform through its release cadence. Mattermost ships a new server version on the 16th of each month and designates some releases as Extended Support Releases, while Rocket.Chat standard releases are supported for 6 months and LTS releases for 12 months. A good answer names the release track you will run, who applies each update, which staging environment proves it first, and how long the rollback path stays open.

Ask the partner to describe its hardening baseline in concrete terms: how the database, file storage and reverse proxy are configured, how SSO and directory sync are wired, which admin accounts exist and how they are logged, and how federation is restricted if you run it. For high availability, ask who runs a failover test, what it proves (node loss, database primary loss, shared file storage loss), and who records the result. For offline upgrades, ask how packages and container images reach a disconnected network and how the partner tests a version that has moved past its support window. For retention and export, ask who produces a sample export from a legal hold, who checks it against the retention policy, and where that evidence is stored.

DeployOpen plans, implements, hardens, tests and documents self-hosted platforms inside your own infrastructure, and it prepares controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications; your independent auditor or certification body does that work. Ask any partner, including DeployOpen, to separate those roles in writing. Confirm which of your regulators' expectations the partner's evidence pack covers and which remain your organization's responsibility, and agree on the scope, deliverables and timelines in writing before work starts.

How DeployOpen scopes and delivers a team chat evaluation

DeployOpen starts with a written scope that turns your RFP questions into a short list of platforms to test against your own identity, retention, network and migration requirements. We then build a working proof in your infrastructure, so vendor answers can be checked against real behavior before a decision.

How we scope

Map each RFP question to a requirement owner in security, compliance, IT and the business
Confirm which features your edition must include, such as SSO, retention, export and high availability
Agree the written scope, deliverables and timeline with you before any work starts
Identify which answers must be confirmed with the vendor in writing rather than assumed

How we build

Deploy the shortlisted platforms in your cloud account, data center or air-gapped network
Test SSO and directory sync, retention settings and export paths against your policies
Run a Slack export import on a sample workspace to measure what migrates and what does not
Verify mobile push behavior under the network rules your users actually operate within

How we hand over

Deliver a comparison document that records test results, open questions and vendor confirmations
Provide an architecture, configuration and runbook set for the platform you select
Document upgrade and support-window procedures so your team can plan monthly releases
Prepare compliance evidence for your assessors, which independent auditors then evaluate

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live
Schedule platform upgrades against each vendor's published release and support dates
Retest retention, export and access controls after each significant version change
Keep documentation current so your team can run the platform without vendor dependence

Team chat RFP questions