Migrate from AWS Wickr to Matrix and Element

Migrate from AWS Wickr to Matrix and Element: what moves and what does not

If your renewal, data residency rule or need to hold your own keys and servers is driving this move, plan on rebuilding rooms, identities and devices on a self-hosted Synapse homeserver rather than carrying a Wickr network across intact. History comes over only where a Wickr export path is confirmed for your plan and retention settings, so ask AWS for that answer in writing before you promise users their message history. Platform or security engineering teams usually own the work, often with an implementation partner who handles the homeserver build, SSO wiring and cutover plan. Confirm with AWS what data export your administrators can actually obtain, because that single answer sets the size of the historical-data conversation.

Both Wickr and Matrix provide end-to-end encryption, so the core risk is not the cryptography. It is key and device handling: how each user's devices are verified, how key backup is set up, and what happens when someone loses a phone or leaves the organization. Element clients need a documented policy for cross-signing, secure key backup and recovery, and the Synapse configuration must match it. Decide these policies before enrollment begins, because changing them after users have joined means re-verifying devices and re-creating trust in each room. Effort and risk depend mostly on user count, how many rooms and security groups must be re-created, and how much identity integration your environment requires. Get those drivers scoped in writing with your partner rather than relying on a generic estimate.

Plan to run Wickr and the new Matrix network side by side for a defined overlap period, with users told which system carries which conversations. Migrated rooms will not match Wickr security groups automatically, so map each group to a room, a membership list and a moderation owner, then test one pilot group end to end before wider rollout. Keep the Synapse version pinned during the pilot and read the upgrade notes before each change, since the notes warn that rolling back can be difficult because of database schema changes. Confirm the Wickr contract end date and data deletion terms with AWS so the overlap does not extend past what you need.

Which Wickr capabilities map cleanly to Matrix and Element

This table maps the main Wickr capabilities to their Matrix and Element equivalents and marks each as clean, needs rework or gap. Synapse is the homeserver in every row, and Element Server Suite is one commercial packaging option that bundles it with Element Call. Items marked to confirm with AWS describe Wickr behavior that you should check against your own network before migration planning starts.

Wickr capability	Matrix and Element equivalent	Migration note
1:1 and group messaging	Direct messages and private rooms on Synapse, used through Element clients	Clean for text. Confirm with AWS: message size limits and edit or delete behavior.
Rooms and security groups	Invite-only rooms with membership and power levels; spaces group related rooms	Needs rework. Rebuild security group membership as rooms and power levels. Confirm with AWS how memberships are exported.
End-to-end encryption	Matrix end-to-end encryption, enabled per room and verified per device in Element	Needs rework. Enable encryption on each room and plan device verification. Do not assume key material moves. Confirm with AWS.
File sharing	Media uploads stored by the Synapse media repository, with size and retention set in configuration	Needs rework. Set upload limits and media retention on the homeserver. Confirm with AWS the Wickr file size and retention limits.
Voice and video calling	Element Call, packaged with Element Server Suite; Synapse alone does not provide calling	Gap until a calling stack and TURN service are deployed. Confirm with AWS the call features you use, such as recording.
Guest and federated access	Federation on port 8448, limited with federation_domain_whitelist and firewall rules	Needs rework. Federation is off only when configured that way, so set it deliberately. Confirm with AWS how external users are invited today.
Retention settings	Synapse retention policies set per room and server, applied to stored events	Needs rework. Export Wickr history first, then map retention to Synapse policies. Confirm with AWS what Wickr retains.
Admin controls and SSO	OpenID Connect, SAML2 or CAS through oidc_providers and saml2_config, with admin tools	Clean for SSO with a supported identity provider. Confirm with AWS which Wickr admin and audit features need a replacement.

What retained Wickr data can come across and what you must confirm with AWS

Wickr's retained data, identities and room structure do not map one-to-one onto a Matrix homeserver, and the supplied sources describe export paths for Slack and Microsoft Teams only. Each card below marks whether an item can be exported, must be re-created by hand, or is a gap you should plan around, and names what to request from AWS before scheduling the cutover.

Retained message history

Message history can only come across if your Wickr network had data retention enabled and AWS confirms a supported export path for that retained data. Ask AWS whether retained messages, files and metadata can be exported, in what format, and whether the export includes private rooms and direct conversations. If no export is confirmed, treat history as a gap and decide with compliance whether the old Wickr network stays read-only for its retention period. Element and Synapse do not import Wickr archives in the supplied sources, so any conversion is custom work.

User and device identities

