Making calendars work across two tenants while you migrate
Two companies merge. For months, half the people live in one Microsoft 365 tenant and half in the other. Someone tries to schedule a meeting across the line and every attendee shows up as a wall of hatch marks — no availability, no way to find a slot. That gap is the first thing anyone notices during coexistence, and it is fixable.
New to cloud? CAMPUX is a free, build-first course. Start here →
When two Microsoft 365 tenants have to run side by side — this is part of the Azure tenant-to-tenant migration guide — the mail cutover gets all the attention. But the quieter pain is scheduling. Each tenant is its own Exchange Online organization with its own directory and its own trust boundary, and availability lookups stay inside that boundary. So on day one of coexistence, a person in tenant A asks for the free/busy of a colleague now sitting in tenant B, and Exchange has nowhere to go. The answer comes back blank. Nobody's calendar is broken; the two organizations simply do not know each other yet.
Why calendars don't cross the line by default
A tenant boundary is a real security edge, not an accident. Availability information — whether you're free, busy, tentative, or out of office — is data your organization holds inside its own Exchange Online, and it does not leak to another organization just because both happen to be Microsoft 365. That is the correct default. The two tenants show each other as strangers, and someone with the right admin rights has to make a deliberate decision to open a path. Until that decision is made and configured, cross-tenant scheduling is guesswork, which during a months-long coexistence means double-bookings, missed standups, and a lot of "are you free Tuesday?" emails that the calendar was supposed to kill.
The organization relationship is the mechanism
Microsoft's tool for this is the organization relationship. In their words, it is "a one-to-one relationship between businesses to allow users in each organization to view calendar availability information." Business-to-business calendar sharing is set up by creating organization relationships; the person-to-person kind, where one user shares their own calendar with a single outsider, is a different setting called a sharing policy. For coexistence you want the org relationship, because you want everyone in scope to see everyone else — not to chase individual shares.
The part people forget: it has to be built at both ends. A Contoso admin creates a relationship pointing at Tailspin Toys, and a Tailspin Toys admin creates one pointing back at Contoso. You are only ever responsible for your own side — you specify the level of information users in the external organization can see in your tenant, and they specify theirs, which can be different. If only one side is configured, the sharing is one-directional and usually looks broken to the people who expected it to work.
Configure only one side and it looks broken. The relationship has to exist at both ends.
Choosing how much detail to expose
When you set up your side, you pick one of three levels of access, straight from the Exchange documentation:
- No access.
- Access to availability (free/busy) time only.
- Access to free/busy, including time, subject, and location.
Most coexistence projects settle on free/busy time only — enough to find an open slot without exposing what everyone is doing. The richest level is genuinely useful for teams that have already merged in practice and want to see the subject and room of each other's meetings, but it is more than you should hand a partner tenant you barely know. Pick the level that matches how joined-up the two populations actually are, and remember you can raise it later once the migration settles.
An organization relationship exposes availability — it does not join the two calendars. Nobody's mailbox moves, there's no shared item store, and the other tenant's people do not appear in your Global Address List because of it. Even at the richest level, the far side sees blocks of time with a subject and a location, not your calendar. And a user can still opt out: in Outlook, under Calendar Properties then the Permissions tab, they can change or remove the default permission so their free/busy is not shown to internal or external users. The individual's setting wins over the org-level one. Treat the relationship as a window, not a bridge.
Where this sits in the coexistence plan
This work rarely stands alone. It runs alongside the mail coexistence setup — the shared address space, directory sync, and routing that let mail flow between the two tenants during migration — and it usually wants the same up-front trust between the organizations underneath. Sequence it early. Free/busy is the most visible daily symptom of a split organization, so getting the org relationship stood up on both sides in the first wave buys you goodwill and cuts the "I couldn't see your calendar" tickets while the slower mailbox moves grind through in the background. It is a small piece of config with an outsized effect on whether the coexistence feels usable to the people living in it.
The takeaway
Calendars don't cross a tenant boundary on their own, and that's by design. To make free/busy visible between two coexisting Exchange Online organizations you create an organization relationship — one-to-one, built at both ends, set to the level of detail the two sides have earned. It shows availability, not the calendar itself; it is a window into who's free, not a merge of two mailboxes. Stand it up early next to the mail coexistence work, and the split organization starts to feel like one schedule long before the last mailbox has moved.
Questions people also ask
How do I share free/busy between two Microsoft 365 tenants?
You set up an organization relationship between the two Exchange Online organizations. It is a one-to-one relationship, and it has to be configured at both ends: each tenant admin creates the relationship pointing at the other domain and sets the level of availability their users will expose. Once both sides exist, users can look up each other's free/busy when scheduling.
What is the difference between an organization relationship and a sharing policy?
An organization relationship is business-to-business: an admin-configured, one-to-one link between two Exchange organizations that lets all in-scope users see each other's calendar availability. A sharing policy is person-to-person: it governs whether an individual user can share their own calendar with a specific outside person. During a migration you almost always want the organization relationship.
Does an organization relationship share the full calendar?
No. It shares availability, not the calendar itself. You choose one of three levels: no access, free/busy time only, or free/busy plus time, subject, and location. Even at the richest level the other side sees blocks of time with a subject and location, not your mailbox. There is no merged calendar and no shared item store.
Why can't users see cross-tenant calendars by default?
Each Microsoft 365 tenant is a separate Exchange Online organization with its own directory and trust boundary. Availability lookups stay inside that boundary unless an admin explicitly opens a path. Nothing crosses from one tenant to another until an organization relationship is created on both sides, so two coexisting tenants show each other as strangers by default.
Can a user still hide their calendar if an organization relationship exists?
Yes. The organization relationship sets the ceiling, but an individual can still restrict what they expose. In Outlook, under Calendar Properties then the Permissions tab, a user can change or remove the default permission so their free/busy is not shown to internal or external users. Their personal permission wins over the org-level setting.