An MSP, an administrator, or the one person who knew how everything worked is leaving, and nobody can prove the business still controls its own tenant.
Take back control of the tenant when the provider or the administrator leaves.
Microsoft 365 Tenant Takeover & Vendor Handover
Tenant and domain ownership is verified, privileged and emergency access is brought under the business’s control, partner and delegated access is reviewed, credentials are rotated where authorized, and the vendor and dependency map is handed to the new owner.
Price
Fixed price confirmed before work begins
Delivery window
The fixed proposal contains the delivery calendar and the completion date.
The price is agreed in writing before any work begins and before any access is granted. Nothing is billed for the scoping conversation that sets it. What moves the number:
- · Number of tenants and domains
- · Number of privileged accounts, service accounts and shared credentials in scope
- · Number of vendors and third-party integrations to map
- · Whether the outgoing party is cooperating
- · Whether Azure subscriptions and on-premises systems are included
No tenant access, credentials, or sensitive files are requested through this website.
What happened
A relationship is ending. The risk is rarely malice — it is that ownership was never written down. The domain sits at a registrar somebody else set up, the partner relationship still grants standing administrative access, the break-glass account is a shared password in a former employee’s manager, and three vendors bill for things nobody can name. Documentation alone does not fix any of that: what is needed is the transfer itself, verified.
An MSP, or the one administrator who knew how the environment was put together, is leaving, and the pieces that prove ownership sit outside the business: the domain is in a registrar account somebody else opened, the partner relationship still grants standing administrative access into the tenant, and the break-glass credential is a shared password held in a departing person's password manager. Multi-factor prompts for the privileged accounts arrive on a phone or an authenticator app belonging to the person walking out, domain and subscription renewals are charged to a card the business does not hold, and the DNS records carrying mail are edited from a console nobody inside the business has signed into.
What happens if it is left as it is
- Anything not verified while the outgoing relationship is still running has to be asked for once it has ended, when there is no open engagement to raise it under and the response sits on someone else's timetable.
- A domain sitting in a registrar account the business does not hold controls where mail is delivered and where sign-in points, and both stay changeable by whoever does hold that account.
- A partner or delegated administrative relationship left in place keeps granting access into the tenant after the invoices stop, and because it authenticates from the partner's own tenant using the partner's own accounts, password changes made inside the business do not reach it.
- Credentials rotated before the dependency map exists can take down whatever was quietly using them — service accounts, mail connectors, line-of-business integrations — at the point when the person who could explain those connections has already gone.
- Until administrative access sits in accounts the business itself holds, ordinary changes such as adding a user, releasing a quarantined message or reissuing a password have to be routed back through whoever still holds the credentials, and each one moves at whatever pace that arrangement allows.
What changes in production
Not findings. These are the things that are different afterwards.
- 1Tenant and domain ownership is verified against the registrar and the tenant, and moved where it is not already with the business.
- 2Global Administrator holders are reconciled to a named, approved list, and emergency access accounts are created or rebuilt under the business’s own control.
- 3Partner and delegated administrative relationships are reviewed, and the ones that should not survive the handover are removed.
- 4Privileged credentials, service accounts and API keys in scope are rotated where authorized, in a sequence that does not break the things depending on them.
- 5Registrar, DNS, CSP, backup, security and application vendors are mapped, with what each one holds and who now owns the relationship.
- 6Whatever is left unresolved is assigned by name rather than left in a document as a finding.
Definition of done
The engagement ends when all of these are true and demonstrable.
- Tenant and domain ownership is verified and held by the business
- The Global Administrator list matches the approved named list, and emergency access is under the business’s control and alerting
- Partner and delegated access is reviewed, with obsolete relationships removed
- Authorized credential rotations are complete and the dependent systems still work
- The vendor, registrar, DNS, backup and application map is complete
- Every unresolved dependency has a named owner and a date
- The handover record has been walked through with the incoming owner
What you provide
Named up front, because these are the things that stall an engagement when nobody owns them.
- Authorize each credential rotation in writing before it happens
- Provide the approved list of who should hold administrative access afterwards
- Name the incoming owner who will take the handover walkthrough
- Own the commercial conversation with the outgoing vendor
What moves the price
The figure comes from what is actually in the environment. Headcount is one input among several, and rarely the one that matters most.
- Number of tenants and domains
- Number of privileged accounts, service accounts and shared credentials in scope
- Number of vendors and third-party integrations to map
- Whether the outgoing party is cooperating
- Whether Azure subscriptions and on-premises systems are included
Not included
Stated so the scope means the same thing to both parties on the last day as it did on the first.
- Legal or contractual dispute with the outgoing provider
- Recovery of access the outgoing party refuses to release, which becomes its own scoped work
- Ongoing administration after handover
- Help desk and end-user support
- Rebuilding systems found to be misconfigured — that is separately scoped remediation
How change is staged and reversed
Production work carries risk. This is the method, not a reassurance.
- Rotation runs after the dependency map, never before it: a credential is changed only once what depends on it is known and has an owner standing by.
- Access is removed in a staged order with the business’s own access proven working first, so no step can leave the tenant unadministered.
Evidence and handover
Yours to keep whatever happens next, including handing it to your own team or another provider. The documents are what prove the work happened; they are not the thing being bought.
- The ownership record: tenant, domains, registrar, and who holds each
- The before-and-after privileged access list
- The partner and delegated access review, with the removals made
- The rotation log, and what depended on each credential
- The vendor and dependency map
- The handover record, signed off by the incoming owner
Is this another report, with the real work quoted afterwards?
It may sound like a consultant will inspect the environment, hand over a document, and then quote a second project. That is not the default here. Where the outcome can be scoped safely from a short working call, the implementation is sold directly, as this page does. Separate paid planning is used only where genuine complexity prevents a responsible fixed price, and where it is used the page says so plainly.
Plan the Tenant Handover
Describe what is happening, what has to be working differently, and any deadline behind it. A reply comes within one business day with the most direct next step, or a clear answer that AZ Innovations is not the right fit.
Plan the Tenant Handover →