Wickr accounts do not carry over as Matrix users. Plan to create Matrix IDs in the form @user:your.server_name and enroll each person and device again through your identity provider over OpenID Connect, SAML2 or CAS. Ask AWS for a list of active accounts and device counts so you can map them to directory identities before enrollment. Each re-enrolled device will need its own verification, so budget help desk time for that step.

Room and security group structure

Wickr security groups and rooms must be re-created as Matrix rooms with explicit power levels, join rules and room aliases. Export the membership list and group names from the Wickr admin console if AWS provides them, then rebuild the structure in a staging homeserver. Confirm with AWS whether group names, admins and moderation roles are visible to admins, because those settings decide how much you rebuild by hand.

File attachments

Attachments are a separate export question from messages. Ask AWS whether files shared in Wickr can be downloaded in bulk, whether their encryption keys are included, and whether file size or type limits apply. Matrix media lives on your homeserver storage, so any file you can retrieve must be re-uploaded or linked into an archive that your records team controls. Anything that cannot be retrieved should be recorded as a gap in the migration register.

Admin and audit logs

Admin actions, sign-in records and policy changes are needed for investigations and assessments, and they do not move into Synapse automatically. Ask AWS which administrative and audit logs are retained, for how long, and how they are exported. Plan to keep the Wickr logs in your existing archive and ship Synapse logs to your own log platform from day one, since Synapse log configuration is yours to set.

Integrations and bots

Wickr bots, webhooks and any connected tools will not function on Matrix until you rebuild them with Matrix bots or bridges. Inventory each integration with its owner, data flow and credentials, then mark it as re-create or retire. The Matrix ecosystem lists bridges that may cover some services, but you must confirm each bridge against your own requirements before relying on it.

The migration sequence from inventory to decommission

The sequence moves a Wickr network to a self-hosted Matrix homeserver in stages, so each step produces a written record that the next step depends on. By the end, the organization holds a tested Synapse deployment, a documented cutover, and evidence for what happened to the Wickr data.

Inventory the Wickr network and its obligations
Record every Wickr network in use, including its security groups, retention settings, enrolled users, devices, bots and integrations, and the internal and external parties that rely on each conversation. Map the compliance obligations that apply to message content, retention and export, and confirm them with your compliance lead and any assessor. The step is complete when you hold a signed inventory that states which conversations must be kept, which may be discarded, and who owns the decision for each.
Pilot a small Synapse deployment
Build a Synapse homeserver in your own infrastructure, using PostgreSQL as the production database, and configure SSO through one of the supported identity protocols (OpenID Connect, SAML2 or CAS). Set server_name deliberately, decide whether federation_domain_whitelist should restrict federation, and create a test set of rooms with a small group of pilot users on Element clients. The step closes when a pilot group can sign in through SSO, exchange messages across devices, and restore the database from a backup in a test environment.
Run both networks in parallel
Keep the Wickr network live while the Matrix deployment serves the pilot groups and then wider teams. Publish a clear notice that states which system holds which conversations, what is still on Wickr, and the date from which new conversations start on Matrix. Confirm with each team lead which conversations will move and which will close. The step produces a register of active rooms and groups on each system, and the register is the input for cutover.
Cut over rooms, SSO and key backup
Re-create the required rooms on Matrix with the membership, power levels and history visibility settings recorded in the inventory, since Wickr security groups do not carry over as rooms. Enroll each user through SSO, and have each user verify their devices with cross-signing before they rely on encrypted rooms. Set the key backup policy in writing, covering who may enable server-side backup, how recovery keys are stored, and how a lost device is handled. The step is complete when each migrated room has a verified membership list, every active user has verified at least one device, and the key backup policy is signed off.
Dispose of Wickr data and retain evidence
Using the retention decisions from the inventory, export or preserve the Wickr data that must be kept, and confirm with the data owner that the export is complete and readable before anything is deleted. Then decommission the Wickr network according to the disposition record, and file the evidence: the signed inventory, the export checksums, the deletion confirmations and the final room register. Ask your assessor which of these records they will request, and keep them with the Synapse upgrade and backup records. The step closes when the disposition record is signed and the evidence set is stored under access control.

How to run Wickr and Matrix side by side and cut over safely

