Migration
Microsoft 365 migration, where ownership usually gets lost
Most Microsoft 365 migrations move the data and quietly leave the ownership behind. The result is a new tenant or site full of files nobody is accountable for. This guide covers the three migration shapes, what each one actually transfers, and the ownership records that need explicit handling.
A migration tool will tell you how many items it copied. It will not tell you who owns them afterwards. Ownership is a separate record from content in OneDrive and SharePoint, and it is the record that decides whether anyone can still administer, retain, or defensibly delete that data once the migration is “done”.
The three migration shapes
1. Intra-tenant moves. Mailbox moves between users, sites moved between SharePoint sites, team sites reorganised as the org chart changes. Data stays inside one tenant, so permissions mostly follow — but ownership often does not, because a move preserves the owning principal while the person behind it has left.
2. Tenant-to-tenant moves. Mergers, divestitures, and M&A. Microsoft supports this through its own migration tooling, and content arrives at the destination with rewritten permissions — but ownership is a deliberate choice that has to be made per resource, not an automatic consequence of the copy.
3. Restructuring. Consolidating a long tail of personal OneDrive sites into team sites before accounts are closed. The volume is small per site and large in aggregate, which is exactly why it gets deferred until deletion is imminent.
What usually goes wrong
- Ownership is not remapped. The file arrives and the owner is still the departing principal or a placeholder identity.
- Primary site owner is treated as the same thing as site collection admin. Changing one does not move the other, and neither one touches library or item ownership.
- Deletion is scheduled before the ownership review finishes. Once the account is gone the personal site is orphaned, and the recycle-bin window is short.
- Nobody re-checks afterwards. Migration tools report what they attempted; only a fresh read of the destination proves what is true now.
- The evidence is the tool's own log rather than a provider-verified record an auditor can rely on.
Where Votra fits
Votra does not perform the bulk data move — Microsoft's own migration tooling or a third-party mover does that, and it does it well. Votra runs the part that follows it: the ownership reconciliation that decides where every resource ends up, the approval gate before anything changes, and the post-move verification that re-reads each item in the destination so the record reflects the provider rather than the request. That is the same step ownership transfer with verification performs, applied after a migration instead of during a departure.
Planning a Microsoft 365 migration
- 1Run the migration first, on your own schedule. Votra does not gate or sequence the data move.
- 2Before any account is closed, discover what each departing principal owns in the destination — not only what was copied into it.
- 3Assign a destination owner per resource and record the decision against the migration.
- 4Approve the plan with someone other than the person who ran the migration.
- 5Transfer ownership item by item, re-reading each resource afterwards to confirm the change landed.
- 6Export signed evidence covering the reconciliation, so the migration and the ownership change are auditable as one event.
If the migration also involves an employee departure, the Microsoft 365 offboarding checklist covers the ordering, and the best-practice sequence explains why transfer has to precede deletion.
Frequently asked
- Does Votra move data between tenants?
- No. Votra is metadata-only by design — it reads and writes ownership and permission records through Microsoft 365 APIs and never downloads file contents. The bulk data move is done by Microsoft's migration tooling or a third-party mover; Votra handles the ownership reconciliation and verification that has to follow it.
- Can Votra migrate from Google Workspace to Microsoft 365?
- No. Google Workspace is not a provider Votra connects to, and the product has no cross-provider data movement. Votra's scope is Microsoft 365: what a tenant owns, who owns it, and proving that ownership changed. Getting data into Microsoft 365 from another suite is a data-move problem handled by other tools.
- Does a migration tool not already transfer ownership?
- Content and permissions are usually remapped by the migration tooling. Ownership is a distinct record and is generally left as-is, or needs an explicit decision. That is the gap Votra addresses, and it is why a migration can complete successfully and still leave files that nobody owns.
- What happens to personal OneDrive sites after a tenant-to-tenant move?
- They arrive as sites in the destination tenant, typically retaining the original principal as an unresolved or placeholder owner. Closing the source account afterwards removes the human behind that principal, which is what makes the site effectively orphaned.
What Votra is
Votra is a platform for running employee offboarding and resource-ownership transfers on Microsoft 365 — with more workspace integrations on the roadmap. Operations discover what an employee owns, move ownership and access through provider APIs without ever moving file content, enforce approval before anything changes, and export a signed audit trail of every action.