IceWarp Migration Guide India — Move from Exchange, Zimbra or Gmail

Migrating your organisation's email is one of the highest-risk IT operations a business undertakes. Done correctly, users notice nothing except a slightly different interface. Done poorly, email is lost, delayed or disrupted for days.

This guide covers the IceWarp migration process as Cloudfy executes it for Indian organisations. It applies to migrations from Microsoft Exchange Server, Microsoft 365, Zimbra, cPanel/WHM, hMailServer, Postfix and Gmail/Google Workspace.

Before You Start — Migration Planning

A successful IceWarp migration starts with planning, not with clicking buttons.

Inventory Your Current Environment

Before Cloudfy begins any migration, we collect:

• Current email server platform and version
• Total number of mailboxes and users
• Average mailbox size (and any very large mailboxes to flag)
• Shared mailboxes, distribution lists and aliases
• Calendar and contact data to be migrated
• Retention requirements (how far back email needs to go)
• Business-critical users (prioritise for early migration and testing)
• Current MX, SPF, DKIM and DMARC DNS records

Define the Target IceWarp Setup

Decide upfront:

• Deployment: cloud-hosted by Cloudfy or on-premise on your servers
• Domain: same domain as current email or new domain
• Mobile sync: ActiveSync for all devices or selective
• Outlook connector: needed for Windows users using Outlook
• Anti-spam configuration: custom rules or default IceWarp engine

Migration Window

Migrations are planned for low-traffic periods — typically Friday night to Saturday morning for most Indian businesses. Critical email services are never left in a split state across business hours.

Phase 1 — IceWarp Server Setup

Before migrating any data, the destination IceWarp server must be fully operational.

Cloud-Hosted Setup (Cloudfy-managed)

