A trust boundary, not a permissions toggle.
Run both sides yourself when you control both tenants. When you do not — carve-outs, tenant separations, MSP work with sensitive end-customers — the same product puts a real boundary between the two organisations rather than asking either to hand over credentials.
What is isolated
§01 — the guaranteesIn the two-organisation model, each side registers and holds its own credentials. Neither ever sees the other’s client secret or tenant ID — only a display name.
Every operation runs through Microsoft Graph REST or the Gmail REST API with narrowly scoped application permissions — no legacy EWS, no basic auth, no standing impersonation beyond what is required.
Invite an end-customer’s IT contact to view or manage just their own batch — never another client’s data, credentials, or billing.
How the boundary works
§02 — one model, or twoIf you control both tenants, connect them both yourself and run the migration start to finish — there is no counterparty and nothing to invite. The two-organisation model below is for when you do not: carve-outs, tenant separations, and MSP work where neither side will hand over credentials.
The inviting org sends an email invite — not an access request. The invited admin signs in, registers their own app registration or Gmail OAuth, and attaches it on their side. It is never transmitted to the other party.
Mailboxes are matched source-to-destination and reviewed independently. Both organisations must explicitly approve the scope — any change to a connection or a match resets both approvals — before a single item moves.
Built on current APIs
§03 — the surface we callFolder enumeration, message export and import, calendar, delta sync and deletion all go through Microsoft Graph REST or the Gmail REST API. Most competitors still lean on EWS, which Microsoft has been deprecating and which requires broader, more static credentials than a scoped Graph app registration.
Nothing in the source is created, changed or deleted. Every pass reads from the source and writes to the destination — a delta pass included, which mirrors source deletions forward rather than acting on them in place.
For a Microsoft 365 source the permissions requested are read and export only — Mail.Read, Calendars.Read, MailboxItem.Export.All and User.Read.All. Google is less granular: its Calendar and Drive scopes have no read-only form, so a Google source grant is wider than what we use. We would rather say that plainly than claim a guarantee the permissions do not make for us.
Questions about the boundary?
Send a note and we will answer with specifics — scopes, grants, and what each side can see.