When Rocket.Chat is a Wickr alternative and when Wickr fits better
If your renewal is coming up, or your plan requires chat to run inside your own environment, the choice between WickrGov and self-hosted Rocket.Chat turns mostly on who operates the platform and where the keys and servers must sit. WickrGov in GovCloud fits best when you want AWS to run the service inside an authorization boundary you can already assess, and when your team prefers a managed service to patching, scaling and backing up a chat stack. Self-hosted Rocket.Chat fits better when you need direct control of servers, databases and key handling, or when the network must stay disconnected from public cloud services, which is the scenario Rocket.Chat's on-premises, air-gapped and sovereign deployment options are built for.
Three questions should drive the decision. First, which accreditation does your program require, and does WickrGov's authorization status cover the users, data classification and network you actually have? Confirm the current authorization documents with AWS rather than relying on this page. Second, who will operate the platform after go-live: an internal platform team, a managed provider, or a mix? Rocket.Chat's own guidance treats regular upgrades as part of running it, since unsupported versions can lose connectivity to the official mobile and desktop clients. Third, which deployment models does the plan allow? Air-gapped deployment is a paid-plan capability and is not available on the free Starter tier, so the Government or Defense plan terms must be confirmed in writing before you commit to an architecture.
Write these answers into the scope before comparing features or prices. A written list of required accreditations, named operators, and permitted deployment models will eliminate options early and make the cost comparison in the later sections meaningful. Where the answer is "both," for example a managed Wickr network for unclassified coordination alongside a disconnected Rocket.Chat instance for a field unit, plan for two sets of users, retention rules and administrators rather than assuming one platform covers everything.
Which scenarios favor WickrGov and which favor self-hosted Rocket.Chat
This table matches six common government and defense conditions to the platform that usually fits best. Read each row with its condition, since the advantage often depends on hosting rules, user count and whether your team can run the platform.
| Scenario | Better fit | Why |
|---|---|---|
| Team already standardized on AWS GovCloud | WickrGov in GovCloud | Existing GovCloud accounts, procurement and access processes shorten setup. Confirm current WickrGov features and authorization scope with AWS. |
| Air-gapped or disconnected unit | Self-hosted Rocket.Chat on a Government or Defense plan | Air-gapped deployment is a paid-plan capability and is not available on Starter. Confirm offline update and licensing steps before purchase. |
| Sovereign hosting mandate | Self-hosted Rocket.Chat on a Commercial, Government or Defense plan | Rocket.Chat lists sovereign deployments on paid plans, so data stays in the hosting environment you choose. Confirm the mandate's wording with your legal team. |
| Small evaluation team | Rocket.Chat Starter (free self-managed) | Starter is free for evaluation and small teams, allows up to 50 users and includes end-to-end encryption. Moving to air-gapped use requires a paid plan. |
| Large multi-site rollout | Assess both, with Rocket.Chat needing a paid plan at scale | One instance with a MongoDB replica set suits up to 500 concurrent users. Multi-instance and microservice designs require a paid plan, so price them in the written scope. |
| No in-house platform operators | WickrGov in GovCloud, or Rocket.Chat with a support retainer | Rocket.Chat needs MongoDB replica sets, regular upgrades and patching. DeployOpen offers ongoing support as a retainer if you keep Rocket.Chat. |
Where Rocket.Chat data lives compared with Wickr's hosted model
Wickr runs as a service that AWS operates, while Rocket.Chat is software you install in your own cloud account, data center or air-gapped network. The cards below cover where data sits, who holds the keys, how identity and audit work, how the license terms differ and what evidence an assessor will ask for.
Where messages and files sit
With AWS Wickr, message and file storage is part of the hosted service in the AWS environment you select. With Rocket.Chat, the server, its MongoDB replica set and any file storage are components you place yourself, whether in a cloud account, a data center or a disconnected enclave. Confirm the exact data residency terms for WickrGov with AWS, then map each Rocket.Chat component to a location your authority accepts.
Who holds the server and database keys
In a hosted service, the provider operates the infrastructure and key management under its shared responsibility model. In a self-hosted Rocket.Chat deployment, your team controls the host operating system, the MongoDB data, the backups and the encryption keys that protect them. Decide who holds administrative access, how key rotation works and whether any vendor support staff can reach the database.
Identity integration on the Starter plan
Rocket.Chat's free Starter plan includes LDAP and Active Directory authentication, single sign-on and multi-factor authentication, with a 50-user limit. Confirm that your identity provider, group structure and MFA method work with those features before you commit. Ask the Rocket.Chat team which SAML user group mapping features sit on paid plans if your directory relies on them.
Audit trails in paid plans
Rocket.Chat's paid Commercial, Government and Defense plans list tamper-evident audit trails covering messages, files and sessions. Wickr's audit and retention behavior differs, so compare what each records and who can read it. Test your audit requirements against a pilot workspace, because a feature listed on a pricing page still needs to match your evidence format.
Open-source core and enterprise license
Rocket.Chat code outside its enterprise directories is MIT-licensed, while code under the ee directories falls under the Rocket.Chat enterprise license. Your legal team should identify which features you use, such as LDAP group mapping or audit trails, and whether they sit in the MIT core or in the enterprise code. This determines what you may modify, redistribute or run without a commercial agreement.
Compliance evidence and attestations
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and independent auditors or certification bodies do that work. Wickr's own compliance attestations must be requested from AWS for the specific service and region. Build an evidence list for the Rocket.Chat deployment, then match it against the assessor's control set before the assessment starts.
Capabilities of Wickr and Rocket.Chat side by side
This table compares the main capabilities of AWS Wickr with Rocket.Chat for government and defense teams. Where the researched facts do not cover a Wickr capability, the cell tells you what to confirm with AWS before deciding. The main takeaway is that Rocket.Chat's identity, encryption and audit controls are documented by plan, so the check you need to make is which plan and deployment model meets your requirements.
| Capability | AWS Wickr (commercial) | Rocket.Chat (open source) |
|---|---|---|
| End-to-end encryption | Confirm with AWS which WickrGov or Wickr tier and client platforms include end-to-end encryption and how keys are managed | Available on the free Starter plan, per Rocket.Chat's plans documentation |
| LDAP and Active Directory | Confirm with AWS whether directory sync is available in your WickrGov configuration | Included on the free Starter plan, which allows up to 50 users |
| Single sign-on and MFA | Confirm with AWS the supported identity providers and MFA options in your GovCloud tenant | Single sign-on and multi-factor authentication included on Starter |
| Message retention | Confirm with AWS retention options and whether they apply to all clients and networks | Retention included on Starter; confirm settings for your compliance period |
| Audit trails | Confirm with AWS what audit logs cover messages, files and sessions, and how they are exported | Tamper-evident audit trails of messages, files and sessions on paid plans |
| Automated failover and high availability | Confirm with AWS the redundancy model and service level terms for your region | Built-in redundancy with automated failover on paid plans; reference architectures scale from one instance up to 500 concurrent users |
| Importing existing chat history | Confirm with AWS whether any migration or import path from other chat tools exists | Imports full Slack workspace exports, Slack users from CSV and a CSV importer for other sources |
| Air-gapped and sovereign deployment | Confirm with AWS the self-hosted Wickr Enterprise and GovCloud options that match a disconnected network | Air-gapped deployment is a paid-plan capability, not available on Starter |
How Rocket.Chat deployments differ for connected, air-gapped and sovereign networks
A connected deployment runs Rocket.Chat in your cloud account or data center with normal outbound access for patches, mobile push and integrations. This is the simplest model to start with, and it is where most evaluation work happens. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, so the database tier is a planning item from day one.
- Database: MongoDB 8.0 or later as a replica set. Rocket.Chat recommends a three-member replica set for high availability.
- Packaging: Node.js is bundled in the official Docker image and Helm chart, so you do not install it separately for those methods.
- Scale: A single instance with a MongoDB replica set fits the reference architecture guidance up to 500 concurrent users. Multi-instance designs linked by NATS and microservices on Kubernetes require a paid plan.
- Upgrades: Standard releases are supported for 6 months and LTS releases for 12 months. After end of life, a version gets no security or bug fixes.
- Mobile clients: Unsupported versions can lose the ability to connect with official mobile and desktop clients, so upgrades are an operating task.
Confirm your planned user count against the reference architecture tiers, and confirm which release line your organization will track before you size the database.
An air-gapped deployment runs with no route to the public internet. Rocket.Chat lists air-gapped deployment as a capability of its paid Commercial, Government and Defense plans, and it is not available on the free Starter plan. You will move software, patches and container images across the gap through your own approved transfer process.
- Plan: Air-gapped deployment requires a paid plan. Starter is not an option for this model.
- Database: The same MongoDB 8.0 or later replica set requirement applies. Keep the replica set on internal hosts and plan for offline backups.
- Supply chain: Build an internal registry or package mirror so that container images, Helm charts and Node dependencies can be imported and verified before installation.
- Upgrades: Each standard or LTS release reaches end of support on the published schedule, so plan a repeatable import cycle for every release you adopt.
- Cloud services: Services such as the push notification gateway, Marketplace and Omnichannel integrations depend on connectivity and stop working after end of life, so expect reduced functionality.
Ask Rocket.Chat which plan and licensing terms cover your exact air-gapped configuration, and ask how its release bundles are delivered offline.
Sovereign hosting keeps the platform, data and operators under a jurisdiction and administrative control your organization or government defines. Rocket.Chat states that its Commercial, Government and Defense plans support sovereign deployments. The technical stack is the same as the other models, so the differences lie in who runs it, where it sits and how changes are approved.
- Operators: Decide whether your own staff, a cleared contractor or a local partner runs the MongoDB replica set, the Rocket.Chat instances and the upgrade process.
- Location: Choose data centers and backup sites within the required jurisdiction, and document which personnel can reach the database.
- Plan: Confirm with Rocket.Chat that the Government or Defense plan covers your sovereignty terms, since plan features differ.
- Upgrades: Track the 6-month standard and 12-month LTS support windows, and schedule approvals so that no deployed version runs past end of life.
- Evidence: Keep change records, release notes and configuration baselines to support assessments by your own authority.
Confirm the sovereignty terms in writing with Rocket.Chat and your accreditation authority before you select an operating model.
What a self-hosted Rocket.Chat deployment costs beyond the license
The plan fee is only one line in the cost of a Rocket.Chat deployment, and Rocket.Chat prices its Commercial, Government and Defense plans by quote. Ask the vendor for a written quote that states which plan covers air-gapped or sovereign operation, whether the price scales with users or instances, and what support and upgrade terms are included. The free Starter plan covers up to 50 users with LDAP, single sign-on, multi-factor authentication and end-to-end encryption, but air-gapped deployment is not available on it, so a classified or disconnected network needs a paid plan from the start. Your own infrastructure costs come next: application nodes, a MongoDB 8.0 or later replica set (a three-member set is strongly recommended for high availability) and storage sized for message and file retention. Those servers, their hypervisor or cloud spend and the storage tier recur every month and grow with user count and retention period. Scale changes the architecture and the bill. Rocket.Chat's reference architectures describe one instance with a MongoDB replica set up to 500 concurrent users, load-balanced instances linked by NATS above 500, and microservices on Kubernetes using the official Helm chart above 5,000. The multi-instance and microservice designs require a paid plan, so the plan tier and the user forecast should be decided together. Kubernetes adds cluster operations, and backup, monitoring and log retention need their own tooling and storage. Confirm which of these the quote includes and which remain your team's cost.
The largest cost that is easy to miss is people. Rocket.Chat states that unsupported versions may lose connection to the official mobile and desktop clients, and standard releases are supported for 6 months while LTS releases are supported for 12 months, so someone must plan and test upgrades on that cycle. Budget for staff time to apply patch releases, rehearse MongoDB upgrades, restore from backups and monitor replica set health. One-time costs include planning the architecture, migrating users and history (Rocket.Chat imports Slack exports, with files split under 15 MB), configuring SAML group mapping and hardening. Recurring costs include the plan fee, infrastructure, backup storage, monitoring and upgrade labor. In a quote, ask for each of these as separate line items, the named support hours, and who performs upgrades and restore tests.
What moving from Wickr to Rocket.Chat involves, step by step
This sequence turns a Wickr network into a Rocket.Chat workspace that your own team operates, with retained history, mapped rooms and access rules, and a tested cutover. Each step ends with a check you can review before moving on.
Confirm what Wickr can export
Ask AWS, in writing, which Wickr data can be exported from your network (messages, files, memberships, retention settings), in what format, and who must run the export. Your Wickr administrator and your compliance lead should own this request, because the answer decides what history you can carry over. Record the answer, including any data that cannot leave the service, in the migration plan. Done when you have a written statement from AWS and your compliance lead has signed off on which history is kept, archived or discarded.
Decide the history and retention policy
Choose which conversations, files and time ranges move into Rocket.Chat, and which stay in an archive under your existing records rules. Involve legal, records and security owners, because retention obligations in regulated and government settings usually decide this, not the chat team. Document the decision per room type. Done when each category of Wickr data has a named disposition: import, archive or delete, and an owner for it.
Build the target Rocket.Chat environment
Deploy Rocket.Chat in your own infrastructure with the MongoDB replica set the system requirements call for, and choose the plan that covers your deployment model, since air-gapped and multi-instance designs need a paid plan. Set up authentication, retention and backup before any user data arrives, and confirm the version you install is in a supported release line. Done when a test workspace runs, backups restore successfully and an administrator can sign in with your identity provider.
Write the conversion mapping and test import
Create a written mapping from each exported Wickr object to a Rocket.Chat target: users to accounts, rooms to channels or private groups, memberships to roles, and attachments to uploads. Rocket.Chat's import tools cover full Slack exports, Slack users from CSV and a generic CSV importer, so convert the Wickr export into one of these formats and state the conversion rules in the mapping. Load a representative sample into a staging instance, review the results against the source, and fix the mapping before any full run. Done when a staging import matches the mapping and a reviewer has signed off on the sample.
Re-create rooms and access rules
Rebuild the channel structure, membership, moderator roles and permissions in Rocket.Chat according to the mapping, rather than copying Wickr security groups one for one. Confirm that private rooms stay private, that only the intended owners can manage membership, and that retention rules apply to the imported history. Done when a access review of a sample of rooms matches the approved access matrix.
Enroll users and connect identity
Connect Rocket.Chat to your directory or single sign-on provider, then enroll users and their devices through that identity path. Enable multi-factor authentication and confirm the official mobile and desktop clients connect to your server. Rocket.Chat lists LDAP and SAML user group mapping as paid-plan features, so confirm which features your plan includes before you design the group mapping. Done when a pilot group signs in through the identity provider on each client type and receives messages.
Run both platforms in parallel
Operate Wickr and Rocket.Chat side by side for a period agreed in your plan, with a clear rule for which platform carries sensitive conversations during that time. Track adoption, missed messages, client issues and any gaps in history, and log each issue with an owner. The length of the parallel period is a decision for your governance owners, not a fixed figure. Done when the pilot groups and the remaining users have reported no open blocking issues against the agreed exit criteria.
Retire Wickr and keep the evidence
Cut users over, set Wickr to read-only or disable it according to your records plan, and archive the export, mapping, test results and access reviews. Confirm with AWS how the service and remaining data are closed in your account. Keep the evidence in your own records system, because it supports later compliance reviews. Done when Wickr access is removed, the archive is verified and the decommissioning record is approved.
What to confirm with AWS and your own environment before deciding
Start with the questions the supplied facts cannot answer, because they decide whether either option is eligible at all. Ask your AWS account team which WickrGov in GovCloud boundary covers your workload, what accreditation status applies to that boundary today, and whether it matches the impact level your authority to operate requires. Do not assume that a commercial Wickr configuration carries the same status as WickrGov. Also ask AWS how message retention is set, what export options exist for records, and whether exports include calls, files and deleted content. Get the answers in writing and have your records officer check them against your retention schedule. Your accreditation authority, not the vendor, decides whether the boundary is acceptable for your data.
On the Rocket.Chat side, confirm the scope of the Government and Defense plans with Rocket.Chat sales before you plan around them. Ask which features are included in each plan, which deployment models are covered (on-premises, air-gapped or sovereign), and whether the enterprise code under the ee directories ships with the air-gapped build. Ask for the support terms for disconnected networks: how offline license validation works, how security patches reach a network with no internet access, and who is responsible for moving signed artifacts across the boundary. Then ask about upgrade commitments. Rocket.Chat's version support windows and end-of-life effects are documented, but how they apply to your contract, your mobile client compatibility and your change control process is a question for the vendor and your own operations team.
Finally, check the items only your environment can answer. Confirm who will run the MongoDB replica set, the upgrade cadence and the backup and restore tests, and whether your staff or a partner such as DeployOpen will carry that work. Confirm that your hosting environment and key management meet your authority's requirements, and that your identity provider can supply the group mapping and multi-factor settings you need. Use a short proof of concept with a representative user group and a sample of real but non-sensitive records to test migration and export before any commitment. Record each answer with its owner and date, so the decision rests on documented evidence rather than on assumptions made during procurement.
Questions buyers ask about moving from Wickr to self-hosted Rocket.Chat
What does it cost to move from Wickr to self-hosted Rocket.Chat?
Rocket.Chat's free Starter plan is self-managed and allows up to 50 users, but air-gapped deployment and multi-instance designs need a paid plan, and those plans are priced by quote. Total cost has four parts: the software license tier, the infrastructure (application servers, a MongoDB replica set of three members for high availability, storage and backups), the people who build and operate it, and the migration work itself. Wickr costs are per-user plans and add-ons, so compare them with the same user count, retention needs and environment. Ask Rocket.Chat for a written quote for the Government or Defense plan that matches your deployment model, and ask any implementation partner for a fixed-scope quote tied to that plan.
How long does a Wickr to Rocket.Chat migration take?
No migration duration is published in the sources for this page, so treat any number you hear as unverified until it is tied to a written scope. The duration depends on the number of users, how much history you need to carry over, whether you run both platforms side by side, how many channels map to existing Wickr security groups, and how long your accreditation or change control takes inside your environment. Rocket.Chat's Slack importer and CSV importer can move content from other sources, but Wickr exports will need to be converted to a supported format first, so confirm that conversion path early. Ask for a schedule broken into discovery, build, import test, pilot and cutover.
What does our own team need to provide during the migration?
Your staff must own identity, network and approval decisions, because those drive most of the setup. Expect to supply directory access for LDAP or Active Directory, single sign-on configuration, the certificates and DNS names for the service, and the network segments where MongoDB and Rocket.Chat will run. Someone must also decide retention policy, the channel and group structure, and who may create rooms. Security and compliance staff should review audit trail settings and key handling, since end-to-end encryption in Rocket.Chat has its own setup and user enrollment steps. Ask any partner to list these inputs in the written scope so that your team's time is planned before work starts.
Can our own staff run Rocket.Chat without an outside partner?
Yes, if your team has Linux, container and database operations skills and can commit to regular patching. Rocket.Chat 8.x requires MongoDB 8.0 or later running as a replica set, Node.js is bundled in the official Docker image and Helm chart, and reference architectures move from one instance to load-balanced instances linked by NATS and then to Kubernetes with the official Helm chart as user counts grow. Multi-instance and microservice designs require a paid plan. Be honest about the ongoing work: backups, failover testing, monitoring and upgrades are continuing tasks, not a one-time setup. If that capacity is not in place, a retainer for ongoing support and upgrades is an option to scope in writing.
Does Rocket.Chat support air-gapped deployment, and on which plan?
Yes, Rocket.Chat offers air-gapped deployment, but it is a paid-plan capability and is not available on the free Starter plan. Rocket.Chat's pricing page describes Commercial, Government and Defense plans that support on-premises, air-gapped and sovereign deployments, so confirm the exact feature set on the Government or Defense plan before you commit. In a disconnected network, plan for offline installation media, internal package mirrors, certificate authority trust, and how updates will reach the environment. Ask Rocket.Chat to confirm in writing which plan, which components and which push notification and cloud-linked features work when there is no outbound connectivity.
How do upgrades work given the 6-month and 12-month support windows?
Standard Rocket.Chat releases are supported for 6 months and LTS releases for 12 months. After end of life, a version receives no security or bug fixes, and cloud services such as the push notification gateway, Marketplace and Omnichannel integrations stop working. Unsupported versions may also lose the ability to connect with the official mobile and desktop clients. In practice, you must schedule upgrades within each support window, test them in a staging copy that mirrors production, and back up MongoDB before each change. Choosing an LTS line lengthens the window between required upgrades, but it still requires a planned upgrade cycle. Ask for the upgrade procedure, testing responsibilities and the cost of each upgrade cycle in your quote.
What security features does Rocket.Chat provide compared with Wickr?
Rocket.Chat's free Starter plan includes LDAP and Active Directory authentication, single sign-on, multi-factor authentication, end-to-end encryption, retention and read receipts. Paid Government and Defense plans add LDAP and SAML user group mapping, tamper-evident audit trails of messages, files and sessions, and built-in redundancy with automated failover. Wickr's security model is different, so compare them on the controls your assessors require, such as key ownership, retention, audit evidence and who can administer the system. Ask Rocket.Chat and your own security team to map each control to your requirement, and check which end-to-end encryption features apply to group rooms and file sharing in your configuration.
How DeployOpen helps evaluate, implement and migrate Rocket.Chat
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For AWS Wickr vs Rocket.Chat, we work from a written scope that covers the deployment model, identity integration, data import and the upgrade routine your team will own.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which Rocket.Chat plan, deployment model and network boundary the work covers, including any air-gapped requirement.
- We document which Wickr features you use today, such as federation, retention and security groups, so nothing is assumed to carry over.
How we build
- We deploy Rocket.Chat with MongoDB as a replica set in your environment, sized to the reference architecture that matches your user count.
- We configure identity integration, including LDAP, Active Directory or SSO, and multi-factor authentication, against your own directory.
- We test end-to-end encryption behavior, retention settings and data import from a sample export before any production cutover.
How we hand over
- Handover includes runbooks for upgrades, backups, restores and the end-of-life dates for the Rocket.Chat release line you run.
- We deliver configuration records, network diagrams and the evidence your compliance assessor will ask for, without issuing any audit opinion.
- Your administrators are trained on user onboarding, plan-specific features and how to plan regular patch upgrades.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover scheduled upgrades to supported Rocket.Chat versions, so the instance does not reach end of life unnoticed.
- Ask any provider to confirm in writing which versions, environments and response expectations a retainer includes before you sign.