The parallel period is where most Wickr-to-Matrix migrations succeed or fail, so decide the cutover order before the first user is invited. Move low-risk, self-contained conversations first, such as project rooms with a clear owner, and leave regulated or high-volume channels until the pilot has run for several weeks. Tell users in one written notice which network to use for each group, and post the same rule in every Wickr room that is still active. Split conversations, where half a team is on Wickr and half on Matrix, are the main source of lost messages and confusion. Avoid them by moving whole rooms and membership lists together, and by setting a single date after which new conversations are created only on Matrix. Confirm with your Wickr administrator how long message retention and export will remain available so the overlap window does not close early.

Federation has to match the cutover plan. During the pilot, set federation_domain_whitelist in the Synapse configuration to the partner domains you have approved, or to an empty list to disable federation entirely. An empty list is the stricter choice while you are testing identities and room permissions. Also firewall the federation listener on port 8448 so only the allowed peers can reach it, because the configuration manual recommends this in addition to the whitelist. Reopen federation only after the security team has signed off on the peer list. Record the decision in your change log, since federation affects who can join rooms and which identities are trusted.

Two controls work as cutover gates. The first is key backup policy: decide whether Matrix message key backup is enabled, who can restore it, and how recovery keys are stored, then test a restore on a pilot account before any production user depends on it. The second is device verification: require each user to verify their devices with cross-signing before the user moves a sensitive room, and confirm that unverified sessions cannot read that room's history. Do not cut over a group until both checks pass for every member. Finally, rehearse upgrades on the pilot. The Synapse upgrade notes warn that rolling back can be difficult because database schema changes between releases, so take a PostgreSQL backup, upgrade the pilot to the current release, and practice a restore before you touch production. Plan the upgrade path rather than assuming you can reverse it.

What drives cost and duration in a Wickr to Matrix move

This table lists the factors that change the effort and recurring cost of moving a Wickr network to a self-hosted Matrix homeserver with Element clients. Read each row for what drives the cost up and how to keep it down, then use the list to shape a written quote. Most rows apply to both the one-time migration and the ongoing operation.

Driver	Why it matters	How to keep it down
User and device count	Each enrolled device adds onboarding, key verification and support load, and device counts usually exceed user counts.	Agree on a device policy early, enroll in waves, and confirm the quote covers users and devices separately.
Networks and security groups	Each Wickr network and security group must be mapped to Matrix rooms, spaces and power levels by hand, which is labor that scales with the count.	Inventory networks and groups before scoping, and consolidate groups that share the same membership and access rules.
Retention and export scope	Only retained data can be carried over, and export depends on what retention and admin settings were enabled in Wickr, so scope can shrink or grow late in the project.	Confirm with Wickr administrators what retention was on, then decide in writing which history is kept, archived or left behind.
SSO and identity provider complexity	Matrix SSO through OpenID Connect, SAML2 or CAS must match your identity provider's claims, groups and session rules, and each provider adds integration and testing work.	Use one identity provider, document required claims, and test login, logout and account deactivation before cutover.
File and call requirements	Media storage sizing, file retention and calling quality (which relies on TURN and related components) add hardware, storage and testing effort.	Set file size and retention limits up front, and confirm which calling features are needed in the first release.
PostgreSQL and Redis operation	Synapse recommends PostgreSQL for production, and Redis is needed once workers are used, so both require backup, tuning and failover planning.	Use managed or existing PostgreSQL where your policy allows, and ask the vendor or partner to size workers only when load demands it.
TURN and push notification setup	Calls need a TURN server reachable from users' networks, and mobile notifications need a push path, both of which add network changes and per-platform setup.	Plan firewall and DNS changes with the network team early, and confirm how push notifications will reach mobile devices in your environment.
Staffing for the upgrade cadence	Synapse changes between releases, and rollbacks can be difficult because of database schema changes, so someone must test and apply upgrades regularly.	Name an owner, budget recurring patch windows, and ask for a written upgrade and rollback procedure with each release.
Python and PostgreSQL version floors	Synapse 1.143.0 and later require PostgreSQL 14 or newer, and 1.142.0 and later require Python 3.10 or newer, so older hosts may need upgrading before installation.	Check host operating system versions against these floors before scoping, and ask for the supported version matrix in the quote.

What usually goes wrong when Wickr users move to Matrix

Most failed Wickr-to-Matrix moves fail on people and process, not software. The cards below cover key handling, identity enrollment, the parallel run, federation settings, upgrade rehearsal and the retention questions that surface only after the old network is switched off.

Unverified device keys hide history

Matrix encrypts room history to each device's keys, so a user who loses a device or skips key backup can end up with messages they cannot read. Wickr users often assume their history follows them automatically. Before cutover, confirm with the Element client team how cross-signing, recovery keys and key backup will be explained and tested with a pilot group, and decide who helps users who lose a device. Owner: IT service desk lead with the security team.

