A planned migration, run by the people who write Stalwart.
Mailboxes, folder structure, flags, calendars, address books and shared resources are carried across; cutover happens in a window you control, with optional co-existence.
Source systems we support out of the box.
The migration tooling reads from the protocols and on-disk formats of the major existing servers.
- Postfix and Dovecot. Maildir and mdbox stores, Sieve scripts, virtual user databases (passwd, LDAP, SQL).
- Cyrus IMAP. Mailboxes (including shared and public folders), seen/flag state, sieve scripts, ACLs.
- Zimbra Collaboration. Mail, calendars, contacts, briefcase folders, distribution lists, shared folders.
- Microsoft Exchange (on-prem) and self-hosted Microsoft 365. Mailboxes, calendars, contacts; public folders where applicable.
- MDaemon. Mailboxes, address books, calendars, mailing lists.
- hMailServer. Mailboxes, domain settings, aliases.
- Courier. Maildir stores, calendaring where present.
- Generic IMAP / CalDAV / CardDAV / WebDAV. Anything else that speaks the standard protocols can be migrated read-side without vendor-specific tooling.
What carries over, and what does not.
Carried over per source: messages with full headers and flags, folder hierarchy, sieve filters where the format permits, calendars and events (including recurrences), address books, shared and delegated resources, and server-side rules where the source exposes them. Not migrated automatically: vendor-specific automation that has no Stalwart equivalent (we flag these in the assessment phase and propose replacements), and end-user client configuration (handled instead by Stalwart's autoconfig and autodiscover).
Built for the way real migrations actually run.
The migration tooling is the same one our team uses on customer engagements, so what you see in a pilot is what runs at scale. It handles bulk loads, delta passes and dry runs without touching the production system more than necessary, and it preserves the details that matter to end users (folder structure, flags, timestamps, recurring events).
- Reads source mailboxes over IMAP, CalDAV, CardDAV, WebDAV or directly from on-disk formats where supported.
- Writes into Stalwart through JMAP; preserves message identifiers, flags and timestamps where the protocols allow.
- Resumable: a partial run can be re-driven without re-importing existing messages.
- Parallel per-mailbox; the throughput target on a typical migration is bound by the source server, not Stalwart.
- Dry-run mode that produces a per-account report (mailbox count, message count, total size, anomalies) before any data is written.
Typical phases and timeline.
- Assessment. A short engagement: we inventory the source server, sample a few accounts, and produce a sizing and risk document.
- Pilot. A small set of pilot accounts (often the IT team) is migrated in parallel with the existing system.
- Bulk migration. The remaining accounts are migrated in waves, each wave running while the source server stays authoritative.
- Final delta and cutover. A short maintenance window flips MX, autoconfig and SRV records to Stalwart.
- Decommission. Source server is kept read-only for an agreed retention period, then retired.
- Indicative timeline: up to 1,000 mailboxes, 2-4 weeks; 1,000-10,000, 4-10 weeks; above 10,000, scoped per engagement.
Switch in one window, or live in both worlds for a while.
For most customers, a single cutover window is the simplest path: bulk and delta passes complete, MX and autoconfig flip, and the source server stops accepting new mail. When a single window is not viable, we run co-existence:
- Split-domain routing. Some users are answered by Stalwart, others by the source server, with a routing layer keeping mail flowing to whichever is authoritative for each address.
- Forwarding co-existence. The source server forwards a copy of all incoming mail to Stalwart while users finish moving; address books and calendars stay in sync via standard CalDAV/CardDAV.
- Read-only legacy. After cutover, the source server is left in read-only mode so users can pull historical data on demand, while all new traffic flows through Stalwart.
The migration is the same; the destination is your choice.
You can migrate onto your own self-hosted Stalwart deployment (Community or Enterprise edition) or onto Stalwart Managed Email. The assessment, pilot and cutover process are identical; the only difference is who runs the destination cluster.