Trust Center
How MigrationFox handles your data
The short, plain version of where your files go, what we keep, what we ask Microsoft for, and what we have and haven’t been certified for. The detail lives in our security overview, DPA and subprocessor list.
Where your files go
Every migration follows the same steps — connect, scan, move, verify. What changes is where the file bytes travel.
In the MigrationFox cloud
- · File contents stream through our migration worker in Toronto, Canada (Oracle Cloud, Canada Southeast region), from your source straight to your destination.
- · We don’t retain file contents after a migration completes.
- · We keep operational metadata — file paths, sizes, success or failure status, and the audit log — plus your encrypted credentials. That metadata is processed on infrastructure in the United States (Railway, us-west-2), and MigrationFox Inc. remains accountable for it under PIPEDA.
On the MigrationFox Windows app
- · The app runs on a Windows machine you control. It reads from your source and writes to your destination directly from that machine, so file contents don’t pass through MigrationFox servers.
- · The MigrationFox cloud receives job metadata — progress, file paths, sizes and status — so you can track the job in the dashboard.
- · It talks to MigrationFox over outbound HTTPS only. No inbound ports, no VPN.
MigrationFox Inc. is a Canadian federal corporation and follows PIPEDA, Canada’s federal privacy law. See deployment options for help choosing between the two.
Encryption and sign-in
Credentials and data in transit
- · OAuth tokens, service-account keys and agent secrets are encrypted at rest with AES-256, using a server-side key that is never stored alongside the encrypted data.
- · The credential format supports versioned keys, so encryption keys can be rotated without losing access to existing connections or asking you to reconnect.
- · TLS is enforced on every API request and file transfer.
Your MigrationFox account
- · Passwords are hashed with Argon2id; older accounts upgrade automatically on next sign-in.
- · Multi-factor authentication (TOTP, with recovery codes) is available on every account.
- · Sessions are scoped to a single tenant and role — no cross-tenant token reuse.
- · Sign-ins, credential changes, jobs, governance scans and admin actions are written to a tenant-scoped activity log.
Microsoft permissions, per app
We use three separate Microsoft Entra apps so each consent screen asks only for what that product needs. You connect only the apps for the products you use.
MigrationFox (file, site and Teams migration)
Delegated Microsoft Graph permissions:
Files.ReadWrite.All Sites.Manage.All Sites.ReadWrite.All Group.ReadWrite.All User.Read User.Read.All offline_access
Write access is needed because a migration creates sites, libraries and files in your destination. User.Read.All maps people between tenants so authors and permissions land on the right accounts. Optional, admin-consented extras are used only by the features that need them: SharePoint AllSites.FullControl for True History mode, and TermStore.ReadWrite.All for provisioning managed metadata term sets.
MigrationFox Mail (mailbox migration)
Mail-only permissions, kept in their own app so file consent never includes mail:
Mail.Read Mail.ReadWrite User.Read offline_accessMail.ReadWrite User.Read.AllMigrationFox Assessment (governance report packs)
Read-only Microsoft Graph permissions. The assessment client blocks every PATCH, POST, PUT and DELETE call at runtime, so a report pack cannot change your tenant.
Sites.Read.All Files.Read.All User.Read.All Group.Read.All Directory.Read.All AuditLog.Read.All InformationProtectionPolicy.Read.All Policy.Read.All Reports.Read.All SecurityEvents.Read.All TeamSettings.Read.All SharePointTenantSettings.Read.All DelegatedPermissionGrant.Read.All Application.Read.All RecordsManagement.Read.All
What each permission is used for, signal by signal: What we check.
Verified publisher and signed installer
Microsoft Verified Publisher
When you connect a Microsoft 365 tenant, the consent screen shows “MigrationFox Inc” with Microsoft’s blue verified-publisher checkmark. If you ever see a MigrationFox consent screen without it, don’t approve it — email security@migrationfox.com.
Code-signed Windows app
The Windows installer and the app inside it are signed with Azure Trusted Signing, so Windows SmartScreen identifies the publisher instead of warning about an unknown one.
Download for Windows →Subprocessors and DPA
The vendors that help us run the service. Each is contractually bound to handle data only on our instructions. We email customers at least 30 days before adding or replacing one.
| Subprocessor | Purpose | Region |
|---|---|---|
| Oracle Cloud Infrastructure | Migration worker (file content streaming, not retained) | Canada Southeast (Toronto) |
| Railway | API hosting, Postgres database, Redis queue | United States (us-west-2) |
| Vercel | Website, web app and docs hosting | Global edge network |
| Stripe | Payment processing | United States |
| Resend | Transactional email | United States |
| Sentry | Error tracking | United States |
| Microsoft Azure | Trusted Signing for the Windows installer | Canada Central |
The maintained list, with data categories: Subprocessors. Our standard Data Processing Agreement covers GDPR Article 28, UK GDPR and PIPEDA; email legal@migrationfox.com to sign one.
Compliance status and disclosure
Certifications
We do not currently hold SOC 2 or ISO 27001 certification. If we obtain independent audit reports, our DPA commits us to making them available to customers. Until then, we answer security questionnaires and your auditors can review this page, the DPA and our security overview.
Reporting a vulnerability
Email security@migrationfox.com. We acknowledge reports within one business day and aim to validate or dismiss them within five.
Questions from your security team?
Send them to security@migrationfox.com — or start with 2 GB free and see it for yourself.