Transfer Email Accounts Without Downtime | TrekMail

You can’t transfer email accounts for a real business the same way you move one personal inbox. That’s where migrations go bad. Mail keeps arriving, users keep replying, aliases keep routing, and one missed DNS record can split delivery between two systems. If you’re planning a move, start with the right model: inventory first, pre-stage second, cut over last. If you want the broader operating context, read this guide to business email before you touch DNS.

The pain is predictable. Someone exports PSTs. Someone drags folders in Outlook. Someone assumes all addresses are “just mailboxes.” Then Monday hits and sales@ stops receiving, a giant mailbox is still syncing, and your team has no idea which server owns the truth. The fix is also predictable: treat email migration like live infrastructure, not file copy.

This guide shows how to transfer email accounts safely using an operator workflow. It covers the manual path with IMAP, the cutover sequence, the failure modes that matter, and the faster path inside TrekMail for teams, agencies, and MSPs that don’t want to babysit scripts.

What does it mean to transfer email accounts?

To transfer email accounts, you copy mailbox contents from one IMAP server to another, recreate routing objects like aliases and forwarding, then switch mail flow at DNS so new mail lands on the destination without losing messages.

That definition matters because most bad plans ignore half the work. IMAP moves mail folders and message state. It does not move everything around the mailbox. Per RFC 3501, IMAP is a protocol for message access and mailbox manipulation. It is not a full business identity export format.

So when you transfer email accounts, you’re really doing three jobs:

1. Copying messages and folder structure.
2. Rebuilding routing objects such as aliases, distribution lists, and forwarders.
3. Changing DNS so new inbound mail hits the new system at the right time.

If you skip any one of those, you haven’t finished the migration. You’ve just started a support incident.

What IMAP migrations move and what they don’t

IMAP migrations move email messages, folders, and usually read or unread state. They do not move calendars, contacts, tasks, desktop signatures, or most client-side rules, so you need a separate plan for those items before users expect them to appear.

This is where you need to be blunt with stakeholders. If the project is IMAP-only, say so in writing. TrekMail’s migration workflow is IMAP-based, and TrekMail is standards-first email hosting, not a groupware suite. That’s why the migration docs focus on source host, port, username, password, and destination mailbox, not calendars or shared scheduling.

Use this rule of thumb when you transfer email accounts:

That last line is the one people miss. If you need a refresher on the difference between an alias and a real inbox, read this alias vs mailbox guide. It saves a lot of cleanup later.

Inventory before you transfer email accounts

The safest way to transfer email accounts is to build a complete inventory before any sync starts. That means every mailbox, alias, group, forwarding rule, quota issue, and oversized mailbox gets mapped to a destination object and a migration wave.

A user export is not enough. You need the dark data too.

At minimum, audit these objects:

1. Primary mailboxes: Every active user inbox, shared mailbox, and role mailbox.
2. Aliases: Alternate addresses that deliver into another mailbox.
3. Distribution lists or groups: Routing objects that don’t exist as normal IMAP inboxes.
4. Forwarders: Server-side rules like info@ to owner@.
5. Catch-all behavior: Decide whether to preserve it, tighten it, or kill it.
6. Large mailboxes: Anything oversized needs an early start.

Large mailboxes change the whole timeline. Providers may throttle IMAP heavily, and giant inboxes can take days, not hours. Don’t promise a weekend move for a mailbox that has years of attachments and no archive policy.

Example: You schedule a Friday cutover for 60 users. One executive mailbox is 48 GB. By Sunday, 59 users are done and the executive is still syncing. That isn’t bad luck. That’s bad planning.

If you’re also standardizing account creation during the move, pair the migration with a provisioning checklist like this bulk create email accounts runbook. Migration chaos usually starts in provisioning, not in DNS.

The right wave plan for transferring multiple mailboxes

When you transfer email accounts in batches, use waves instead of one big bang. A pilot wave proves credentials, folder mapping, and source connectivity. A pre-stage wave copies old mail in the background. The final wave captures recent changes and lines up with DNS cutover.

This is the practical sequence:

Wave 1: Pilot

Move a small sample first. Pick IT staff, test accounts, and one normal user with a realistic mailbox. Confirm SSL on port 993, confirm credentials, and inspect how Sent, Drafts, Archive, and custom folders map on the destination.

Wave 2: Pre-stage

Start the bulk sync before cutover weekend. The goal is to move the cold data early so you’re not waiting on years of mail while the MX switch is already live.

Wave 3: Delta cutover

Run a final pass for recent mail and anything that changed since pre-stage. Then switch MX and verify new inbound mail lands only on the new system.

That’s how you transfer email accounts without gambling on provider throttling, weekend labor, and user panic.

The manual way to transfer email accounts with imapsync

If you need direct control, the standard manual way to transfer email accounts is an IMAP-to-IMAP sync tool such as imapsync. It is well known because it handles retries, folder mapping, and message flags better than ad hoc client exports.

The old way is Outlook drag-and-drop, PST exports, and one-off commands typed from memory. That produces inconsistent results and weak auditability.

