Questions engineers actually ask.

Microsoft 365 and Google Workspace in any direction, plus generic IMAP/POP sources. The most common projects are Google Workspace → Microsoft 365 and tenant-to-tenant M365 → M365 consolidations after an acquisition.

Yes — when the source speaks those items natively. For API-based sources (Microsoft 365 and Google Workspace), three things come across in one pass: mail with its full folder structure and read/flag state; calendars with recurring series, attendees, organizers, locations and reminders; and personal contacts with all their fields. Calendars and contacts are exactly the pieces cheaper mail-only tools tend to drop. Mailwynx does not migrate inbox rules, signatures, auto-replies, or shared-mailbox and delegate permissions — those stay to be set up on the destination.

Generic IMAP/POP sources are mail-only. IMAP is an email protocol — it carries messages and folders, nothing else. Calendars and contacts live in separate protocols (CalDAV/CardDAV) that IMAP can't see, so a migration from IMAP moves email only. Full calendar and contact fidelity requires an M365 or Google source. See the question below for how to bring those across manually.

Your email will — every folder and message, deduplicated and resumable like any other job. Your contacts and calendar will not, because those hosts expose them over CalDAV/CardDAV, not IMAP, and Mailwynx reads IMAP sources over IMAP. This is a protocol limit, not a Mailwynx shortcut.

To bring them across, do a one-time manual export from the host's webmail: export Contacts as a vCard (.vcf) and import it into Outlook/Microsoft 365 → People; export the Calendar as an .ics and import it into Outlook → Calendar. It takes a couple of minutes per mailbox and only has to happen once, at cutover.

Mailwynx runs as a single app on your own Windows machine. Mailbox data moves directly between the source and destination APIs through your host — it is never uploaded to, stored on, or processed by any Mailwynx-operated cloud. Credentials are encrypted at rest on your machine. That's what lets you give a straight answer to any data-residency question.

No. You pre-stage mailboxes over days while users keep working on the source. At cutover you run a final delta sync to catch anything new, then switch MX. Users move to the destination with their full history already waiting.

You buy mailbox migrations in one-time packs — $199 for 100 or $449 for 300 — with no subscription and no recurring bill. Packs top up the same key, so you can buy more whenever you run low. Re-running the same mailbox never costs a second credit, and dry-run previews are always free. See pricing for details.

Just run it again. Mailwynx is idempotent: it tracks what already migrated and skips it, so retries never create duplicates. A dropped connection or a rebooted server is a non-event — resume and it picks up where it left off.

It depends on mailbox sizes and the source API's rate limits, both of which Mailwynx throttles against automatically. Because you pre-stage ahead of cutover, the part that's time-sensitive — the final delta — is usually minutes per mailbox, not hours.

No agents, no desktop installs. Mailwynx works entirely server-to-server over the platforms' native APIs. Users don't have to do anything except sign in to the new tenant after cutover.

Yes. Every batch produces a completion report with per-mailbox item counts and any warnings, which you can export and give the client as sign-off documentation.

Yes. Sign up and your self-hosted trial license lets you run unlimited dry-run previews and migrate three mailboxes free — real, end-to-end, with no card and no time limit. When you're ready for more, buy a pack (100 or 300 mailboxes) and keep going. Prefer a guided pilot? Book a demo.