How long does an email migration really take? Three real examples

• Timelines ran from 1 month to 8. About 1,000 users took a month, about 5,000 took 2.5 months, about 60,000 took 8 months.

• Bigger projects usually run in waves. The larger the project, the more users move per month, because the work is parallelised, not because it is easier. This is the general pattern, not a description of how these three were run.

• Scope changes the work. Mail, contacts and calendars are the baseline. Signatures, rules and documents each add mapping and checking.

• Cloud was the shorter path. Both cloud projects finished in under three months. The only on-premises project took 8 months, and it was also by far the biggest.

All three projects started on Zimbra. Two moved to IceWarp Cloud, one to IceWarp on-premises. The timelines run from one month to eight, and the reasons for that spread are more useful than the headline numbers.

Company A Moved from: Zimbra Moved to: IceWarp on-premises (self-hosted) Users: about 60,000 Duration: 8 months What moved: Mail, contacts, calendars, signatures and more

Company B Moved from: Zimbra Moved to: IceWarp Cloud Users: about 5,000 Duration: 2.5 months What moved: Mail, contacts, calendars, signatures, rules, documents and more

Company C

Moved from: Zimbra Moved to: IceWarp Cloud Users: about 1,000 Duration: 1 month What moved: Mail, contacts, calendars

Duration means the whole project, from the first day of work to the day users could fully work on the new system.

More users means more time, but not in a straight line. Rough pace, based on the figures above:

• Company C: about 1,000 users in 1 month, around 1,000 users a month.

• Company B: about 5,000 users in 2.5 months, around 2,000 users a month.

• Company A: about 60,000 users in 8 months, around 7,500 users a month.

The larger the project, the more users moved per month. That does not mean big migrations are easier. In general it means large projects run in waves, with several batches handled in parallel by a dedicated team, while small ones can be done in one or two steps.

A telecom provider in Cyprus moved its Zimbra environment of about 60,000 users to IceWarp on-premises, self-hosted. Mail, contacts, calendars, signatures and more were migrated.

Self-hosted projects of this size typically include extra steps before and around the data move: sizing and ordering hardware, setting up the servers, testing with a pilot group, and moving users in waves. These are general characteristics of on-premises migrations, not a breakdown of this project.

A political party in Austria moved about 5,000 users from Zimbra to IceWarp Cloud in two and a half months. This project had the widest scope of the three: mail, contacts, calendars, signatures, rules and documents all came across.

A municipal government in Brazil moved about 1,000 users from Zimbra to IceWarp Cloud in one month. The scope was the core: mail, contacts and calendars. A smaller scope and no infrastructure to set up on the customer side both generally shorten a project.

The three projects differ in three ways, and each one can affect the timeline.

1. Number of users

The most obvious factor. Batches, pilot groups and user communication all grow with headcount.

2. Where the new system runs

The two cloud projects finished in 1 and 2.5 months. The only on-premises project took 8 months. Careful with that comparison: the on-premises project is also 12 to 60 times bigger, so size and deployment type are mixed together. On-premises also adds hardware lead times and server setup, which a cloud project skips.

3. What moves with the mailboxes

Mail, contacts and calendars are the baseline. Signatures, rules and documents add work, because each has to be mapped, moved and checked. Company B moved the most and still finished in 2.5 months, so scope matters, but it is not the only driver.

The mailbox copy is only one part of a migration. In general, these are the things that most often stretch a timeline:

• Planning and discovery. Counting users, mailbox sizes, archives, shared mailboxes and aliases before anything moves.

• Hardware and infrastructure. For self-hosted setups, ordering, delivery and configuration of servers can happen long before the first mailbox moves.

• Running both systems in parallel. Keeping old and new side by side lowers risk, but it means managing two systems for a while.

• Big bang or phased. One weekend for everyone is fast but unforgiving. Moving in batches takes longer but keeps problems small.

• Pilot users. A small test group finds the surprises while they are still cheap to fix.

• The DNS and MX switch. Small on paper, stressful in practice. Lower TTL values ahead of time and pick a quiet window.

• Large mailboxes and old attachments. Years of data add up. Cleaning up beforehand saves time.

• People. Users need to know what changes, when, and who to ask.

• Timing. Cutovers right before holidays or peak periods tend to cause trouble.

Timelines are only half the story. The other half is why teams move and whether the move holds up. Three published IceWarp customer stories add that side.

Smartwings: leaving MS Exchange over cost

Smartwings, the largest airline in the Czech Republic, switched to IceWarp in 2003. The IT manager recalls that they "grew tired of MS Exchange because it was both expensive and felt heavy-footed". The company went from about 100 employees to over 1,500 active mailboxes and, two decades later, still runs on IceWarp.

VŠÚO Holovousy: migration handled by specialists

VŠÚO, a Czech fruit research institute with 100 users, tried MS Exchange and Kerio before choosing IceWarp. The migration was done by IceWarp's migration team: they analysed the environment, proposed a migration method and carried out the whole process. In the IT manager's words, initial concerns "quickly became widespread satisfaction".

Big Sandy Medical Center: avoiding the Microsoft 365 bill

Big Sandy Medical Center in Montana (100 users, hosted IceWarp with cloud storage) had a poor email service with severely limited functionality. Microsoft 365 would have put them well over budget "for functions we wouldn't use", so they chose a setup where they only pay for the tools they need. IceWarp also provided a plan for working towards HIPAA compliance.

How long does an email migration take? It depends on the number of users, the target, and the scope. In the three projects above it ranged from 1 month for about 1,000 users to 8 months for about 60,000 users.

What can be migrated? In these projects: mail, contacts and calendars in all three, plus signatures in two, and rules and documents in one.

Can users keep working during the migration? In most migrations users keep working while data is copied, followed by a short planned switch of mail delivery at the end.

Do we have to run the old and new systems in parallel? No, but many teams do. Parallel running lowers risk and allows testing with real users, at the cost of managing two systems for a while.

Is a phased migration better than a big bang? Neither is always better. A big bang is faster and simpler to communicate. A phased migration takes longer but keeps any problems small. Larger organisations tend to prefer phases.

Can I migrate from Exchange or Microsoft 365 as well? Yes. IceWarp offers native migration utilities for legacy Exchange and imports from Microsoft 365, Google Workspace and existing mail servers. The three timelines in this article come from Zimbra projects, so your own timeline will depend on your users and scope.

Should we choose cloud or on-premises? IceWarp offers both. Cloud is quicker to start. On-premises gives you full control over where data lives.

What happens to the DNS and MX records? MX records tell the internet where to deliver your mail, so they are switched when you cut over. Lowering the TTL beforehand and choosing a quiet time keeps the switch smooth.

Can you promise how long our migration will take? No. We can scope it with you once we know your users, data and requirements.