Tenant isolation
Migrate tenant data without weakening the shared boundary
Moving one tenant between stores changes routing, ownership and background work. Keep an authoritative location and explicit cutover rules throughout the transition.
In this article
Inventory all tenant-owned data
Include primary rows, files, search indexes, caches, queued jobs and derived reports. A database copy alone may leave the application reading or writing other artifacts in the old location.
Record cross-tenant or shared reference data separately. Decide which records move, which remain shared and how identifiers continue to resolve.
Define the source of truth during migration. Two writable locations without a conflict rule can produce divergence even if the initial copy is correct.
Build and verify the destination
Create the destination with the intended schema, roles and isolation controls. Test it using the runtime identity that will serve the tenant, not only an administrator performing the copy.
Copy data through a scoped process and reconcile counts, identifiers and important business relationships. Use sampled content checks or checksums appropriate to the data, while avoiding unnecessary exposure in migration logs.
Account for changes made during the copy. Use a controlled write pause, change capture or another explicit catch-up method supported by the system.
Switch routing and work ownership
Update the tenant-location registry or equivalent authoritative routing mechanism at a defined point. Ensure web requests and workers use the same decision.
Handle queued jobs created before cutover. They may carry old location hints or credentials, so re-resolve trusted routing where the design requires it rather than blindly executing against the previous store.
Invalidate or partition caches and search data that could return old results. Verify downloads and exports as well as ordinary API reads.
Rehearse rollback with new writes
A rollback must account for changes accepted at the destination after cutover. Restoring the old route to a stale copy can lose work or expose inconsistent records.
Define which location becomes authoritative and how data catches up during restoration. Test the process with a synthetic post-cutover mutation and an in-flight job.
Retire old tenant copies through the documented retention and removal process once the observation window closes. The migration is complete when every serving path resolves the same tenant boundary and historical copies have a known, controlled fate.
Primary sources
Microsoft Learn: multitenant storage approachesOWASP: multitenant securityReferences checked 11 September 2026.