The new way is repeatable batch execution with logs per mailbox and a defined delta pass. TrekMail’s own migration flow is built around that same operator logic, just without making you maintain the plumbing yourself. If you want a deeper imapsync playbook, TrekMail already published an operator guide to imapsync.

Here’s the basic batch pattern for teams that still want to run it manually:

#!$0

# users.csv format:
# source_user,source_pass,dest_user,dest_pass

while IFS=, read -r src_user src_pass dest_user dest_pass
do
  echo "[START] $src_user -> $dest_user"

  imapsync \
    --host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
    --host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
    --automap \
    --usecache \
    --fast \
    --skipsize \
    --subfolder2 "Imported_Mail" \
    --log "logs/${src_user}.log"

  echo "[DONE] Review logs/${src_user}.log"
done < users.csv

A few practical notes:

Use cache. You don’t want the tool re-reading the same mailbox metadata on every pass.

Use a staging folder when risk is high. If you suspect split-brain delivery or user activity on both sides, isolating imported mail makes verification easier.

Keep per-mailbox logs. When you transfer email accounts at scale, the question is never “did migration work?” It’s “which exact mailbox failed, where, and why?”

DNS cutover is where most email migrations actually fail

To transfer email accounts cleanly, you need a controlled DNS cutover. Lower MX TTL ahead of time, remove old MX records, publish the destination records, and verify that inbound mail reaches only the new platform before you call the project done.

Email doesn’t switch because you finished a sync. It switches because DNS told the world where to deliver the next message.

If you mess up this part, users will receive some mail on the old host and some on the new host. That’s split-brain routing. It’s one of the worst failure modes because both systems look half alive.

Use a short TTL before the move, then verify the required records. TrekMail’s domain setup docs cover the required DNS records and warn against keeping legacy MX records in place. A minimal example looks like this:

@                 MX   10 mail.trekmail.net.
@                 TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey   TXT  "<unique TrekMail DKIM value>"
_dmarc            TXT  "v=DMARC1; p=quarantine;"

During cutover, check these in order:

1. Old MX records removed.
2. New MX record published.
3. SPF merged correctly if other senders still exist.
4. DKIM present.
5. DMARC present.
6. Test message arrives only on the destination.

Once cutover is done, watch deliverability with tools like Google Postmaster Tools if Gmail traffic matters to you. Migration doesn’t end when the last message copies. It ends when new mail lands and gets accepted normally.

The TrekMail way to transfer email accounts

TrekMail lets you transfer email accounts from another IMAP server using a built-in server-side migration tool, so you don’t have to run your own VM, maintain scripts, or supervise retries by hand.

This is the old way vs new way split in plain terms.

The current TrekMail setup is straightforward:

1. Add the domain and publish the required DNS records.
2. Create the destination mailbox.
3. Open Migration in the dashboard.
4. Enter the source IMAP host, port, username, and password.
5. Select the TrekMail mailbox as destination.
6. Run the import and monitor status.

You can confirm the workflow in TrekMail’s docs for migration, mailbox creation, and DNS setup: IMAP migration overview, starting a migration in the dashboard, creating a mailbox, and required DNS records.

Pricing is the other part that changes the math. TrekMail starts at $3.50 per month on Starter. There’s a Nano plan at $0, and paid plans include Starter, Pro, Agency, and Enterprise. The Nano plan is always free and doesn’t need a card. The paid trial is 14 days and does require a credit card. For teams that transfer email accounts often, pooled storage is the important bit. One oversized mailbox doesn’t force you into weird per-user quota gymnastics.

If you’re comparing plans, use TrekMail pricing directly.

A practical cutover checklist for live teams

The safest way to transfer email accounts is to run a short final checklist just before MX cutover. It catches the errors that cause silent mail loss: missing aliases, stale DNS, wrong passwords, and unfinished large mailbox syncs.

Use this before you switch anything:

1. All destination mailboxes exist and can log in.
2. Aliases, forwarders, and groups are recreated.
3. Source IMAP access works on SSL port 993.
4. Largest mailboxes were pre-staged early.
5. DNS TTL was lowered in advance.
6. Old MX values are documented so you can verify removal.
7. Final delta sync is scheduled.
8. Users know when to stop editing server-side rules on the old host.
9. One test mailbox is ready for inbound and outbound validation.
10. Post-cutover monitoring owner is assigned.

None of this is glamorous. That’s the point. You transfer email accounts safely by removing surprises before they happen.

Conclusion: transfer email accounts with process, not hope

If you need to transfer email accounts for one domain or fifty, the rule is the same: inventory the identities, pre-stage the data, cut over DNS carefully, and verify delivery after the switch. IMAP can do the mailbox copy. It cannot rescue a bad migration design.

The manual route still works if you want tight control and don’t mind running the tooling yourself. But if you transfer email accounts regularly, TrekMail is the practical option: flat-rate multi-domain pricing, pooled storage, built-in IMAP migration, and a dashboard built for operational work instead of per-seat upsells. Start with the Nano plan or check pricing if you need migration on a paid plan.