How do I move Microsoft Bookings to another tenant?

What Microsoft supports#

• Cross-tenant mailbox migration needs a paid Cross-Tenant User Data Migration licence (a one-time fee) for each mailbox. It moves user-visible mailbox content only. Microsoft adds that it "only migrates mailbox data and nothing else". Teams meeting links in migrated calendar items stop working in the target tenant, so you have to "remove and recreate Teams meetings". Cross-tenant mailbox and calendar permissions don't carry over either.
• Booking pages aren't mentioned. A shared page is a mailbox of type SchedulingMailbox that holds the business details, staff, services and appointments. The migration article doesn't list that type as supported or unsupported. We haven't tested it. Even if some calendar items came across, nothing Microsoft documents says the page setup would, so don't build a plan around it.
• Microsoft Graph is the route Microsoft itself suggests for copying a page. Asked whether Bookings calendars can be cloned, the FAQ says: "use the Graph API to get mailbox details, and then use those details to create a new mailbox." The Bookings API can read everything from the old page and create it again in the new tenant.

What you lose in the move#

Migration checklist#

Before the move (in the old tenant)

1. List every page: Get-EXOMailbox -RecipientTypeDetails SchedulingMailbox -ResultSize Unlimited. If you can't open some of them, give yourself access first.
2. Export each page's bookings as a TSV file. The FAQ says each export covers 120 days, so export several date ranges to cover a full history. See exporting to Excel.
3. Pull the page setup with Graph (GET /solutions/bookingBusinesses/{id}, plus /services, /staffMembers, /customQuestions and /customers). Screenshot any settings you can't find in the output. The customer list export covers the customers call.
4. Write down every place each link is published: website buttons, embeds, email signatures, ads, QR codes and flows.

Rebuild (in the new tenant)

5. Set the default domain for new booking mailboxes before you create any pages, so they don't end up on onmicrosoft.com.
6. Create each page. You can do this in the web app, or with POST /solutions/bookingBusinesses, which needs the delegated Bookings.Manage.All permission. Application permissions aren't supported for this call. Then add staff, services and custom questions (Bookings.ReadWrite.All).
7. Create customers, then future appointments (BookingsAppointment.ReadWrite.All). Each appointment has an optOutOfCustomerEmail property. Set it to true if you don't want every customer to get a new confirmation during the import. Test on one appointment before you trust it.
8. Publish the page (POST /solutions/bookingBusinesses/{id}/publish) and make a test booking from a private window.

Cutover

9. Update every link from step 4. Tell customers who have upcoming appointments that their old manage links will stop working, and give them the new page.
10. Unpublish the old page, but keep it until the last imported appointment has passed and your exports are safe. Then delete it. Deletion is permanent (see deleting a Bookings page).

The Graph Bookings API applies only to shared booking pages. Bookings with me pages have no API, so each person sets theirs up again in the new tenant.

Doing this with BookingsXP#

If your website shows the booking page through a saved BookingsXP widget, the Microsoft Bookings link is stored once in the widget settings, not in your site code. At cutover you paste the new page link there, and every embed and the hosted page at bookingsxp.com/book/<your-name> switch over together. Services and staff get new IDs in the new tenant, so check any service or staff preselects afterwards. BookingsXP doesn't move any Bookings data. See embedding options. BookingsXP is independent and not affiliated with or endorsed by Microsoft.