Migrate Kopano Mailboxes to Grommunio or Zammad: Choose the Right Path

The right migration path depends on what you mean by “mailbox.” If you need a replacement for Kopano that keeps mail in a groupware mailbox, use grommunio’s Kopano migration path. If you want a shared support queue where incoming email becomes customer conversations and tickets, Zammad may fit—but it is a help desk, not a groupware mailbox replacement. Zammad’s current migration documentation does not list Kopano as a direct import source.

That distinction determines what a successful result looks like. In grommunio, users should be able to find their mail and, after separate migration work, the other supported groupware data they rely on. In Zammad, agents should see the selected correspondence as correctly grouped tickets and articles, with customers and ownership mapped according to your support workflow. Neither target should be treated as a byte-for-byte copy of Kopano without a pilot and an acceptance check.

Choose the target before copying data

grommunio’s migration overview recommends gromox-kdb2mt for Kopano/Zarafa and describes this path as moving complete mailboxes, including MAPI properties. Its separate IMAP path moves mail and folders, but not calendars or contacts. Read the current grommunio migration overview before choosing a tool.

Plan the migration and define acceptance checks

Start with an inventory rather than a bulk copy. Record each Kopano user, primary and alias addresses, store identifier, mailbox size, item counts, quota, shared folders, delegates, public folders, and the services that authenticate users. Note whether Kopano uses LDAP and whether attachments are stored in the database or in a filesystem layout. A mailbox transfer can move content while leaving directory configuration, mail routing, and permissions behind.

Choose a small pilot set that represents the real estate: one ordinary mailbox, one large mailbox, and any mailbox with shared access, non-English folder names, or unusual attachments. Back up the source and target, and make the first import into a disposable or otherwise clean target mailbox. Define measurable checks before running tools:

• Compare source and target folder trees and message counts, including nested folders.
• Open sample old and recent messages, verify sender and recipient display, dates, bodies, and attachments.
• Check unread and flagged states where the migration method is expected to preserve them.
• Test calendars, contacts, tasks, delegates, and shared resources separately; do not infer their success from a successful mail import.
• Record skipped objects, errors, and differences, then decide whether they are acceptable or require a different method.

Option A: migrate Kopano to grommunio

Use the Kopano database migration path when you need mailbox fidelity

For supported Kopano databases, grommunio documents a direct path using gromox-kdb2mt together with gromox-mt2exm. The first utility reads one store from a Kopano SQL database and its associated attachment storage; the second imports the transfer stream into a grommunio mailbox. Follow the invocation syntax and options for the versions you have installed instead of copying a generic command line from another deployment.

The source SQL service and required attachment files must be accessible to the migration process. The current gromox-kdb2mt manual lists supported database schema versions and notes that installations using attachment_storage=files_v1-x-y need the corresponding --l1 and --l2 options. If your source layout differs, pause and resolve the storage mapping before attempting a full import.

Prepare target domains and mailboxes before importing. If Kopano is backed by LDAP, decide whether grommunio will use the same directory and test user matching before transferring stores. The official Kopano migration guide describes a multi-step flow: configure the target’s directory integration where applicable, create stores, migrate user data, then switch mail routing. It also cautions that the guide may not cover every source installation.

Map users deliberately. Kopano’s database may identify stores through numeric or GUID metadata rather than a simple email address. grommunio documents kdb-uidextract as a helper for producing a user map from a live Kopano system; see the kdb-uidextract manual. Mapping matters for recipient addresses and access-control entries. A transfer can succeed technically while shared-folder permissions still point to identities that do not exist on the target.

Use IMAP synchronization only when its limits match your scope

If direct database migration is unavailable, or you only need email, IMAP synchronization can be a practical alternative when IMAP is enabled and reachable on Kopano. grommunio’s documented imapsync workflow supports repeatable full and delta runs and preserves mail folders, standard flags, and internal dates. Its limitations are material: IMAP does not transfer calendars, contacts, tasks, notes, server-side rules, delegations, public folders, or passwords.

Prepare target mailboxes and quotas first, secure credentials in protected files, and test connectivity before the first copy. Run an initial synchronization for one pilot mailbox, review the result in grommunio Web, then repeat a delta sync after mail flow is redirected. The detailed grommunio IMAP migration guide includes preparation, dry-run checks, folder mapping, delta synchronization, cutover, and troubleshooting. Avoid mirror or delete options unless you have verified exactly what they remove.

Option B: migrate selected correspondence into Zammad

Zammad organizes work as tickets with articles, customers, groups, and agents. It does not recreate an Exchange-style mailbox with calendar, contacts, tasks, folder permissions, and normal mail-client behavior. Its migration documentation currently lists supported source systems such as Freshdesk, Kayako, OTRS, and Zendesk, but not Kopano. The documentation says that unsupported source migrations require an API-based approach or custom migration work.

Before building an importer, define the conversion rules. Decide which Kopano mailboxes or folders represent support requests, how to group messages into conversations, how to match senders to Zammad customers, and how to map old ownership or categories to Zammad groups and agents. A mailbox is not automatically a ticket queue: personal correspondence, newsletters, drafts, and automated notices may not belong in customer-facing tickets.

For historical data, plan a controlled export-and-import process using a supported Zammad API or a custom migrator. Preserve original message dates and headers where the target data model allows, retain attachments, and log the source mailbox and message identifiers for traceability. Import a small sample into a new Zammad instance first. Zammad’s general migration rules state that source migrations are all-or-nothing and require a new instance; those rules concern its documented migration modules, so confirm the behavior of any custom importer separately.

Use Zammad’s email channel to connect the address that should create or receive new support correspondence after cutover. The current Zammad email-channel documentation describes connecting email providers and routing incoming messages. Treat channel setup and historical mailbox import as separate tasks. Do not point a live customer inbox at an untested importer: duplicate tickets, unexpected replies, or incorrect routing can affect real users.

Cut over without losing incoming mail

Keep Kopano available and backed up through the acceptance period. After the pilot passes, run the main migration and record a source baseline. Schedule a short change window to pause or redirect delivery, perform a final delta or catch-up import, switch MX or internal routing, and then send test messages from both inside and outside the organization. The grommunio migration overview specifically recommends a final delta run after the DNS/MX switch so messages arriving during the transition are not missed.

Update user sign-in, client configuration, autodiscovery, mobile devices, aliases, relay rules, and any application that sends through Kopano. These are separate from copying mailbox data. Keep a rollback plan: know how to route mail back, how users will access the original server, and who may authorize a rollback if the target fails acceptance.

How to judge the result—and when to change approach

A migration is ready for normal use when the target’s folders and representative content match the source within the agreed tolerance, users can find recent and historical messages, attachments open, and mail flow works in both directions. For grommunio, separately verify calendar and contact migration, shared access, directory login, and client behavior. For Zammad, verify ticket boundaries, article order, customer matches, visibility, assignment, and that old messages did not trigger unintended outbound responses.

Change methods if the pilot shows missing MAPI data, broken attachments, unresolved ACLs, or a need to preserve groupware features that an IMAP copy cannot carry. For Zammad, reconsider the destination if the main requirement is personal mailbox continuity or calendar/contact support. A custom migration can bridge data models, but it adds mapping, testing, and maintenance work; it is not equivalent to a native Kopano mailbox import. Keep Kopano read-only or retain a separate archive until users and administrators can verify the records they need.