Migrate from Microsoft Exchange to grommunio

Migrate from Microsoft Exchange to grommunio: what the move involves

grommunio presents itself as a native Exchange drop-in replacement, and its exchange2grommunio script moves each mailbox by exporting it to PST on the Exchange side and importing it on the grommunio server over SSH. The effort is driven less by the software than by two things: whether grommunio can use the same LDAP or Active Directory as Exchange, and how many mailboxes and how much data each one holds. Teams usually choose this move after a renewal notice, a licensing change for Exchange Server, a data residency requirement or a wish to reduce dependence on a single vendor. Exchange Server Subscription Edition reached general availability on July 1, 2025, and Exchange Server 2019 left extended support in October 2025, so organizations still on 2019 have a clear deadline to decide. Those dates frame the decision; the migration itself is a separate project.

The work is normally run by the internal messaging and Active Directory team, usually with an implementation partner for the grommunio appliance, hardening and the cutover runbook. The script runs from an elevated Exchange Management Shell on Windows Server 2012 R2 or newer and needs a shared folder that Exchange can write to and the grommunio server can mount. Confirm those prerequisites, the directory design and the mailbox inventory with the grommunio documentation for your version before you schedule anything. Mail itself moves well. Calendars, delegates, shared mailboxes, client profiles and the timing of the DNS and client switch need explicit planning. PST export captures mailbox content, but you must test how meeting data, permissions and Outlook profiles come across, and decide how users reconnect. Plan a pilot group, a rollback path and a coexistence period, and check with your Outlook, mobile and calendar-sharing users before the first production run.

Which Exchange capabilities map cleanly to grommunio and which need rework

This table compares common Exchange capabilities with what grommunio covers natively, what needs rework during migration, and where a gap exists. Read each row as a starting point for your own test plan, since the grommunio documentation and your pilot results decide the final status for compliance and archive features.

Capability	Status	What to expect on grommunio
Mailboxes and Outlook connectivity (MAPI/HTTP, RPC/HTTP, EWS)	Clean	grommunio documents MAPI/HTTP, RPC/HTTP, EWS and ActiveSync, so existing Outlook clients can usually keep connecting. Confirm client versions in a pilot.
Mobile access (ActiveSync)	Clean	grommunio-sync provides ActiveSync for native iOS and Android clients. Re-test device policies and wipe behavior before cutover.
Calendars and contacts	Needs rework	Calendars and contacts move through the PST export path and CalDAV or CardDAV is available. Verify recurring meetings, free/busy lookups and shared calendars with real users.
Active Directory dependency	Needs rework	The migration script requires grommunio to use the same LDAP or Active Directory as Exchange. Plan directory integration before any mailbox moves.
Archive mailboxes	Gap or rework	The PST export path must cover primary and archive mailboxes separately. Confirm archive handling against the grommunio migration documentation and your own test mailboxes.
Shared mailboxes and delegates	Needs rework	Confirm how shared mailboxes, send-as rights and delegate permissions are represented after import. Test each permission type in a pilot.
Transport rules and journaling	Gap	Transport rules and journaling are server-side Exchange features that do not transfer automatically. Confirm equivalent mail flow controls in grommunio before retiring Exchange.
Litigation hold and eDiscovery	Gap	Exchange holds and eDiscovery search are not carried over by the PST migration. Confirm compliance and retention options with grommunio and your legal team.

How the exchange2grommunio script moves each mailbox

The exchange2grommunio.ps1 script runs in two stages. On the Exchange side, New-MailboxExportRequest writes each mailbox to a PST file. On the grommunio side, gromox-pff2mt reads that PST and pipes its output into gromox-mt2exm, which imports the content into the target mailbox. The import runs on the grommunio server and is reached over SSH, so the Exchange host needs a working SSH path to the grommunio appliance before the first mailbox is attempted. Because the export and import are separate steps tied to a per-mailbox log, a failed mailbox can be retried without repeating mailboxes that already succeeded.

The script must run from an elevated Exchange Management Shell on Windows Server 2012 R2 or newer, under an account that holds the Mailbox Import Export role. Exchange writes the PST files to a shared folder, and that same folder must be mountable on the grommunio server so the import stage can read them. Confirm the share's UNC path, the write permissions for the Exchange computer account, and the read access for the grommunio side before a test run. Plan free disk space on both sides for the largest PST files, since each mailbox is fully exported before it is imported.

Before any production run, confirm that grommunio uses the same LDAP or Active Directory as Exchange, because the script maps each mailbox to an existing directory account. Run a single pilot mailbox end to end, then check the success and failure logs the script writes and confirm the message count and folder structure in the grommunio web client. Ask your grommunio partner to confirm the script version and supported Exchange builds for your environment, since the documented requirements are the authoritative source for the exact prerequisites. Keep the export share and PST files under access control until each mailbox is verified and the run is closed.