Users enrolled outside SSO

If accounts are created by hand, identities drift from the corporate directory and offboarding misses Matrix accounts. Synapse can federate login through OpenID Connect, SAML2 or CAS, so the identity provider should be wired in before any user is invited. Check that deactivated directory accounts also lose Matrix sessions and that local password logins are disabled where policy requires it. Owner: identity team.

Split conversations during parallel run

Running Wickr and Matrix side by side means some teams keep talking in the old network while others move, and decisions end up scattered across two systems. Set a dated cutover per group, publish which rooms replace which Wickr security groups, and state in writing that the old network is read-only for new decisions. Track which groups still send traffic on Wickr each week. Owner: program manager with business unit leads.

Federation exposed by accident

Synapse federates on port 8448 by default, so a server built for internal use can become reachable from other homeservers if the listener is opened to the internet. Set server_name deliberately, use federation_domain_whitelist to restrict or disable federation, and firewall the federation listener as the documentation recommends. Verify from outside the network after each change. Owner: network security engineer.

Skipped upgrade rehearsal

Synapse changes database schemas between releases, and the upgrade notes warn that rolling back can be difficult. Teams that upgrade production without a rehearsal on a copy of the database may have no clean way back. Restore a recent PostgreSQL backup into a staging environment, run the target version there, and record the steps. Also check the PostgreSQL and Python minimums in the upgrade notes before scheduling. Owner: platform engineering lead.

Retention and legal hold found late

Wickr retention settings, legal holds and eDiscovery exports may have been configured by someone other than the team running the migration. Once Wickr is shut off, data that a regulator, court or internal policy requires can be gone. Before the switch-off date, inventory retention and hold obligations with legal and records management, confirm what can be exported from Wickr, and agree where archived content will sit. Owner: general counsel with records management.

How the migration changes by network size and starting point

A single organization with one Wickr network and a modest user count usually has the most direct path. The work centers on one Matrix homeserver, one identity source and a short list of rooms that map to existing Wickr security groups. An illustrative case would be one business unit moving team by team over several phases, although the actual scope depends on your Wickr configuration and your own environment.

Server name first: Choose the server_name before any user is created, because it fixes how user IDs such as @user:example.com and room identifiers are formed.
Single homeserver: One Synapse host backed by PostgreSQL is a common starting point, but confirm sizing with load tests in your own environment.
Federation off: Set federation_domain_whitelist to an empty list if no outside parties are in scope, and still firewall the federation listener.
One identity provider: Connect a single OIDC or SAML provider so users and devices enroll through existing sign-in.

Confirm with AWS what Wickr can export for retained messages, and confirm which of your users hold administrator rights before you design the room structure.

When customers, suppliers or partner organizations share Wickr rooms with you, federation turns a private migration into a cross-organization one. Synapse federates over port 8448 by default, and delegation can serve user IDs on port 443 from another host, so the networking and DNS plan must cover both paths. Each partner also needs an agreed policy for what may be federated and how long messages are kept.

Allowlist, not open federation: Use federation_domain_whitelist to list only the domains you trust, and treat that list as a governed document.
Delegation and DNS: Plan .well-known delegation so that @user:example.com identities resolve correctly to the host serving federation.
Partner alignment: Agree with each partner on server versions, retention and deletion, and who approves new domains.
Identity trust: Decide whether external users sign in through their own identity provider or through a guest flow that you control.
Partner migration timing: Confirm whether each partner is replacing its own Wickr network at the same time, because federated rooms split across two systems can confuse users.

Confirm with your legal and security teams whether partner data sharing needs contract changes before any federated room is opened.

How long does a Wickr to Matrix migration take and what does it need from us?

Can message history move from AWS Wickr to a self-hosted Matrix server?

Only if your Wickr network had data retention turned on and you can export what it holds, and that depends on what AWS and your Wickr administrators confirm for your plan. Our supplied sources do not document a Wickr export format or a Wickr-to-Matrix import path, so do not assume history will carry over. Ask AWS which retention data is accessible to you, in what format, and whether it covers files and calls. Plan for any retained content to be loaded as archive material in separate rooms, since Matrix does not replay Wickr's encrypted session state. Decide before cutover which history matters for legal hold, and keep a copy of the export under your own retention policy.

How long does a Wickr to Matrix migration take?

