IMAP Migration Initial Setup and Connection Checklist
Use this checklist before starting an EdbMails IMAP migration, IMAP-to-PST export, or provider-specific mailbox move. The exact preparation depends on the source and target. Standard IMAP is email-focused, so contacts, calendars, tasks, and rules require a separate provider-specific or application-specific workflow.
For the product overview, supported destinations, commercial features, trial, and licensing, use the EdbMails IMAP Migration Tool. This page remains a setup checklist rather than a competing product page.
1. Prepare the source IMAP account
- Confirm that the mailbox is available through IMAP and collect the correct host name, port, TLS/SSL requirement, email address, and provider-supported authentication method.
- For multiple users, prepare the mailbox list with the EdbMails CSV workflow and validate a small test set before loading the full production list.
- Check provider limits on simultaneous IMAP connections, per-user sessions, message size, and throttling because these can affect migration throughput.
- For Gmail or Google Workspace, do not use the retired “Less Secure Apps” method. Google Workspace stopped supporting username/password-only less-secure-app access in 2025. Use the authentication method supported by the account and current EdbMails workflow; app passwords are only available in specific 2-Step Verification configurations and may be restricted by administrators.
See IMAP connection and login guidance.
2. Prepare the target for the selected scenario
IMAP to Microsoft 365
- Create or provision the required target mailboxes and assign the appropriate Microsoft 365 licenses.
- Use the current EdbMails modern-authentication / Microsoft sign-in workflow. Do not disable Security Defaults merely to make a migration work. If an organization uses Conditional Access instead of Security Defaults, configure that security policy intentionally with the Microsoft 365 administrator.
- Exchange Online retired the legacy ApplicationImpersonation RBAC role in 2025, so do not use old Office 365 impersonation setup instructions for a current Microsoft 365 migration.
- Verify target permissions, mailbox mapping, throttling, and message-size limits, then run a pilot migration.
See IMAP to Office 365 migration.
IMAP to Exchange Server
- Confirm the Exchange target version and Microsoft support status before migration.
- Exchange Server 2016 and 2019 are out of normal support; Exchange Server Subscription Edition (SE) is Microsoft's current on-premises release.
- Prepare target mailboxes, mail flow, certificates, accepted domains, and the Exchange permissions required by the selected EdbMails connection method.
- For on-premises Exchange workflows, configure ApplicationImpersonation only where the selected EdbMails/EWS connection method requires it.
See IMAP to Exchange migration.
IMAP to IMAP
- Create and validate destination mailboxes on the target IMAP service.
- Collect the target host name, port, TLS/SSL requirement, and authentication method.
- Check target connection limits and storage quotas before increasing concurrency.
IMAP to PST
- Use a Windows computer that meets the current EdbMails PST requirements.
- Install the Outlook components required by the current EdbMails build and prepare the required Outlook profile.
- Provide sufficient local storage for the PST output and working space.
- Use PST splitting where appropriate for large exports.
See IMAP to PST export and backup.
3. Run a pilot before the production migration
- Test one or more representative mailboxes.
- Verify mailbox and folder mapping.
- Check representative messages, attachments, dates, read/unread state, and folder hierarchy.
- Review migration reports for warnings, skipped items, or authentication errors.
- Only after validation should you increase the batch size or concurrency.
4. Plan the final cutover
Incremental follow-up passes can be used for supported scenarios before final cutover. Migration is not continuous two-way synchronization. Any required MX, DNS, Autodiscover, Outlook-profile, or user sign-in changes should be scheduled only after the target has been validated.