What data and integrations need to move or be rebuilt

Mailboxes are only part of an Exchange deployment. Identities, calendars, contacts, mobile devices and every application that sends mail through Exchange each need an explicit decision before cutover. The cards below treat these as parallel workstreams, each with its own owner and check.

Mailbox content through PST

The exchange2grommunio script exports each Exchange mailbox to PST with New-MailboxExportRequest, then imports it on the grommunio server over SSH through gromox-pff2mt and gromox-mt2exm. Confirm the Mailbox Import Export role, the writable shared folder and the Windows Server version before the first run. Because the script logs successes and failures, plan a retry list for mailboxes that fail and rerun them rather than assuming a clean pass. Archive mailboxes and folder filters need their own test, since they are handled separately from primary mailboxes.

Directory identities through shared LDAP

The script requires grommunio to use the same LDAP or Active Directory as Exchange, so user identities, group membership and address lookups stay consistent after cutover. Before migrating, confirm that every migrated mailbox maps to a directory account that grommunio can resolve, and that service accounts used by the migration have the rights they need. Disabled, orphaned or duplicate accounts will surface as failed imports or mailboxes that users cannot open. Decide who owns directory changes during the cutover window.

Calendars and contacts through CalDAV and CardDAV

Calendars and contacts are not part of a mailbox import that carries mail alone, so each needs a deliberate path. grommunio-dav provides CalDAV and CardDAV for clients that support these protocols. Test shared calendars, delegate access and resource bookings with real Outlook and mobile users before announcing the cutover. Note which clients will sync contacts and calendars natively and which will need a manual reconfiguration step.

Mobile devices through grommunio-sync

grommunio-sync provides Exchange ActiveSync for native iOS and Android clients, so phones that already use Exchange accounts can usually be reconnected to grommunio. Plan for each device to re-enter or re-validate its account, and expect some users to lose local cache and need a resync. Decide how remote wipe and device policies will be enforced, and confirm that every mobile policy you rely on is supported before you retire the Exchange policy set.

SMTP relays and application mail flows

Printers, scanners, line-of-business applications, monitoring tools and journaling rules often send mail through Exchange connectors that the mailbox export never touches. Inventory every send connector, smart host, relay IP allow list and journaling target, including the ones that no user owns. For each, decide whether it points to grommunio, to a relay, or to a replacement service, and test sending from the application with the new target. Missing this inventory is the most common reason a cutover looks successful but breaks invoices, alerts or scans.

The migration sequence from inventory to Exchange decommissioning

This sequence moves mailboxes from Exchange to grommunio in controlled stages, so each stage produces evidence that the next one can rely on. It ends with Exchange switched off only after retention obligations are confirmed as met.

Inventory mailboxes, archives and mail flow
The Exchange administrator and the messaging owner list every mailbox with its size, primary and archive status, delegates, shared mailboxes, distribution groups, and the applications or devices that relay mail through Exchange. They also record which Outlook, mobile and ActiveSync clients are in use and their versions. Confirm that grommunio will use the same LDAP or Active Directory as Exchange, because the migration script depends on it. The step is done when the inventory is signed off and every mailbox has a named owner and a target wave.
Pilot with a small mailbox group
Choose a small group of mailboxes that includes a delegate and a shared mailbox, and run the exchange2grommunio script against them from an elevated Exchange Management Shell. Check that each mailbox exports to PST, imports over SSH, and appears in the expected client. If you are evaluating the free Community package, confirm that the pilot stays within its limit of 5 users, and confirm with grommunio that your pilot is supported under the package you intend to use. The pilot is complete when the success log matches the mailbox list and users confirm their folders, calendars and contacts.
Run the production waves in parallel
Migrate the remaining waves while Exchange keeps running, and check mail flow between both systems after each wave. Verify that inbound and outbound routes, the relays from line-of-business applications and the directory entries resolve to the correct server. Review the failure log after each run, correct the cause, and rerun only the failed mailboxes, relying on the script's logging so that completed mailboxes are not imported twice. The step closes when every wave shows zero unexplained failures and mail flow tests pass in both directions.
Cut over with a defined window and Outlook guidance
Agree a cutover window with the business owners, freeze mailbox changes for the affected users, and run the final incremental import. Switch the MX records, the relays and the client autodiscovery settings to grommunio. Give each user written Outlook profile instructions, including whether an existing profile must be recreated, and test shared calendars and delegate access before the window closes. The cutover is done when users can send and receive mail on grommunio, the helpdesk has a log of profile issues, and the rollback plan has been tested or confirmed as not needed.
Decommission Exchange after retention is satisfied
Before you turn off Exchange, confirm with legal, compliance and records owners that every retention hold, litigation hold and archive requirement is met, either by exporting the data to a retained store or by confirming that the migrated copies meet the same obligations. Keep a final export of mailbox data as the agreed records source, then remove the Exchange servers, licenses and connectors. The step is complete when the records owner signs the retention checklist and the decommission record shows the removed systems and the retained export location.

