Why a self-hosted Slack alternative is a sovereignty decision for EU teams
An EU compliance or IT lead looking at Slack's data residency terms usually faces one question: can personal data about staff and their conversations leave the EU, and who can compel access to it? Self-hosted chat in an EU datacenter or with an EU provider can keep messages, member profiles and analytics under your organization's control, and the answer then depends on your own configuration and contracts rather than on a vendor's regional options. The legal baseline is GDPR Article 44, which requires every transfer of personal data to a third country, including onward transfers, to meet the conditions in Chapter V. The EDPB Guidelines 05/2021 treat remote access from a third country, even just displaying data on a screen for support, as a transfer, so administrator access from outside the EEA matters as much as where storage sits.
On the Slack side, the practical constraint is the export and retention plan. Every Slack plan can export messages and file links from public channels, but exporting private channels and direct messages requires Business+ or Enterprise, and custom exports by member or conversation are Enterprise-only. Confirm with Slack which plan and region terms cover your workspace before you rely on them, and record who in your organization can approve an export, since that decision is itself a processing activity. Whichever platform you choose, you still need to decide whether a US-headquartered operator can be reached by a third-country authority request, because the EDPB Recommendations 01/2020 state that no effective technical measure may exist where the destination's authority powers exceed what is necessary and proportionate.
The short answer for the three open-source options is that the sovereignty outcome depends on who operates the server. Mattermost, Rocket.Chat and Matrix with Element can all run entirely in your own datacenter or with an EU hosting provider, so the data path stays inside the region. What each one leaves in a US company's hands differs: Mattermost and Rocket.Chat use open-core licenses where some features sit behind commercial terms, while Synapse is AGPL-licensed with commercial exceptions from Element. Each vendor's support, license and update channel is a separate dependency you should map before choosing, and any paid tier you need for SSO or compliance features should be confirmed in writing.
What EU data sovereignty requires from a chat platform
For an EU organization, the question is less where a Slack workspace sits and more who can reach the data from outside the EEA and under which legal order. The cards below set out the rules that shape that answer, from transfer definitions to the powers of foreign authorities and the switching rights that come with the Data Act.
Every third-country transfer needs a basis
GDPR Article 44 applies to every transfer of personal data to a third country, including onward transfers, and each one must meet the Chapter V conditions. For a chat workspace, this covers member profiles, message content, file storage and analytics held by a vendor that may route data through other countries. Map each sub-processor and each country where data is stored or accessed before you accept a vendor's regional promise. Confirm the full transfer analysis with your counsel.
Remote access counts as a transfer
The EDPB's Guidelines 05/2021 (version 2.0) state that remote access from a third country is a transfer, even when the data is only displayed on a screen for support or administration. Storage in a cloud outside the EEA is also a transfer. An administrator or support engineer in another country who can open a workspace therefore creates the same exposure as a copy stored there. Ask vendors which staff locations can view data, including support tooling and telemetry.
Fines reach 4% of turnover
Infringements of Articles 44 to 49 carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher under Article 83(5)(c). The ceiling applies to the controller that decides to move data, so an unexamined transfer through a chat vendor is a board-level risk, not only a procurement detail. Document which chat data leaves the EEA, on what legal basis, and who approved it.
US law reaches data wherever it is stored
The CLOUD Act provision at 18 U.S.C. 2713, added on 23 March 2018, requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. An EU data center operated by a US company can therefore still fall within that reach. GDPR Article 48 only recognizes such foreign orders when they rest on an international agreement in force with the Union or a Member State. Ask vendors how they respond to foreign legal requests and whether they commit to challenging them.
Data Privacy Framework status is unsettled
Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List. An appeal against the General Court's September 2025 judgment upholding that decision is pending as Case C-703/25 P, so a vendor's listing today does not settle the question for the life of a multi-year contract. Check whether the vendor is listed, ask what fallback transfer tool applies, and plan for the case where the adequacy basis changes.
Switching rights under the Data Act
The Data Act, applicable since 12 September 2025, gives customers the right to move from a data processing service to another provider or to on-premises ICT infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. These rights shape exit planning: an open-source platform run in your own datacenter keeps the data and the exit path under your control. Confirm the notice and transition terms in your contract with counsel.
Where Slack's data residency and export terms leave EU controllers
The first question for an EU controller is what the plan lets you retain and take out, because that decides what you can prove later. Slack's Free plan keeps 90 days of message and file history, and content on Free workspaces older than one year is permanently deleted, so any retention duty longer than that cannot rest on a Free workspace. Every plan can export messages and file links from public channels. Private channels and direct messages need Business+ or Enterprise, and custom exports by member or conversation are Enterprise-only. Confirm with your records and legal teams which of these exports they need before choosing a tier, since the export entitlement determines whether the full record can leave Slack later. Start with Slack's export guidance.
Residency is a separate question from retention. The topic's review indicates that Slack's EU data residency needs Business+ or Enterprise and that member profiles and analytics remain outside the region. Treat that as a starting point, not a finished answer. Ask Slack in writing for its current data residency terms, its subprocessor list, the location where each subprocessor handles personal data, and how support access from outside the EU is controlled. Under GDPR Article 44, remote access from a third country counts as a transfer, so a support engineer viewing a record abroad matters as much as where the data is stored. Under EDPB Guidelines 05/2021, that exposure is part of the transfer assessment. File the written answers with their dates.
Self-hosting changes which questions you must answer, but it does not remove them. With Mattermost, Rocket.Chat or Synapse in an EU datacenter or an EU provider, you control where messages, file storage and backups sit. You still need to check the provider itself, because a provider under US control can receive a preservation or disclosure order under 18 U.S.C. 2713 wherever the data is located. Also plan for exit. The EU Data Act, applicable since 12 September 2025, gives customers a right to switch providers or move to on-premises infrastructure, and switching charges are banned from 12 January 2027. Run a test export from your current Slack plan now, so you know what the export actually contains before any decision depends on it.
Which self-hosted option fits which EU sovereignty constraint
Mattermost Team Edition is free, self-hosted and MIT-licensed as compiled by Mattermost, and it is aimed at teams under 250 users that do not need single sign-on. The source code is available under AGPL v3.0 or a commercial license from Mattermost, Inc., and admin tools and configuration files fall under Apache 2.0. For a US company, the license holder is Mattermost, Inc., and the commercial license path runs through that vendor. SSO and AD/LDAP sync start with the Professional plan, while high availability clustering and FIPS 140-3 compliance require Enterprise. High availability needs redundant application servers, database servers and load balancers, plus shared file storage on Amazon S3, an S3-compatible service or NAS mounted on each node. Local file storage will not work correctly and risks corrupting files.
- Licence holder: Mattermost, Inc. holds the commercial license. Confirm which edition and licence terms apply to your build.
- Paid tiers: Professional, Enterprise and Enterprise Advanced are prepaid annual seat subscriptions with no public prices on the pricing page. Ask for a written quote.
- Data path: Your data stays on the servers you run, but confirm with the vendor whether any telemetry or licence check contacts Mattermost at runtime.
- Storage and database: S3-compatible or NAS storage for clusters, and PostgreSQL as the database, both in your EU infrastructure.
- Edition gating: Air-gapped deployment is listed only for Enterprise Advanced, so confirm this before you rely on it for a disconnected network.
Before you commit, ask Mattermost to confirm in writing which components, if any, call out to vendor services in your chosen edition.
Rocket.Chat code outside its enterprise directories is MIT-licensed, while code under the ee directories uses Rocket.Chat's enterprise license. The licence split means a free Starter workspace for evaluation and small teams sits alongside commercial plans that carry the paid features. Rocket.Chat offers Commercial, Government and Defense plans that support on-premises, air-gapped and sovereign deployments. For a US company, the licence holder is Rocket.Chat, and the paid plans create a continuing commercial relationship for support, updates and the sovereign deployment options. The database layer is a MongoDB replica set, so the sovereignty review must include where that database runs and who operates it.
- Licence split: Separate the open code from the enterprise directories in your build to confirm which features depend on the enterprise licence.
- Sovereign plans: Commercial, Government and Defense plans are the documented route for sovereign and air-gapped use. Ask which plan covers your deployment model.
- Database operations: The MongoDB replica set holds messages and metadata, so confirm its hosting location and the administrator access model.
- Vendor touchpoints: Confirm whether licence validation or update checks reach Rocket.Chat servers in your edition.
- Support contract: Paid plans create a relationship with Rocket.Chat for support and security fixes, which should be written into the scope.
Before you deploy, confirm the exact enterprise features your EU use case needs and get the runtime network behavior of the chosen plan documented.
Synapse is the most widely documented Matrix homeserver, developed by Element and distributed under AGPL-3.0, with commercial licenses also available from Element. Element relicensed Synapse and Dendrite from Apache 2.0 to AGPLv3 and began selling AGPL exceptions, so the licence holder for the commercial route is Element. Element Server Suite comes as a free AGPL Community edition that includes Synapse and Element Call, a Pro edition with Synapse Pro, and a Sovereign edition for air-gapped deployments. Federation is the main sovereignty lever. The federation_domain_whitelist setting restricts federation to listed domains, an empty list disables it, and the docs recommend also firewalling the federation listener on port 8448.
- Licence holder: Element is the developer and commercial licensor for Synapse. The community code remains AGPL, so confirm what the Pro and Sovereign editions add.
- Federation control: Set federation_domain_whitelist to an empty list for an isolated server, or to named domains, and enforce the same rule at the firewall.
- Identity: Synapse supports OpenID Connect, SAML2 and CAS, and Matrix Authentication Service connects to upstream identity providers you host.
- Vendor touchpoints: Confirm whether Element Call, push gateways or update checks contact Element or matrix.org services at runtime, and disable what you do not need.
- Operations: Synapse runs on PostgreSQL and can use Redis with workers, so the database and cache must stay in your EU infrastructure.
Before you go live, verify that federation is off or limited as intended and document every outbound connection the chosen edition makes.
How Mattermost, Rocket.Chat and Matrix compare on sovereignty trade-offs
This table compares Mattermost, Rocket.Chat and Matrix with Element on the points that matter for EU data residency: license, where data sits under self-hosting, which controls need paid editions, high availability, Slack import limits and the vendor relationship. Read each row as a question to put to the vendor and to your own architecture team, since self-hosting moves data location under your control but not every vendor behavior.
| Criterion | Mattermost | Rocket.Chat | Matrix with Element |
|---|---|---|---|
| License | Source under AGPL v3.0 or a commercial license from Mattermost, Inc.; admin tools under Apache 2.0 | MIT outside the ee directories; ee code under Rocket.Chat's enterprise license | Synapse and Dendrite under AGPLv3 since the November 2023 change; commercial licenses from Element |
| Where data is stored when self-hosted | Your servers or EU datacenter; PostgreSQL database and file storage you configure | Your servers or EU datacenter; MongoDB and files you configure | Your servers or EU datacenter; PostgreSQL and media storage you configure, plus federation traffic if enabled |
| Cross-border exposure to confirm | Confirm in writing whether telemetry or update checks contact vendor servers and what data they send | Confirm in writing whether telemetry or update checks contact vendor servers and what data they send | Confirm in writing whether telemetry or update checks contact vendor servers, and whether federation reaches servers outside the EU |
| SSO and paid-edition gate | SSO (SAML, OIDC, OAuth) and AD/LDAP sync start at the Professional plan | LDAP and SSO available; confirm which features need paid plans for your use | SSO through OIDC, SAML2 or CAS in the open-source server configuration |
| High availability | Clustering only on Enterprise and Enterprise Advanced; needs shared S3-compatible or NAS storage | Confirm HA and MongoDB replica set requirements against the current plan terms | Scaling through worker processes and Redis; operational design is your team's responsibility |
| Slack import path | mmetl converts the export for mmctl; users, channels, DMs, threads and attachments move | Built-in importer under Manage, Workspace, Import; split exports into files under 15 MB | Bridges can keep Slack channels connected during cutover; history migration needs its own plan |
| Slack items that do not move | Integrations, custom emoji images, user groups and Slack Connect channels | Confirm which integrations, bots and user groups must be rebuilt after import | Slack integrations and Slack Connect equivalents must be rebuilt or bridged |
| Vendor relationship | Single vendor for server and commercial editions; paid plans are annual seat subscriptions | Single vendor with Starter, Commercial, Government and Defense plans | Upstream developer Element sells Synapse Pro and Element Server Suite Pro; Matrix is an open standard with several server implementations |
How to deploy self-hosted chat under EU residency controls
This sequence takes an EU organization from the hosting decision to a tested, documented chat deployment in which member data, remote access and upstream upgrades stay under the organization's control.
Fix hosting location and provider contract
The legal or compliance owner, with the data protection officer, chooses the hosting location: your own EU datacenter or an EU-based provider. Write down the provider's sub-processors, support locations, and whether any third-country entity can access systems or backups. Ask the provider to confirm in writing where data is stored and where administrators connect from. The step is done when the contract and the processing record name the same location and the same operators.
Map data flows and remote access paths
The platform owner lists every place chat data can travel: the database, file storage, backups, logs, push notification services, email relays, mobile clients, and any federation peers. Include support sessions where an engineer outside the EU views a screen, because remote display can count as a transfer under the EDPB guidance. Mark each path as EU-only, restricted or out of scope. The step is done when the map has no unexplained third-country path.
Pick the option and edition
Compare Mattermost, Rocket.Chat and Matrix with Element against the requirements from the previous steps. Check which features your residency and identity needs depend on, such as SSO, AD or LDAP sync, high availability, compliance export and air-gapped operation, and confirm which plan or edition includes them with each vendor. Confirm license terms with counsel, including AGPL obligations for Synapse and the MIT or enterprise split in Rocket.Chat. The step is done when a single option and edition is recorded with its license and feature justification.
Deploy in the EU on PostgreSQL and shared storage
The platform engineering team deploys the application servers, PostgreSQL, and file storage inside the chosen EU location. For Mattermost high availability, file storage must be shared (S3-compatible storage or NAS mounted on every node), because local storage will not work correctly and risks corrupting files. For Synapse, use PostgreSQL in production and add Redis and workers only as load requires. Confirm that the database and object store both sit in the EU. The step is done when a test user can post, upload and read history from an EU-only network path.
Restrict federation or disable it
The Matrix or Rocket.Chat administrator sets the federation policy before users are onboarded. For Synapse, set the federation domain allow list to named partners, or set an empty list to disable federation, and firewall the federation listener as the configuration manual recommends. Record the decision and the reason. The step is done when a test federation attempt to an unlisted domain is refused and the configuration is stored under version control.
Configure SSO, retention and audit settings
The identity team connects chat to the corporate identity provider using SAML, OpenID Connect or the method the chosen platform supports, and confirms that deprovisioning removes access. The records owner sets message retention and any legal hold or compliance export requirements, and confirms which paid editions include them. Verify these settings with a test account that is then deactivated. The step is done when login, deprovisioning and retention behave as the policy states.
Run a Slack export and import test
Export a Slack workspace with the plan that matches your needs: public channel data is available on every plan, while private channels and direct messages require an approved Business+ or Enterprise export. Import the export into a staging instance using the platform's documented path, such as mmetl with mmctl for Mattermost or the built-in importer for Rocket.Chat. Compare user, channel and message counts against the source and note what does not move, such as integrations and custom emoji. The step is done when the staging gap list is signed off by the business owner.
Pin upstream versions and document access and backups
The platform owner pins the server version in the deployment code and plans upgrades against the vendor's release calendar. Mattermost publishes a new server version in binary form on the 16th of each month, and its Extended Support Releases have fixed support end dates, so record which line you run and when it ends. Document where backups, logs and administrator access live, who holds keys, and the restore test schedule. The step is done when a restore has been tested in the EU and the runbook names an owner for each upgrade.
Evidence a regulator or auditor will ask you to produce
A regulator or auditor reviewing a self-hosted chat deployment will want to see where personal data sits, who can reach it, and how the system is kept current. The cards below cover the records that answer those questions for a Mattermost, Rocket.Chat or Matrix setup. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit report or certification.
Transfer impact record
A written assessment of whether any personal data leaves the EEA, including remote access from a third country and storage in a cloud outside the EEA, which the EDPB treats as transfers. For a self-hosted server, the record should show the hosting location, the operator's staff locations and any support access path. Record also how you assessed third-country law exposure for any EU provider that is itself subject to foreign authority requests, since the EDPB expects that assessment before you engage it.
Data location and access map
A diagram and register listing every system that holds chat content, including the PostgreSQL database, file storage, backups, search indexes, logs and any bridge or push relay. For each one, record the physical location, the accounts and roles with access, and whether the operator can read content in the clear. This map is the first document a reviewer will test your other evidence against.
Processor and subprocessor contracts
Signed agreements with every party that hosts, operates or supports the deployment, including the implementation partner, any cloud or datacenter provider, and any managed backup service. Each contract should name the subprocessors, the processing locations, the access conditions and the handling of third-country government requests. Check that the agreement covers the actions you rely on, such as remote troubleshooting from outside the EEA.
Federation and remote access configuration
Exported configuration showing how the server handles outside connections. For Matrix, this includes the server_name, the federation_domain_whitelist list (or the empty list that disables federation), the firewall rules for the federation listener on port 8448, and the SSO provider settings. For Mattermost and Rocket.Chat, record the equivalent settings for external accounts, guest access and admin session controls. Keep dated copies so you can show what was in force at any point.
Backup and restore records
Evidence that backups run on a schedule, are encrypted, are stored inside the agreed location, and have been restored in a test. Keep the restore test results with dates, the person who ran them and the time taken to bring the chat service back. A backup copy outside the EEA is a transfer, so the location of each copy belongs in the data map.
Upgrade and support records
A dated log of server upgrades, security patches and the versions in service, checked against each project's published support windows. Mattermost publishes a support end date for each server release and Synapse drops support for Python and PostgreSQL versions once upstream support ends. Record which versions were running, when they were patched, and who approved each change, so you can show the system was supported throughout the period under review.
What the migration and cutover involve for EU teams
Start with the export, because the Slack plan decides what you can take out. Every Slack plan can export messages and file links from public channels, but private channels and direct messages require a Business+ or Enterprise plan, and custom exports by member or conversation are Enterprise-only. For an EU team, this means confirming the export tier before the project is scoped, and asking the Slack account team in writing which data categories the export will include. Free workspaces also lose history: older content is permanently deleted after one year, so anything you need must be exported before that window closes. On Mattermost, the documented path converts the Slack export with mmetl into Mattermost's bulk import format and loads it with mmctl. Users, channels, direct messages, threads and attachments move across. Integrations, custom emoji images, user groups and Slack Connect channels do not, so plan to inventory each of them and rebuild them by hand. Rocket.Chat takes a different route: its built-in importer reads a Slack export from Manage, Workspace, Import, and its documentation recommends splitting large exports into files under 15 MB. Test both paths on a copy of the export inside your own environment before choosing one.
For phased cutover, a Matrix server with Element can run alongside Slack while Matrix bridges for Slack keep channels connected, so teams move at different speeds. Confirm each bridge's current support and history handling with its maintainers before you rely on it. Your exit from Slack is also a documented process. Under the EU Data Act, customers have the right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027. Record the export dates, the data categories moved, the rebuilt integrations and the deletion confirmations in your migration file, so the exit can be shown to your data protection officer and auditors.
Questions EU teams ask before a Slack data residency move
Does self-hosting Mattermost or Matrix remove all GDPR transfer obligations?
No. Self-hosting moves the data to your own infrastructure, but it does not remove your duties as a controller. If your servers sit in an EU datacenter run by you or an EU provider, a transfer happens only when personal data is stored, accessed or displayed from outside the EEA, including remote support sessions from a third country. GDPR Article 44 applies to every such transfer, and the EDPB Guidelines 05/2021 (version 2.0) treat even on-screen remote access as a transfer. You still need a record of processing, a lawful basis, a data inventory of where chat content and member profiles land, and written terms with any provider or support firm that can touch the system. Confirm each access path with your legal team before you cut over.
What does a self-hosted EU chat migration cost, and what drives the cost?
The cost has four components: hosting, licensing for paid editions, migration work, and admin time. Hosting covers compute, PostgreSQL, file storage and backups in your chosen EU location, and it recurs. Licensing matters only if you need features that sit in paid tiers: Mattermost's SSO and AD/LDAP sync start at the Professional plan, and high availability starts at Enterprise, according to its pricing page, which lists no public prices. Migration and admin time are mostly one-time, but they grow with the number of integrations, bots and Slack Connect channels you must rebuild. Ask any quote to split these lines, to name who is paid for each, and to state which features are assumed to need paid licenses.
How long does an EU data sovereignty chat project take?
The timeline depends on scope rather than on a fixed number of weeks, so ask for a schedule in the written scope instead of a generic estimate. The main drivers are the number of users and channels, whether private channels and direct messages must come across (which depends on the Slack plan that authorizes the export), how many integrations need rebuilding, whether high availability and SSO are in scope, and how long your legal and works council reviews take. Mattermost's documented migration path converts a Slack export with mmetl and loads it with mmctl, and Rocket.Chat imports from a Slack export after you split large files, so both paths are testable early in a pilot.
What does our team need to provide for a self-hosted chat project?
You need named owners for data protection, infrastructure, identity and business sign-off, and you need them early. Data protection staff must confirm the transfer map and the data categories in chat. Infrastructure staff must provide the EU hosting location, network rules and backup targets. Identity staff must supply the SSO provider settings, such as OIDC or SAML details, and the user directory to sync. Business owners must decide which channels, direct messages and retention periods move. Ask the provider which of these inputs it expects in the first phase and what it needs from your change calendar.
Can our own IT team run a Mattermost or Matrix deployment without outside help?
A capable team can run a small single-server deployment, but production work needs skills across Linux, PostgreSQL, reverse proxies, backups and upgrades. Mattermost runs as a single Linux binary with PostgreSQL, and high availability requires redundant application servers, database servers and load balancers plus shared file storage such as S3-compatible storage or NAS on each node. Synapse needs PostgreSQL 14 or newer for recent releases, and at scale it adds Redis and worker processes. Its upgrade notes warn that rolling back can be difficult because of schema changes. Be honest about who will patch, upgrade and be on call. If you want outside support, DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer.
Is an EU-based hosting provider enough for data sovereignty?
Not on its own. An EU provider reduces transfer exposure, but it does not settle every question. The EDPB Guidelines 05/2021 (Example 12) say that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, yet complying with a third-country authority request would be, so you must assess that exposure before you engage the provider. The US CLOUD Act, at 18 U.S.C. 2713, reaches providers with possession, custody or control of data regardless of location. Check whether the provider is a US-parented company, who can access the platform, which support staff sit outside the EEA, and what legal measures and contract terms apply. Where EDPB Recommendations 01/2020 apply, a technical measure may not be enough if the provider must access data in the clear.
What should we ask for in a fixed-scope quote for a self-hosted chat migration?
Ask for a written scope that lists each deliverable, the platform edition and the features it depends on, the hosting location and every access path, and the acceptance tests for the pilot. Request separate lines for one-time work (installation, hardening, migration, integration rebuilds, training and documentation) and recurring work (hosting, licensing, upgrades, backups and support). The quote should name what is excluded, such as channels you will not migrate, bots you will not rebuild or features you will not enable. Also ask how the provider handles the Slack export, who holds the export files and when they are deleted, and what evidence it will hand over for your compliance file. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list, so the quote follows from that scope.
How DeployOpen deploys chat under EU sovereignty constraints
DeployOpen plans, implements, hardens, documents and supports self-hosted chat inside your own infrastructure, whether that is your data center or an EU provider you select. The work starts with a written scope that defines where messages, files, profiles and logs will sit, who can reach them from outside the EU, and which evidence your compliance team needs.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope maps every data flow, including backups, logs, push notifications and admin access from outside the EU.
- We confirm which platform, edition and license terms your legal team has reviewed before any build begins.
How we build
- We deploy the chosen platform in your own cloud account, data center or EU hosting environment, with no dependency on a US-hosted control plane.
- We configure identity integration, database and file storage, federation settings and retention controls to match the approved scope.
- We test access paths, including remote administration and vendor support sessions, against the transfer conditions set out in the scope.
How we hand over
- You receive architecture diagrams, data flow records, configuration baselines and runbooks written for your administrators.
- We prepare the controls and evidence your independent auditors or certification bodies will assess; we do not issue audit reports or attestations ourselves.
- Migration from Slack, where in scope, is documented step by step, including what did not move and who must rebuild it.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Upgrades are planned around each platform's published release and support windows, with a tested rollback path where the vendor allows one.
- Re-checks of data flows are scheduled when the vendor changes licensing, hosting options or subprocessors, so your records stay accurate.