The length depends on the number of users and devices, how many rooms and security groups you need to rebuild, how much identity integration is required, and how many parallel systems you must run. No duration is supplied for this migration, so treat any timeline as something to agree in writing against your own inventory. Teams with a small user base and simple groups can finish much faster than organizations with many regulated groups, custom SSO rules and air-gapped networks. Ask for the schedule to be broken into discovery, build, pilot, cutover and side-by-side operation, with each phase tied to an exit criterion.

What does a Wickr to Matrix migration cost, and which parts are one-time?

Costs fall into three groups: the one-time build (server deployment, PostgreSQL, Redis if you scale with workers, TURN and push setup, SSO integration, room and access design, user enrollment and testing), the recurring run cost (hosting, patching, backups, monitoring and on-call), and any licensing. For licensing, Synapse is AGPL-3.0 and Element sells commercial licenses, and Element Server Suite has Community, Pro and Sovereign editions with published pricing on Element's site. Wickr's per-user pricing and add-ons should come from AWS. Ask for quotes that list each component separately, state who pays for hardware and cloud accounts, and include an annual support or upgrade line.

Can our own team run the migration without a partner?

A team with Linux, PostgreSQL, identity federation and Kubernetes or container experience can do most of the work, and Element's documentation covers Synapse configuration in detail. The harder parts are rarely the installation. They are the access model, federation policy, key backup decisions, device enrollment at scale and proving the controls to an assessor. Check whether your staff have time to own a homeserver after cutover, since Synapse upgrades can be difficult to roll back because of database schema changes. A partner can handle a fixed-scope piece, such as the build or the evidence pack, while your team keeps operational ownership.

What must we provide before the migration work starts?

Prepare four inputs: access to your identity provider, an inventory of networks and firewall rules, your retention and legal hold decisions, and a list of rooms, groups and roles mapped to people. For SSO, Synapse supports OpenID Connect, SAML2 and CAS, and the identity provider must be reachable from the homeserver. For networking, confirm where the server will sit, which hostnames and DNS names it will use, and whether federation is needed at all. Synapse federates on port 8448 by default and can be restricted with federation_domain_whitelist, and the docs recommend firewalling the federation listener. Decide early whether you need federation or a closed deployment.

How do key backup and device enrollment work for our users?

Each Matrix user signs in on each device, and the device gets its own cryptographic keys, so enrollment should be planned as a user process with support. Decide before rollout whether users back up room keys to the server, how recovery keys are issued and stored, and who can reset a lost device. These are policy choices that determine whether a lost laptop means lost history. Confirm the exact enrollment and key backup flow with Element's current client and server documentation for your version, and test it with a pilot group before cutover.

Does Matrix meet the compliance controls we had with Wickr?

Matrix can support end-to-end encrypted messaging, self-hosted key custody, SSO and audit logging of server activity, but it does not inherit Wickr's certifications or its AWS-managed controls. Compliance depends on how you configure and operate the homeserver, and the compliance status of Element and Synapse should be confirmed with the vendor and your assessor. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications; independent auditors and certification bodies do. Map each Wickr control you rely on to a Matrix control, then identify the gaps before you commit.

How DeployOpen scopes, runs and supports a Matrix migration

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from AWS Wickr to a Matrix homeserver with Element clients, we start with a written scope that fixes what is migrated, what is rebuilt and what stays on the Wickr side during overlap.

How we scope

Inventory Wickr networks, security groups, bots and any retention settings your administrators can export before work starts
Agree in writing which rooms, device enrollments, SSO connections and key backup rules are in the Matrix build
Confirm server_name, federation posture and hosting region with your security and compliance owners before design
Define a fixed scope with deliverables and timelines agreed in writing, with no prices in this page

How we build

Deploy Synapse with PostgreSQL in your environment, using the versions your upgrade notes require at the time of build
Configure SSO through your identity provider and set federation_domain_whitelist to match the agreed policy
Test room creation, device verification, push notifications and message retention against a representative user group
Firewall the federation listener and document every configuration key that differs from the defaults

How we hand over

Deliver runbooks for user and device enrollment, room provisioning, key backup policy and offboarding
Document the side-by-side period, cutover criteria and the rollback limits described in the Synapse upgrade notes
Train administrators on upgrades, backups and monitoring so your team can operate the homeserver
Provide compliance evidence packs that your independent auditors can review, without issuing any attestation ourselves

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Plan each Synapse upgrade against release notes, database requirements and a tested backup before changes
Run periodic security testing of the homeserver, clients and integrations on a schedule agreed with you
Confirm with your team who owns on-call response, key recovery requests and vendor license decisions

Migrate from AWS Wickr to Matrix and Element