What drives migration cost and duration, and how to keep each down

This table lists the factors that change the effort and cost of moving Exchange mailboxes to grommunio, along with the one-time or recurring nature of each. Read it as a checklist to scope a written quote, since most drivers are set by your own environment rather than by the software.

Cost driver	Why it changes cost or effort	How to keep it down
Mailbox count and total size	Each mailbox is exported to PST and imported over SSH, so run time and storage for PST files grow with volume.	Pilot a representative batch first, then schedule waves by mailbox size. Ask the partner to state the assumed data volume in the quote.
Archive mailboxes and large PST handling	Archive mailboxes are separate stores that must be exported and mapped, and very large PST files can slow or fail imports.	Inventory archives before the project starts. Decide which old data stays in a read-only archive instead of moving.
Folder filters and retention scope	Deciding which folders and date ranges move changes both the number of export requests and the review effort.	Agree the in-scope folders and date range in writing before the first run, so no one re-exports later.
Directory alignment	The script requires grommunio to use the same LDAP or Active Directory as Exchange, so directory cleanup, group mapping and account matching can add work before any mail moves.	Audit accounts, stale users and distribution groups early. Ask the quote to list who performs directory changes and who signs off on them.
Outlook and mobile client profiles	Each Outlook profile, shared mailbox, delegate setup and phone configuration needs testing and, in some cases, reconfiguration after cutover.	Group users by client type (Outlook on Windows, Outlook on Mac, iOS, Android). Test one profile of each type before the wider rollout.
Custom transport rules and application relays	Scanners, line-of-business applications and SMTP relays that send through Exchange need new routes and tests, and custom transport rules must be re-created.	List every system that sends mail or depends on Exchange connectors. Assign each one a named owner and a test case.
grommunio subscription tier	The Community package covers up to 5 users without manufacturer support. Basic, Plus and Business are priced per user per month from set user thresholds, and Enterprise is custom from 1,000 users. Licenses are sold only through certified partners. Recurring.	Size the tier to the real user count and support needs. Ask the partner to quote each tier separately, with the support terms and the pricing source named in writing.
Partner or internal labor	Partner fees cover scoping, scripting, testing and cutover support. Internal staff time covers directory work, user communication and sign-off. Labor is mostly one-time, while support may recur.	Split the quote into fixed-scope phases with written deliverables. Ask which tasks your own team owns so you do not pay twice for the same work.
Ongoing support and upgrades	After cutover, patches, backups and upgrades of the appliance or containers recur and depend on the chosen support model.	Ask for the support model, upgrade process and backup approach in the quote. Confirm any retainer terms in writing.

How the migration differs by organization size and starting point

Teams at or under the Community package limit of 5 users usually have a small Active Directory or LDAP footprint and a short list of mailboxes. The grommunio pricing page lists a free Community package for up to 5 users, but that package comes without manufacturer support, so the operator carries all troubleshooting, patching and recovery. The migration script still expects the same LDAP or Active Directory that Exchange uses, so the directory work does not disappear at this size.

Directory: Confirm that grommunio can read the same LDAP or Active Directory as the current Exchange server before exporting anything.
Cutover: A short mailbox list makes a single planned window practical, but keep the Exchange server available for rollback until users have verified their mail.
Support: No manufacturer support comes with the Community package, so assign one internal owner for backups, updates and incident response.
Outlook clients: Test MAPI/HTTP profile creation on each desktop before cutover, since small teams often have no one to rebuild profiles at short notice.
Mobile devices: Test grommunio-sync with each iOS and Android device that users rely on.

Before committing, ask whether a single operator can keep the server patched and restored without vendor help, and whether the team needs a partner-sold tier for support instead.

What usually goes wrong in an Exchange to grommunio move

Most problems in an Exchange to grommunio move trace back to three places: the directory, the export and import runs, and the mail and client changes around cutover. The cards below cover the failure points we see most often, with a prevention step for each. Check them before the first mailbox moves, not after users report missing data.

Directory mismatch breaks the import

