Talk to us Sign in Start free

Your tenants stay yours.

MigrateX never holds a tenant password, never stores your data and can be revoked in a click in either tenant. Here is exactly how access works, what is kept and what is not.

Start free Ask a security question
Global Administratorapproves the MigrateX app once
consented
MigrateXstreams through memory, stores nothing
no storage
Workspace super admindelegates the service account once
delegated

Application permissions, granted once, revocable always.

Microsoft 365

Admin consent to a multi-tenant app

  • A Global Administrator signs in at Microsoft and approves the MigrateX application. That is the whole connection.
  • Application permissions only — Mail.ReadWrite, Files.ReadWrite.All, Sites.FullControl.All, Group.ReadWrite.All and the like — scoped to what your project's scope needs, and checked on every re-verify.
  • Authentication uses a certificate credential (signed JWT assertion), never a client secret in a browser.
  • The consenting account needs no license and its password is never seen by MigrateX.
  • Revoke at any time: Entra ID → Enterprise applications → MigrateX → delete. Access ends immediately.
  • Exchange-only operations (shared mailbox rights, aliases, distribution lists) run through Exchange Online PowerShell with the Exchange Administrator role, again app-only.

Google Workspace

Domain-wide delegation to a service account

  • A super administrator adds the MigrateX client ID under Admin console → Security → API controls → Domain-wide delegation, with the listed scopes.
  • Migrations run as each user through short-lived tokens minted per call; the admin address is used only for directory and admin calls.
  • Scopes are verified one by one and shown on the project page; missing ones are named.
  • Nothing is installed in the Workspace; no user ever signs in to MigrateX.
  • Revoke at any time by removing the client ID from domain-wide delegation.

Exchange Server (on-premises)

One service account over Exchange Web Services

  • You create a service account and give it the ApplicationImpersonation role; MigrateX reads every mailbox as that account. No user password is ever needed.
  • The password is encrypted at rest with a key that stays on the MigrateX server, decrypted only for the EWS call, never logged or shown again.
  • HTTPS only, Basic or NTLM, and only to a public hostname; certificate checks stay on unless you turn them off for that one connection (recorded in the activity log).
  • Nothing is installed on the server and nothing on it is changed, except a forwarding rule you ask for at cutover.
  • Revoke at any time by disabling the service account or removing the role assignment.

Zoho Mail

App-specific passwords, one per mailbox

  • Each user generates an app-specific password in Zoho (two-factor required by Zoho); you upload them as a CSV. Nothing is installed and no Zoho API client exists.
  • Stored encrypted per mailbox, decrypted only for the IMAP, CardDAV or CalDAV call that needs them, never logged, never shown again — not even in error messages.
  • TLS only, and every request stays on the host you configured: a redirect or link to any other host is refused, so a password can never be sent elsewhere.
  • App passwords can read and write mail, contacts and calendars — nothing else. Groups, forwarding and the domain are changed by you in the Zoho admin console.
  • Revoke at any time by deleting the app password in Zoho; the connection stops working immediately.

Through, not into.

MigrateX is a pipe with a memory of what it has already carried — not a copy of your tenant.

Streamed through memory

Mail, files and history are read from the source and written to the target in chunks. Nothing is written to disk on the way.

Server-side where possible

Google Drive to Google Drive copies inside Google (share, copy, unshare). The file never leaves Google.

What is kept

Directory metadata (names, addresses, sizes), an item map of source IDs to target IDs so nothing is copied twice, progress counters, verification counts and error notes.

What is encrypted

OAuth tokens, certificates, TOTP secrets and recovery codes — XSalsa20-Poly1305 at rest with a key that lives outside the database.

What is never kept

Message bodies, attachments, file contents, chat messages, tenant passwords.

Directory sync

To compare two directories MigrateX keeps names, addresses, titles, phone numbers, group membership and OU paths. Passwords and SID history are never read, in any direction.

The Active Directory agent

One readable PowerShell script that only calls out over HTTPS. Its token is stored as a fingerprint, it knows a fixed list of actions, and it never deletes.

When it is deleted

Delete a project and its connections, cursors, item maps and notes go with it. Nothing in either tenant is touched.

Hardened by default.

  • Two-step sign-in (TOTP, RFC 6238) with replay protection and single-use recovery codes for every account; a separate, unlisted back-office door for MigrateX staff.
  • Argon2id password hashing, per-account lockouts on top of per-IP throttling, timing-safe checks.
  • Strict browser headers: nonce-based Content-Security-Policy with no inline scripts or styles, HSTS with preload, COOP/CORP, frame denial, referrer policy.
  • Sessions in __Host- cookies, regenerated on sign-in; CSRF tokens on every form.
  • Tenant isolation: every record is scoped to your organization; roles owner › operator › viewer; the back office answers 404 to everyone else.
  • Append-only audit log of who did what, when, from which address and device.
  • No third-party code: a custom PHP framework with no package dependencies to inherit vulnerabilities from.

Questions we are happy to answer

  • Where MigrateX runs and where data transits (it can be hosted in your own region or on your own servers).
  • Which Graph permissions and Google scopes each workload needs, and why.
  • How to scope a project so only the permissions you need are requested.
  • How to pilot with a handful of users before granting anything to production.
Ask us

Connect a tenant and watch what it asks for.

The permission list is on the project page before you consent. Scope down, pilot, then widen — on your schedule.

Start free Talk to us