How to export your data from Microsoft Bookings before the contract ends
If a Microsoft 365 renewal, a licensing change or a residency requirement is pushing you off Bookings, the data can be pulled out in two ways. The 120-day TSV report on the Home tab of the Bookings page gives a quick snapshot of recent appointments, and Microsoft Graph Bookings APIs or EWS are the routes for full history. Export one test calendar first and compare its rows with what the web app shows, so you know what the file contains before the contract clock runs down. Expect appointment records, customer details entered in the booking form, and the service and staff names attached to each booking. Those fields are what a replacement needs to rebuild services and providers.
What generally does not come out cleanly is the configuration around the data: booking page layout, business hours and staff availability rules, custom questions, confirmation and reminder email wording, and the Teams meeting links tied to each appointment. Record these from the admin screens and keep screenshots before access changes. Confirm in Microsoft's own documentation which fields each export includes today, what retention limits apply to each API, and whether notes or attachments are returned, because these details change and this page does not set them.
Each Bookings calendar is backed by an Exchange scheduling mailbox, and its items sit outside the Bookings report, so handle it as a separate workstream. Ask your Microsoft 365 administrator which mailboxes belong to which calendars, whether they hold confirmations or calendar items you need, and who may read them under your retention policy. Keep read-only copies of every export under that policy. Delete the scheduling mailboxes and the Bookings calendars only after the replacement has loaded the data, reconciled it with the exports and passed tests with sample bookings.
Which Bookings data can be exported and by which method
This table maps each Bookings data type to the export method Microsoft documents, the output format and the known limits. Where Microsoft's format or retention is not confirmed for this move, the cell tells you what to check first. Read the limit column before you plan, because the 120-day Home tab report will not capture older history on its own.
| Data type | Export method | Output format and known limit |
|---|---|---|
| Appointments | Home tab TSV report for recent bookings; Graph Bookings APIs or EWS for older history | TSV from the Home tab covers a 120-day window. Confirm the Graph and EWS output formats and how far back they reach. |
| Customers | Confirm with Microsoft whether the Home tab report or Graph Bookings customer resources return customer details | Confirm which customer fields are returned and whether personal data can be exported in bulk. |
| Services | Microsoft Graph Bookings APIs; confirm whether the Home tab report includes service definitions | Confirm the returned fields, such as duration, price and buffer times, and their output format. |
| Staff | Microsoft Graph Bookings APIs for staff assigned to each service | Confirm whether staff membership appears in appointment exports or only through the API. |
| Calendar settings | Confirm with Microsoft which availability, business hours and booking page settings are exportable | Underlying calendar items sit in the Exchange scheduling mailbox. Confirm whether EWS or Graph returns them, and plan manual rebuilds for anything else. |
What does not come out of Bookings and how to rebuild it
Bookings exports cover the data records: appointments, customers and services. The items below sit in settings, templates, integrations or payment systems, so they usually need to be recorded before you retire the tenant and rebuilt in the target platform. Treat each one as a separate line in your migration checklist with an owner.
Teams meeting links
Bookings can attach a Teams meeting to each appointment, and the join URLs live in Teams and Exchange rather than in the appointment record you export. Once the Bookings service is gone, those links stop working. Before cutover, list which services generate online meetings and decide the replacement, such as a Nextcloud Talk room or another conferencing tool. Then tell customers the new join method, and confirm that existing future appointments are rebooked or updated in the new system rather than left pointing at dead links.
Booking page branding and public URLs
The public booking page URL, logo, colors, business hours display and business information are configured in the Bookings admin pages and are not part of the TSV report. Customers who saved the old URL or linked it from a website will land on an error page after you retire the calendar. Record the page address, screenshots of the current layout and every place it is linked from, such as your website, email signatures and invoices, so the new booking page can be published and the old links redirected or updated.
Confirmation and reminder email templates
The wording, sender name and attachments of confirmation, reminder and cancellation emails are set inside Bookings. Exporting appointments does not export these messages, so the new platform will send nothing until you write each template again. Copy the current text from the admin settings, note any dynamic fields you relied on, and check the reminder timing against what customers expect. Test each message type with a dummy appointment before go-live, and confirm the sending domain has the SPF, DKIM and DMARC records your mail team requires.
Payment and deposit records
If Bookings collected payments or deposits, the transaction history sits with the payment processor and the Microsoft billing layer, not in the appointment export. Your new platform will not hold those records or the link between a charge and an appointment. Ask finance to export settled transactions, refunds and open balances from the processor, and store them with the customer identifiers they match. Keep the processor account active for refunds and dispute windows, and confirm whether your target scheduler collects payment at all before you promise customers the same flow.
Custom questions and intake answers
Custom booking questions and the answers customers gave are only partly visible in the exports. Question wording, required flags and the order they appeared in are configuration, so they must be recreated by hand in the target platform. Export the answers that the API or report returns, then map each question to a field in the new form, including any free-text values that do not fit a dropdown. Check that sensitive answers, such as health or legal details, keep their access restrictions after they move to your own server.
Staff availability and working hour rules
Each staff member's working hours, time zone, buffers, blocked dates and the rule that controls how far ahead customers can book are set in Bookings and may not appear in a flat export. Rebuilding them from memory tends to produce bookable slots that do not match the rota. Record each staff rule from the admin pages, compare the first two weeks of generated slots in the new platform against the old calendar, and confirm how the target handles holidays, time zone changes and staff who are on leave.
Choosing between the Home tab report, Graph and EWS
The Home tab report is the fastest route to a recent snapshot. It is generated from the Bookings web app, so the person running it needs access to the booking business and sign-in rights to Bookings. It covers the 120-day window that the report includes, so it will not return older history.
- Who runs it. Any staff member who can open the business in Bookings can export, usually an owner or administrator of the booking business.
- Permissions. No API consent or separate admin role is needed beyond access to the business. Confirm this in your tenant, because admin policies can restrict Bookings.
- Output. A tab-separated values file of recent appointments that opens in a spreadsheet and can seed a migration worksheet.
- Right choice. Quick reconciliation, or a small business where only current and near-term bookings matter.
Check the file's columns against your own services and staff list before relying on it, since the file reflects what Bookings currently shows and may omit older records.
Microsoft Graph exposes Bookings resources such as businesses, services, staff members and appointments through a REST API. It suits a scripted export that writes structured records into your own database or into the import format of the target platform. Someone with development skills and an app registration in Microsoft Entra ID builds and runs the client.
- Who runs it. A developer or platform engineer who writes and maintains the script, working with a tenant administrator to grant consent.
- Permissions. Bookings access is granted to an app registration, either as delegated permissions for a signed-in user or as application permissions with admin consent. Confirm the exact permission names in the current Graph reference.
- Output. JSON objects for each business, service, staff member and appointment, which need mapping to your providers and services.
- Right choice. Full customer and appointment records that require transformation, repeatable test runs, or incremental exports during a cutover period.
Before building, confirm in Microsoft's current Bookings documentation which endpoints are available, how paging and retention behave, and whether any endpoint is marked deprecated.
Exchange Web Services reads the items stored in mailboxes, including the calendar items in the scheduling mailboxes that sit behind each Bookings calendar. It is the route to mailbox-level history when the Bookings API does not return what you need. Its status is changing, so treat it as a fallback while you verify it in your tenant.
- Who runs it. An Exchange administrator or a service account with access to the scheduling mailboxes, with access scoped by the tenant.
- Permissions. Mailbox access is granted through Exchange role assignments or application access policies. Confirm the current role and authentication requirements in Microsoft's Exchange documentation.
- Output. Calendar and message items returned as XML, typically parsed by a script or read through an export from a mail client. Items reflect the mailbox view, including confirmations and cancellations.
- Right choice. Recovering older items, or checking what a scheduling mailbox holds when the other two routes leave gaps.
- Deprecation risk. Microsoft has been moving Exchange Online away from EWS, so confirm its availability before you plan a migration around it.
Confirm the current EWS status and access model in your tenant, and test a single mailbox before running a full export.
The export sequence for a complete Bookings move
This sequence turns scattered Bookings data into a verified, restricted archive that maps cleanly onto any target scheduler. Each step closes with a check, so you know what was captured before the Bookings calendars are touched.
Inventory every Bookings calendar and its staff
Before exporting anything, list each Bookings calendar in the tenant, the services it offers, the staff members assigned to each service, and the business owner who signs off on the move. Note which calendars are active, which are inactive, and which share staff, because shared staff are where duplicate or conflicting records usually appear. Your inventory is complete when every calendar has a named owner, a service list, and a staff list that the owner has confirmed in writing.
Run the Home tab report for each calendar
Open each calendar in Bookings, use the Home tab to generate the appointment report, and download it as a TSV file. The report covers a limited recent window, so label each file with the calendar name and the date range it shows, and do not merge files from different calendars at this stage. Check that the row count in each file matches what the Bookings list view shows for the same window. If the counts differ, record the gap before going further.
Pull older bookings through Graph or EWS
Appointments outside the Home tab window must come from programmatic access. Use the Microsoft Graph Bookings APIs for appointments, customers and services, and use EWS where you need mailbox-level history that Graph does not return for your case. Confirm current endpoint support and retirement notices with Microsoft before you start, since API availability changes. Your check is a count comparison: for each calendar, the API export should cover every appointment the Home tab report shows plus the older records, with no duplicate appointment IDs.
Store raw output unchanged in a restricted location
Copy every TSV, JSON and EWS export into a restricted storage location with access limited to the people running the migration, and record a SHA-256 checksum for each file in a manifest. Do not edit, sort, or clean these files, because the raw copy is your evidence and your rollback source. Keep the location under your own control, apply the same retention and access rules that govern customer personal data in your organization, and confirm with your privacy or legal team how long the archive must be held. The step is done when the manifest lists every file and a second person has verified the checksums.
Normalize records into a mapping sheet
Working from copies of the raw files, build a mapping sheet that links each Bookings field to a field in the target system: service names to services, staff to providers, customer name and email to client records, and appointment start and end times to the target's time zone model. Record time zone handling explicitly, because Bookings and most schedulers store and display times differently. Flag any field with no target equivalent, such as Teams meeting links, custom questions, or SMS settings, and decide what happens to each one. The check is a sample of at least one appointment per calendar, traced by hand from the raw file through the mapping sheet to the expected target record.
Compare counts and spot-check against live calendars
Load a test import into a non-production copy of the target system, then compare record counts per calendar, per staff member and per year against the raw export. Differences in counts, missing customers, or shifted times must be explained or fixed in the mapping sheet before any production load. Ask a calendar owner to spot-check a random sample of appointments against the live Bookings calendar, including recent, future and cancelled entries. The step closes when the owner signs off on the sample and the differences log is empty or fully explained.
Delete Bookings data after the move is verified
Only after the target system has passed the reconciliation, plan the deletion of Bookings calendars, customer records and the Exchange scheduling mailboxes that sit behind them. Confirm with the business owners that no open appointments remain, that the raw archive is retained under the agreed policy, and that any retention obligation is met. Remove the calendars in a controlled change, keep a record of who approved each deletion, and check that booking pages no longer accept new appointments. Confirm the final state with an admin check of the tenant and the mailbox list.
How to verify the export is complete before deleting anything
Do not delete anything in Bookings until you have proved that the export holds every booking, customer and service you need. Reconcile counts per calendar: for each Bookings calendar, compare the number of appointments, customers and services in your export file against the same counts in the live Bookings views for the same date range. Run the comparison calendar by calendar, not as one total, because a missing calendar can hide inside a matching overall number. Where the export came from the 120-day report, note the date range it covers and check that older appointments were pulled through the Graph or EWS route described above, so that gaps are found now rather than after the Exchange scheduling mailboxes are gone.
Then test the content, not just the counts. Pick a sample of appointments across several staff members and months, and compare start and end times, customer names, service names and assigned staff against the live calendar. Pay particular attention to time zones: confirm which time zone the export uses and whether it matches the calendar's configured zone, especially for appointments near daylight saving changes or for customers booked from another region. Also decide, and write down, how cancelled, no-show and past appointments will be handled. Some may belong in the new system as history, others may be intentionally excluded, but each category should have a named owner and a recorded decision, not an accidental omission.
Keep the outcome as evidence. Store a signed-off reconciliation record that lists each calendar, the counts compared, the sample checked, the time zone finding, and the decisions on cancelled and past appointments, with the names and dates of the people who approved it. Keep a read-only copy of the raw export alongside it, with checksums if your process uses them. Retain both for as long as your records policy requires, and confirm that period with your compliance or legal team before any deletion. Only after that approval should the Exchange scheduling mailboxes and Bookings calendars be removed, because deletion is the one step in this migration that cannot be reversed from the export.
What to plan before the Microsoft 365 renewal or termination
The export itself is the easy part to schedule. The decisions that determine whether it succeeds are made earlier: which plan carries Bookings, when new bookings stop, who signs off, and how long the old data must be kept. Each item below is something to confirm with the account team or against the organization's own records before the contract date.
Confirm the Bookings plan and read access
Bookings is included in certain Microsoft 365 and Office 365 plans rather than sold on its own, so the first step is to confirm which plan and add-ons currently enable it. Ask the account team whether calendars, services and booking history remain readable after a downgrade, a license removal or a tenant change, and whether any administrator role is needed to run the Bookings report or call the Graph endpoints. Record the answer in writing, because a downgrade can remove the interface you planned to use for the export.
Set a freeze date for new bookings
Every booking made after the export snapshot is a record the target system will not have. Choose a freeze date, communicate it to staff and to any public booking page links, and decide whether existing future appointments are migrated or left to run out in Bookings. Plan a cutover point on the freeze date so that bookings created before it are exported and bookings made after it are handled manually. Without this, the team spends the final weeks reconciling records that changed after the snapshot.
Name the export owner and sign-off
Assign one person to own the export, one business owner to approve the data set, and one security or privacy contact to approve how appointment records are stored. The owner should agree which fields are required, such as customer name, contact details, service, staff member and notes, and who may review the extracted files. Written sign-off on the record count and the field list protects the organization if a customer later disputes a booking that is missing from the new system.
Schedule the target build and test window
The target system must be installed, configured and tested before the Microsoft 365 contract ends, not after. For Easy!Appointments that means provisioning a PHP and MySQL environment, mapping services and providers, and testing booking confirmations and calendar sync. For Nextcloud it means a supported server release with its database and identity integration. Confirm internally how long the build and test takes, who performs it, and whether the team needs a support or implementation partner, then fix the window against the contract date.
Plan a parallel run
Run the old and new booking pages side by side for a defined period so that staff can compare what each system shows for the same provider and day. Decide which system is the source of truth during the overlap, how cancellations made in one system are mirrored in the other, and how calendar invitations are handled so that customers do not receive duplicate or conflicting emails. Agree the exit criteria for the parallel run in advance, such as a matching record count and no unresolved calendar conflicts, so the decision to switch off Bookings is evidence-based.
Check retention and legal hold
Appointment records often contain personal data, health or financial details, and customer communications, so their retention period may be set by policy, contract or regulation rather than by the software. Ask the legal, privacy and records teams whether any hold applies to the Bookings mailboxes, calendars or exported reports before deletion, and whether the export format meets the organization's archive rules. Confirm how long Microsoft retains data after the subscription ends and document the deletion date of the old Exchange scheduling mailboxes so the decision is traceable.
Retiring the Exchange scheduling mailboxes after the move
Each Bookings calendar is backed by an Exchange scheduling mailbox that holds its booking data, so retiring it is a deliberate step, not a clean-up task. The order of operations matters: stop new bookings first, complete and verify the export, keep the mailbox for a defined hold period, and only then remove the mailbox and release its licenses. Removing it early can destroy the only copy of history that the 120-day report and API pulls did not capture. Before you start, confirm with your Microsoft 365 administrator how the mailbox is licensed and whether any retention or litigation hold applies to it, since holds can block deletion until they are lifted.
Before removal, check that nothing else depends on these mailboxes. Review mail flow rules, transport rules, shared mailbox delegations, forwarding settings, and any connectors or line-of-business applications that send confirmation or reminder mail from the scheduling address. Confirm with records and legal owners whether mailbox content falls under a retention label or a compliance policy, because the export proves the booking data was moved but does not necessarily satisfy the retention obligation for the original mailbox. Ask the administrator to list every object that references the mailbox so the inventory is based on evidence, not memory.
Record the removal as an approved change in your change management system. The record should name the mailboxes, the verified export package and its checksum or sign-off, the hold period agreed with the business owner, the rollback position, and the approver. Tie the change to the decommissioning of the Bookings calendars so auditors can trace the chain from source data to destination system. Keep the export and the change record together for the period your retention schedule requires, and confirm that period with your compliance lead rather than assuming it.
Questions teams ask before exporting Bookings data
How long does exporting Microsoft Bookings data take?
The time depends mainly on how much history you hold and how many calendars sit behind it, so no single duration applies to every tenant. The TSV report from the Home tab covers only the last 120 days, so it is quick but incomplete. Full history requires scripted calls to the Microsoft Graph Bookings APIs or EWS, and those calls are paced by service limits, which can stretch a large export across a longer run. Ask any provider for an estimate based on a sample run against your own tenant, and for the exact paging, retry and throttling approach they will use.
Do we need an outside consultant to export Bookings data?
Not always. A tenant administrator can download the 120-day TSV report without outside help, and that may be enough if older appointments have no legal or operational value. Outside help becomes worth considering when you need full history, when a scripted extraction must be written and tested, or when the export must be documented for an audit or a data protection review. Whether you hire a consultant, use an internal engineer or do the work yourself, the steps are the same: define the data, extract it, validate it and store it under your controls.
What does our internal team need to provide for the export?
The internal team owns decisions that no outside party can make for you. Expect to provide tenant administrator access or a delegated account with rights to read Bookings and the relevant mailboxes, a list of business units and calendars in scope, the retention period you must meet, and a named approver for field-level decisions such as which customer notes to keep. You also need a storage location that matches your data classification rules, and a validation window in which staff confirm that appointments, services and staff names match what the business expects. Confirm these responsibilities in the written scope before work starts.
Can we export Bookings data without developers?
Partly. An administrator can run the TSV report and save the file, which covers only the last 120 days and gives flat data without full detail on every booking. Anything older needs the Microsoft Graph Bookings APIs or EWS, which are normally called from a script written by someone who can handle authentication, paging and error handling. Without that skill, the practical route is a short engagement with an engineer who writes and documents the script, after which a non-developer can rerun it. Ask whether the script is delivered with a runbook and whether it logs failed records.
What happens to the Exchange scheduling mailboxes during an export?
Each Bookings calendar is backed by an Exchange scheduling mailbox, and that mailbox sits behind the booking page and its appointment data. Export first, then decide when to retire the mailboxes, because deletion is the step that carries the most risk. Before deleting anything, confirm with Microsoft how deleted mailboxes and Bookings data are retained and recovered in your tenant, and check whether any other process, such as calendar sharing or mail flow rules, depends on them. Record the deletion in your change log and keep a verified copy of the export for the retention period you set.
What drives the cost of a Bookings data export?
Most of the cost is labor. The main components are discovery of calendars and data fields, writing and testing the extraction, handling paging and throttling, mapping and cleaning records, validation with the business, and secure storage and deletion of the output. Costs rise with the volume of history, the number of calendars, the amount of free-text notes that need review and the number of validation cycles. Costs fall when the TSV report meets the need, when the data model is clear and when staff are available quickly for sign-off. One-time work covers extraction and cleanup, while recurring costs appear only if you run a sync during a parallel period or keep a support retainer. Ask each provider for a quote that prices every component separately.
What should a written scope for a Bookings export include?
A useful scope names the source, the data, the destination and the acceptance test. List the tenant and calendars in scope, the time range, and the entities to extract, such as appointments, customers, services, staff and availability settings. Specify the method, whether the TSV report, the Graph Bookings APIs or EWS, and how throttling and failed records will be handled. Define the output format, storage location, access controls and the deletion date for working copies. Include validation with reconciliation counts and sign-off by a named owner. Finally, state the deliverables, the timeline agreed in writing, and what is excluded, such as Teams meeting links or payment records.
Does an exported Bookings file contain personal data that needs protection?
Yes. Appointment exports usually contain customer names, email addresses, phone numbers, appointment times and free-text notes, which may include health, financial or other sensitive details depending on your business. Treat the file as personal data from the moment it leaves Microsoft. Limit who can open it, keep it in a location your security policy approves, avoid copying it to personal devices and set a deletion date for working copies. Check whether your records of processing and any impact assessment need updating, and involve your privacy or compliance lead before the export runs. Ask the provider how they will handle the data during the work and who will have access to it.
How DeployOpen scopes and delivers a Bookings data exit
DeployOpen plans and delivers the export of Bookings services, staff, customers and appointment history as a fixed-scope engagement, agreed in writing before work starts. The work runs inside your own infrastructure, so the extracted data is handled on systems you control from the first pull to the final handover.
How we scope
- Inventory every Bookings calendar, service, staff member and booking page, and record which ones must move.
- Confirm which history exists beyond the 120-day report and which access method covers it.
- Agree in writing which Exchange scheduling mailboxes are kept, archived or deleted after cutover.
How we build
- Build the extraction scripts against Microsoft Graph and EWS, run them with least-privilege credentials, and log every pull.
- Map exported services and staff to the target scheduler's providers, services and working hours.
- Test the import in a staging copy and compare booking counts and times against the source before go-live.
How we hand over
- Deliver a written runbook covering each export step, the field mapping and known data gaps.
- Provide an evidence pack with extraction logs, reconciliation results and the deletion record for each mailbox.
- Walk your administrators through the cutover checks and the retention steps before the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover is complete.
- Keep backups of the target system and document the restore steps alongside the export records.
- Ask your team to confirm retention rules with legal or compliance owners before any mailbox is deleted.