The exchange2grommunio script requires grommunio to use the same LDAP or Active Directory as Exchange. If the grommunio server points at a different directory, or user objects, aliases and SMTP addresses do not match, mailboxes land under the wrong accounts or fail to resolve. Before running anything, confirm that every source mailbox maps to an existing grommunio user and that primary addresses are identical in both systems.

Partial exports missed in log review

Each mailbox is exported to PST with New-MailboxExportRequest and then imported over SSH, and the script logs successes and failures so a run can resume. A run that looks finished can still hold failed mailboxes, and an unread log hides them until a user reports missing mail. Review the failure entries after every batch, rerun only the failed mailboxes, and keep the logs as migration evidence.

Shared folder permission errors

The PST files travel through a shared folder that Exchange must write to and the grommunio server must mount. Missing write rights for the Exchange side, or a mount that is not available on the grommunio host, cause exports to fail before any data moves. Test write access from the Exchange server and read access from grommunio with a small test mailbox, and confirm the mount persists across reboots.

Delegates and calendars lost in transit

Mailbox exports carry folder content, but delegate permissions, shared calendar grants and free/busy visibility depend on how each object is recreated on the target. Those permissions often exist only on the Exchange side and are not reapplied automatically. Build a list of delegates and shared calendars for pilot users before cutover, then recreate and test each one on grommunio with a named tester.

Outlook profile changes confuse users

Users who keep Outlook will see a different server and profile after cutover, and some will get prompts for credentials, new certificates or a rebuilt profile. Without notice, they may assume mail was lost and create duplicate profiles or archive files. Publish a short guide covering the new profile steps, the expected prompts and a help contact, and test the MAPI/HTTP, EWS and ActiveSync paths on the Outlook versions your users run.

Forgotten relays keep sending mail

Scanners, line-of-business applications, printers and partner gateways often send through the old Exchange server or a relay tied to it. When the Exchange server is switched off or its DNS record changes, that mail fails silently or bounces. Inventory every system that relays through Exchange, point each one at grommunio or a documented relay, and keep Exchange running in receive-only mode until the inventory shows no traffic.

Questions buyers ask before moving from Exchange to grommunio

How long does an Exchange to grommunio migration take?

No migration duration is published for this script, so the timeline has to be confirmed with grommunio and fixed in a written scope for your environment. The main drivers are total mailbox size, the number of mailboxes and archive mailboxes, and the throughput of the shared folder and network path between Exchange, the file share and the grommunio server. Directory state matters as much as data volume. Users must already exist in the same LDAP or Active Directory that grommunio uses, so disabled accounts, orphaned mailboxes or duplicate identities add rework before any export starts. Ask for a pilot batch of representative mailboxes so you can measure throughput on your own data before setting a cutover date.

What does the migration need from our internal team?

The work needs four groups of people and access, all in place before the first export:

An Exchange administrator who can run the script from an elevated Exchange Management Shell on Windows Server 2012 R2 or newer, with the permissions required for New-MailboxExportRequest.
A shared folder that Exchange can write to and that the grommunio server can mount, used for the PST files.
Directory ownership, meaning one LDAP or Active Directory serving both systems, with clean user objects and known mailbox owners.
A person who owns DNS, certificates, SSH access between the hosts, and the mail routing change at cutover.

Confirm the exact permissions and host preparation steps with grommunio before you plan staffing, because the documentation is the source of truth for the script version you run.

Can our own team run the Exchange to grommunio migration?

A team with solid Exchange and Linux skills can attempt it, because the script and its documentation are public. Whether that is the right choice depends on mailbox volume, how many cutover windows you can staff, and how much rollback planning your change board expects. Failed batches, directory mismatches and client reconfiguration tend to consume more time than the copy itself. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support, upgrades and continuous testing are available as retainers.

Does Outlook stay the same after cutover to grommunio?

Outlook can stay in use, because grommunio states that organizations can keep their existing Microsoft Outlook clients through its MAPI/HTTP, EWS and Exchange ActiveSync support. Users should still expect some client work at cutover, including profile or autodiscover changes, certificate trust for the new server name, and handling of cached offline data. Shared calendars, delegates and resource mailboxes are the areas most likely to need testing with real accounts before the switch. Native iOS and Android mail clients connect through grommunio-sync over ActiveSync. Ask grommunio to confirm which Outlook versions and connection modes it has validated with your planned configuration, and run a pilot group through the full set of daily tasks first.

How do failed migration runs get resumed in grommunio?

