Discuss your project

Microsoft 365 tenant takeover and vendor handover

Hold the keys to your own accounts, domain and billing, whoever leaves.

Ownership of the tenant and the domain is verified. Admin and emergency access come under your control, partner access is reviewed, and passwords are rotated where you authorize it. The map of vendors and what depends on what goes to the new owner.

What you get
Client-controlled administration and a tenant, domain and provider ownership map with recovery instructions.
How it starts
A free scope call. The price is fixed in writing before anyone is given access.
When it is done
Your owners verify the agreed access and recovery paths. Provider access and remaining transfer actions are reviewed and assigned.
Price the tenant handoverReview scope & terms

Illustrative sample · constructed example

Tenant access is only one of the keys.

Ownership map · domain to tenant

Selected check

Who can approve and make the required DNS change?

Ownership / authority mapIllustrative
CONTROL BOUNDARYExisting Microsoft 365 tenantConfirm whether control changes here or a separately scoped tenant move is needed.
ADMINISTRATIONClient administratorAuthorized access + recovery check
DOMAIN / DNSRegistrar account ownerAuthority must be established before DNS-dependent work
LICENSE / BILLINGClient + providerAgree replacement licenses and release sequence
APPROVALClient change ownerApprove scope, timing and remaining conditions

A provider release changes control. It is not a mailbox-data transfer.

Ownership / authority map: constructed inspection record
RecordEvidence or responsibilitySample review
RegistrarIdentify the authorized account and recovery contact.Owner missing
DNSName who approves and performs a domain change.No verified change owner
TenantVerify administrator access and protected recovery access.Tenant administrator exists
Provider and billingConfirm release conditions and the next contract owner.Separate scope question

Tenant administration does not confer registrar authority or authorize a DNS change.

Evidence
A tenant administrator exists; the registrar account owner is missing.
Decision
Hold DNS-dependent work
Next action
The client establishes registrar authority and a recovery contact.

Illustrative sample. Verifying ownership does not authorize a domain change or include a new tenant migration.

The related record on the Results page is kept separate from this sample, with its own limits stated beside it.

Inspect the related record

Why now

The work starts here.

Your IT provider, your administrator, or the one person who knew how it all worked is leaving. Nobody can prove the business still controls its own Microsoft 365.

Scope at a glance

  • You get the handover, not a binder
  • Passwords changed only with your written go-ahead
  • Handover reviewed with the new owner

If nobody acts

What waiting costs

  1. Anything not verified while the relationship is still running has to be asked for after it ends. There is no open engagement to raise it under, and the answer arrives on somebody else’s timetable.

  2. A domain in a registrar account you do not hold controls where your mail is delivered and where sign-in points. Both stay changeable by whoever does hold that account.

  3. A partner or delegated admin relationship left in place keeps granting access after the invoices stop. It signs in from the partner’s own tenant with the partner’s own accounts, so changing passwords inside your business does not reach it.

  4. Rotating passwords before the map exists can take down whatever was quietly using them: service accounts, mail connectors, business integrations. That happens at the point when the person who could explain those connections has already gone.

  5. Until admin access sits in accounts you hold, ordinary jobs go back through whoever holds the credentials. Adding a user, releasing a quarantined message, reissuing a password: each one moves at whatever pace that arrangement allows.

Check your own environment

Sounds like you?

  • The person or company who set up your Microsoft 365 is leaving, or already has
  • You cannot sign in as an administrator without asking someone outside the business
  • The domain name is registered in an account somebody else opened
  • Renewals are charged to a card the business does not hold
  • Nobody inside the business has ever edited the settings that route your mail

Save yourself the call

Not for you if

  • You already hold the admin account, the domain, and the billing, and have signed in to all three
  • The outgoing provider is cooperating and writing everything down on a schedule you agreed
  • A new provider has already taken over and shown you what they received

The work

What is different when we hand over

  1. Tenant and domain ownership is verified against the registrar and the tenant, and moved where it is not already with the business.

  2. Global Administrator access is cut back to a named, approved list, and emergency access accounts are created or rebuilt under the business’s own control.

  3. Partner and delegated administrative relationships are reviewed, and the ones that should not survive the handover are removed.

  4. Privileged credentials, service accounts and API keys in scope are rotated where authorized, in a sequence that does not break the things depending on them.

  5. Registrar, DNS, CSP, backup, security and application vendors are mapped, with what each one holds and who now owns the relationship.

  6. Whatever is left unresolved is assigned by name rather than left in a document as a finding.

Acceptance

Checks before handover

  • 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

A fair question

Our provider is leaving on good terms. Is this not overkill?

Good terms are what makes it easy, not what makes it unnecessary. The risk is rarely bad faith. It is that ownership was never written down, so the questions only the departing party can answer stop having an answer the week after they go. Doing this while everyone is still friendly is the cheap version.

Price and calendar

Scope, price and project calendar

Engagement price

Price fixed after a short scope call.

The price is agreed in writing before any work starts and before anyone is given access. The call itself costs nothing. What moves the number:

What determines the scope

  • 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

Delivery calendar

The proposal names the start date, the change windows and the completion date before anything is agreed.

How engagements work

Scope & responsibilities

What is and is not included

The exclusions, what we need from you, how change is staged and reversed, and what is handed over at the end.

Exclusions
  • 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 badly set up, which is quoted as its own job
What we need from you
  • 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
Change and rollback method
  • 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.
What you keep at handover
  • A System guide: the configuration as delivered, the checks that were run and the unresolved list
  • 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

Access, acceptance and support arrangements

How you know the work is good

Judge it by what you can inspect.

The method is written down, the sample records open and the demo can be broken on purpose. Read it the way your technical owner would.

How a project runs

A first conversation, free. An agreed scope with a named technical lead in the proposal. The price fixed in writing before we are given access. Checks before handover.

How we work
What is checked

Release checks, access test matrices and ownership maps. Constructed inspection records on the service pages show the standard before you buy.

See sample deliverables
What you keep

A System guide: what was agreed, what changed, what was tested and what remains open. With it, the scripts and check results behind the work.

Next step

Start with a free scope call.

Tell us what needs to change, what must keep working and the deadline. The call is free, and the price is fixed in writing before anyone is given access.

Price the tenant handover

Or write to [email protected]