A sale, a purchase or a company split means one Microsoft 365 tenant has to move into another. The date is usually agreed before IT is asked.
Bring two Microsoft 365 tenants together on the date the deal says.
Tenant to Tenant Migration
The agreed users, mail and files land in the receiving tenant. Sign-in and mail work on the new path, and every user is checked across both sides.
No access to your tenant (your Microsoft 365 environment), no credentials, and no sensitive files are requested through this website.
What is going wrong
Two tenants have to become one, and nobody has listed the parts that clash. The same domain cannot live in both. The same person has an account on each side. The two businesses wrote different security rules. Nobody has decided whether the two sides need to see each other’s calendars and message each other while the move runs. And no one has written down what would stop it, or who makes that call.
Signs you can check yourself
- A deal has a date on it and IT was told about it late
- The same person has an account on both sides
- One domain name is needed by both businesses
- People on the two sides cannot see each other’s calendars or message each other
What waiting affects
- A domain can only be attached to one tenant at a time, so the moment it moves, sign-in and mail for everyone using it moves with it, whether or not the rest of the work is ready.
- Where the two sides cannot see each other’s calendars or message each other during the move, the business runs as two companies for that period, and the people affected are usually the ones closing the deal.
- Security rules that do not come across leave accounts on the receiving side protected differently from the way they were the day before, and nobody notices until something uses the gap.
- A deal date is fixed by people who are not in IT, and a move that has to be rebuilt from scratch when a clash is found is only as complete as the days left before that date.
What AZ changes
Not findings. These are the things that are different afterwards.
- 1Everything in scope is counted on both sides before anything moves, and every user gets a named destination.
- 2The clashes are found first: shared domains, duplicate accounts, and security rules that differ between the two tenants.
- 3How much the two sides can see of each other during the move is decided and set up in advance, rather than discovered on the first morning.
- 4The move runs in dated groups, and each group is checked before the next one starts.
- 5The receiving tenant is checked against the source user by user, and every gap is closed or given an owner.
How you know the job is finished
The engagement ends when all of these are true and demonstrable.
- Every user on the agreed list can sign in on the receiving tenant
- Mail and files for those users have arrived and are tested
- Every user is counted across both tenants, and anything deliberately left behind is written down with an owner and a date
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.
- How many users are moving
- Which parts of Microsoft 365 are in scope: mail, files, Teams, devices
- Whether the two tenants have to work side by side during the move, and for how long
- Whether devices have to be re-enrolled on the receiving side
- How many domains move, and whether any are shared between the two businesses
You may not need this engagement
- The two businesses are staying on separate tenants
- Only mail is moving, and it is coming from a host rather than another tenant
- Nobody has agreed which side is receiving, which has to be settled first
Both sides are Microsoft 365. Should this not be straightforward?
Same platform, but the parts that clash are the same parts either way. A domain can only live in one tenant, so the moment it moves, sign-in and mail move with it. The same person may exist on both sides. And the two businesses almost never wrote their security rules to agree with each other. Those are the three things that decide the schedule.
The full scope
Everything this engagement commits to, in detail. None of it is a surprise on the last day.
What is not included
Stated so the scope means the same thing to both sides on the last day as it did on the first.
- Licenses needed to run the move, on either side
- Application rebuilds or integrations on the receiving side
- HR, payroll or finance system moves
- Help desk and staff support
What you provide
Named up front, because these are the things that stall an engagement when nobody owns them.
- Confirm the list of users, domains and data that moves
- Approve the switch window and the period the two sides run side by side
- Give administrator access to both tenants
- Tell staff on both sides what is happening and support them through it
How changes are made, and how they are undone
Work on live systems carries risk. This is the method, not a reassurance.
- Users move in dated groups, and a group is not started until the one before it checks out.
- The conditions that stop the move are agreed before the first user moves, and they name conditions rather than intentions.
- The domain move is scheduled as its own step, with its timers shortened in advance, because it takes sign-in and mail for everyone on it at the same moment.
What you get at the end
Yours to keep whatever happens next, including handing it to your own team or another provider.
- The counted list of users, mail and files that moved
- The list of clashes found and how each was settled
- The dated schedule, as it actually ran
- The agreed conditions for stopping
- The check sheet proving source and destination match
Plan the Tenant Move
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 Move →