The exchange2grommunio.ps1 script logs each mailbox as a success or a failure, which allows a run to resume without treating the whole batch as lost. The flow for each mailbox is an export to PST with New-MailboxExportRequest, then an import on the grommunio server over SSH, where gromox-pff2mt is piped into gromox-mt2exm. Before rerunning, check the logs for the failing mailboxes, confirm that the PST file exists and is complete on the shared folder, and clear any stale export requests so they do not block the retry. Ask grommunio to confirm the log locations, the exact resume behavior for your script version, and how item counts are reconciled after a partial import.

Is grommunio free to use, and what do paid tiers cost?

The free Community package covers up to 5 users, but it comes without manufacturer support. From 6 users, grommunio lists Basic at 1.99 euros and Plus at 3.99 euros per user per month, Business at 5.49 euros from 50 users, and custom Enterprise pricing from 1,000 users, according to its pricing page. Licenses are sold only through certified partners, so confirm which partner is certified for your tier and what each tier includes. Software licensing is only one cost. Budget also for the server or virtual machines, storage for PST staging and mailboxes, backup, the internal staff who run it, and the migration work itself. Check the current prices on the pricing page before you build a business case.

What does a fixed-scope DeployOpen engagement for grommunio cover?

A fixed-scope engagement covers the work listed in an agreed written scope, including the deliverables and timelines that the scope defines. For a migration, that can include planning the directory and mailbox inventory, preparing the Exchange export side, running and monitoring import batches, checking results, hardening the grommunio host, setting up backup, documenting the procedure and supporting cutover. The quote follows from that written scope, because DeployOpen does not publish a price list. DeployOpen does not issue audit reports or certifications, so if your compliance team needs evidence for an assessment, ask which controls and records the scope will produce and which independent auditor will review them.

How to run Exchange and grommunio in parallel and cut over safely

Keep Exchange as the system of record until the pilot passes. The exchange2grommunio script copies mailboxes as a point-in-time export, so mail that arrives in Exchange after an export does not appear in grommunio unless you run a later pass or plan a final delta. Decide before the pilot how mail flow will work during the overlap: which domain stays on Exchange, whether inbound mail is still delivered to Exchange and relayed to grommunio for migrated recipients, and how outbound mail leaves. Your mail flow routing (MX records, the Exchange send connector, and any smart host or gateway) decides where a message lands during the window, so write that routing down and test it with two or three pilot accounts before any production user moves.

Plan the cutover window around the final mailbox pass rather than the calendar. The script works through each mailbox, logs successes and failures, and can be resumed, so the failed-mailbox list from the last pass should be empty or fully understood before you switch DNS and routing. Confirm with the grommunio documentation on the migration guide how mailboxes are re-run and how the grommunio side is kept in step with the same LDAP or Active Directory, since a directory mismatch during cutover is the most common cause of a mailbox landing in the wrong place. Also confirm how the Exchange export requests are cleaned up afterwards.

Test what Outlook users actually see when their account moves. Because grommunio supports MAPI/HTTP, EWS and RPC/HTTP, a profile may reconnect without a rebuild, but the exact behavior depends on the Outlook version, autodiscover configuration, cached mode and whether the account's profile points at a name that changes during cutover. Use test mailboxes with realistic folder trees, shared calendars, delegates and a mailbox that has an open meeting request. Confirm the expected client behavior in the grommunio documentation, then record what your own test users see, including prompts, re-sync time and any items that do not appear. Share that result with the users who will be moved.

How DeployOpen scopes, runs and supports an Exchange to grommunio migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, including grommunio. For an Exchange to grommunio move, we start from a written scope that names the mailboxes, directory dependencies, client types and cutover window involved, then build and test the migration path in your environment before any production mailbox moves.

How we scope

Inventory Exchange mailboxes, archives, shared mailboxes and delegates that the written scope will move.
Confirm the LDAP or Active Directory arrangement, since the exchange2grommunio script requires grommunio to use the same directory as Exchange.
Agree in writing which Outlook, Exchange ActiveSync and CalDAV or CardDAV client types must work after cutover, and which are out of scope.

How we build

Prepare the grommunio server from its appliance images or documented installation, with the shared folder the script needs mounted and writable.
Run the exchange2grommunio.ps1 export and import against a pilot set of test mailboxes, checking the success and failure logs before wider runs.
Test resumed runs after a simulated failure, and verify calendars, folders and delegate access in Outlook and mobile clients.

How we hand over

Document the scoped procedure, including the Mailbox Import Export role, PST staging, log review and how failed mailboxes are retried.
Provide a user communication and cutover runbook covering what Outlook users will see after cutover and how profiles are updated.
Deliver the configuration, test results and open items to your team, so they can run and maintain the grommunio environment.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask for a quote based on the written scope, and confirm grommunio subscription terms and licensing with a certified partner.

Migrate from Microsoft Exchange to grommunio