1. Cloudfy provisions the IceWarp server on Indian cloud infrastructure
2. IceWarp is installed, configured and hardened
3. Your domain is added to IceWarp
4. SSL certificate (Let's Encrypt or commercial) is installed
5. Anti-spam engine is configured and tested
6. Admin access is verified

On-Premise Setup

1. Server hardware or VM is provisioned (Windows or Linux)
2. IceWarp is downloaded, installed and licensed
3. Initial domain and admin configuration
4. SSL and firewall rules configured
5. Server-to-internet connectivity verified (SMTP port 25 outbound, IMAP/SMTP inbound on standard ports)

At this stage, the IceWarp server is live but MX records still point to your old server. No user mail flows to IceWarp yet.

Phase 2 — Data Migration

IMAP Migration (Works for Most Sources)

The safest migration method for most platforms is IMAP-to-IMAP. IceWarp's built-in migration tool or Cloudfy's migration scripts connect to your old server over IMAP and copy all mail, folders and flags to IceWarp.

This method works for:

• Microsoft Exchange Server (with IMAP enabled)
• Microsoft 365 / Exchange Online
• Google Workspace / Gmail
• Zimbra
• cPanel/WHM (Dovecot)
• hMailServer
• Any IMAP-compatible mail server

Migration Steps (IMAP Method)

1. Cloudfy creates matching accounts on IceWarp for all users
2. Migration tool is configured with source server credentials
3. A test migration runs for 2–3 pilot mailboxes
4. Pilot users verify email, folders and sent items are complete
5. Full migration runs for all mailboxes (runs in parallel, typically overnight)
6. Migration completes — all historical email is on IceWarp

During migration, users continue working on the old server. Email keeps arriving at the old server. This is a read-only copy of historical mail — live email flow has not changed yet.

Exchange-Specific Considerations

For on-premise Exchange migrations, Cloudfy can also use Exchange's native export (PST) or direct MAPI migration for organisations where IMAP is not enabled. Public folders require special handling — we migrate these as shared mailboxes on IceWarp.

Calendar and Contact Migration

• Calendars: Exported from Exchange/365/Zimbra as .ics files and imported into IceWarp CalDAV
• Contacts: Exported as .vcf and imported into IceWarp CardDAV
• Shared calendars and contact lists: Recreated as IceWarp shared resources

Phase 3 — DNS Cutover

This is the step where live email starts flowing to IceWarp. It must be planned precisely.

Pre-Cutover Checklist

• All mailboxes created on IceWarp
• Historical email migration complete and verified
• Calendars and contacts migrated
• SPF record updated to include IceWarp's sending IP
• DKIM configured and key published in DNS
• DMARC policy set to p=none monitoring mode for first 30 days
• MX record change prepared (new value ready, TTL reduced to 300 seconds 24 hours before cutover)
• Pilot users verified on IceWarp (Outlook connector or webmail)

The Cutover Sequence

1. T-24h: Reduce MX TTL to 300 seconds
2. T-0: Change MX records to point to IceWarp server
3. T+5min: Verify new MX is resolving with nslookup or dig
4. T+15min: Send test email to the domain from an external address — verify it arrives at IceWarp
5. T+30min: Pilot users log into IceWarp webmail or configure Outlook Connector
6. T+2h: All users migrated to IceWarp clients
7. T+24h: Old server kept running in receive-only mode for any delayed delivery
8. T+72h: Old server decommissioned

SPF Record Update

Your SPF record must include IceWarp's sending IP address:

v=spf1 ip4:[ICEWARP-SERVER-IP] include:yourdomain.com ~all

Cloudfy provides the exact SPF string for your IceWarp deployment.

DKIM Configuration

IceWarp generates DKIM keys internally. Cloudfy publishes the public key as a TXT record in your DNS:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=[PUBLIC-KEY]"

Phase 4 — Post-Migration Verification

Email Flow Check

• Send and receive email from external domains (Gmail, Outlook.com)
• Verify reply-to, CC and BCC behaviour
• Check that forwarding rules (if any) are preserved
• Verify auto-responders and distribution lists

Anti-Spam Check

• Check spam filter is catching obvious test spam
• Whitelist any legitimate senders that were being flagged
• Configure custom block lists if needed

Mobile and Desktop Client Setup

• Configure ActiveSync for mobile devices
• Install and configure Outlook Connector for Windows users
• Verify calendar sync on mobile

DMARC Monitoring

After cutover, check your DMARC aggregate reports (available from your DMARC reporting provider) to verify all legitimate mail is passing SPF and DKIM. Only move DMARC to p=quarantine or p=reject after 30 days of clean reports.

Common Migration Issues and How Cloudfy Handles Them

After Migration — What Cloudfy Supports

Cloudfy's migration engagement does not end at cutover. We provide:

• 30-day post-migration support — resolving any client configuration issues, anti-spam tuning, mobile setup
• Admin training — how to create/delete users, manage aliases, configure shared mailboxes in IceWarp Admin Console
• Ongoing managed support — optional monthly support contract for server health, updates and user management

Get Started with IceWarp Migration

If you are planning to move your organisation's email to IceWarp, contact Cloudfy for a migration scoping call. We will review your current environment, estimate migration duration and provide a fixed-fee migration quote.

→ IceWarp services at Cloudfy → Contact Cloudfy for migration scoping → IceWarp pricing guide — cloud vs on-premise

FAQ

How long does an IceWarp migration take?

For most organisations (up to 200 users with average mailbox size under 10GB), the full migration — planning, setup, data migration and cutover — takes 3–7 business days. Very large deployments (500+ users or large mailboxes) may take 2–3 weeks.

Will there be any email downtime during migration?

With proper planning, email downtime is zero. Mail continues flowing to the old server until the MX cutover, at which point new mail goes to IceWarp immediately. Historical mail has already been migrated before cutover.

Can we run both servers in parallel during migration?

Yes. We keep the old server live and receiving mail until the MX cutover. After cutover, the old server is kept in a receive-only mode for 72 hours to catch any delayed deliveries.

What if we need to roll back to the old server?

We keep the old server intact until 72 hours after cutover and migration is verified. If a rollback is needed, we change the MX record back. This is an emergency option; in practice, rollbacks are extremely rare.