Migrate from Microsoft Bookings to Easy!Appointments

Migrate from Microsoft Bookings to Easy!Appointments: what the work involves

Moving from Microsoft Bookings to Easy!Appointments is a data and integration project more than a feature copy. The effort depends on three things: how many years of booking history you need to carry over, how many staff members and services sit behind each Bookings calendar, and how deeply Teams meeting links and Exchange scheduling mailboxes are wired into daily operations. A team that wants its appointment data and calendars on its own servers should start by inventorying those three areas before choosing an install date. Bookings' built-in report covers only the most recent 120 days, so older history usually needs Microsoft Graph Bookings APIs or EWS, which requires an admin with access to the tenant and someone who can script the export.

Internal IT usually runs the migration, and many teams bring in a partner for the parts that need specialist hands: installing Easy!Appointments on PHP 8.2 or later with MySQL, mapping Bookings services and staff to providers and services, replacing Teams meeting links, and rewriting the confirmation and reminder emails that Bookings sends automatically. Easy!Appointments is free to license under GPL v3.0 with no recurring fees or booking commissions, so the cost sits in hosting, labor and any custom work. Confirm with the project's author what the Premium Services for installation, migration and support cover before you request a quote, and ask for the mapping of each Bookings staff member to a provider as a written deliverable.

Plan the retirement of the Exchange scheduling mailboxes as the final step, not the first. Keep them running until the new booking pages, reminders and calendar sync have been tested with real staff accounts and customers have been told where to book. Confirm the Google Calendar synchronization you need, since Easy!Appointments documents that integration, and check any Bookings-specific feature your customers rely on, such as SMS reminders, against what you will build or buy. Once the cutover is complete, export and archive the final data set so you can answer a customer's question about an appointment after the Bookings tenant configuration is removed.

Which Bookings features map cleanly to Easy!Appointments and which need rework

This table compares the main Bookings features with their Easy!Appointments equivalents and marks each as clean, needs rework or gap. Read the status column first, then the notes, to see which items are documented and which need confirmation in your own environment. The main takeaway is that core online booking and provider scheduling map well, while SMS, payments, reports and Teams and Exchange behavior need custom work or testing.

Bookings feature	Easy!Appointments equivalent	Status and notes
Services and service duration	Services organized under categories, with durations and prices set per service	Clean. Confirm that the service fields you rely on, such as buffers and capacity, match your Bookings configuration.
Staff members as bookable resources	Providers linked to the services they perform, with their own working hours	Needs rework. Multi-staff service calendars in Bookings must be rebuilt as providers mapped to services.
Customer booking pages	Online booking for customers, built from services and providers	Clean. Rebuild the page layout and wording, then test the booking flow end to end.
Confirmation and reminder emails	Automated notifications exist, but template content and triggers must be checked	Needs rework. Rewrite each message and confirm which reminder timings are available without custom development.
SMS reminders	Not a standard feature; available through custom development	Gap. Plan and price SMS integration as custom work before cutover.
Calendar sync with Google Calendar	Documented synchronization with Google Calendar	Clean for Google. Confirm sync direction and conflict handling in your own tests.
Outlook or Exchange calendar sync	Not covered by the documented capabilities used for this comparison	Confirm in your environment. Test two-way sync with your Exchange or Microsoft 365 calendars before retiring Bookings.
Teams meeting links on bookings	Not covered by the documented capabilities used for this comparison	Confirm in your environment. Plan an alternative meeting link, such as a self-hosted video tool, and test it.
Payments at booking and reports	Payments and reports come through custom development	Gap without custom work. Scope these as separate deliverables if your current workflow depends on them.

Which exports and integrations to pull before you build

Bookings data does not leave in one step. Each export path returns a different slice of history, and the rebuild list covers people, services, customers, calendar links and messages that never move on their own. Settle these inputs before you install anything, so the Easy!Appointments build starts from a known data set.

The 120-day TSV report

The Bookings Home tab offers a TSV report covering roughly the last 120 days of appointments. It is the quickest first pull and the easiest for staff to run without help, but it is only a recent window. Anything older, including past customer visits you may need for follow-up or records, is not in it. Open the file in your tenant and confirm which columns it contains before you plan the field mapping, since the export docs do not describe every field.

Microsoft Graph Bookings APIs

Microsoft Graph exposes Bookings businesses, services, staff and appointments through an API. Use it to pull history beyond the 120-day report and to read service and staff records in structured form. An app or administrator with the right Bookings permissions must run the calls, and you should confirm in your tenant which records and fields come back for past appointments before you rely on them for migration.

EWS where Graph falls short

Exchange Web Services can read the scheduling mailboxes behind each Bookings calendar, which is useful when a Graph call does not return what you need. Microsoft has been moving Exchange integrations toward Graph, so check the current support status for EWS in your tenant before you build a dependency on it. Treat EWS as a fallback for specific gaps, and document which data came from it.

Staff as Easy!Appointments providers

Each Bookings staff member becomes a provider in Easy!Appointments, with their own working hours, services and calendar connection. Build the provider list first and confirm each person's login and contact details, since providers are the anchor for every booking. Decide who keeps administrator rights, because an administrator account is the only way to edit services, providers and settings after cutover.

Services, durations and customer records

Bookings services carry names, durations, buffers and the staff who deliver them. Recreate each one as an Easy!Appointments service and assign it to the matching providers, checking durations line by line because a mismatch shifts every slot. Customer records need a separate review: move only what you have a lawful basis to keep, and remove duplicates before import.

Calendar links and confirmation templates

Easy!Appointments syncs with Google Calendar, so an Exchange-based calendar needs a bridge, a Google Workspace move, or a manual process. Plan this before cutover, because a provider without a working calendar connection can be double-booked. Bookings' confirmation emails, reminders and Teams meeting links do not transfer, so rewrite each template, replace the meeting link source, and test every message on a staging install before go-live.

How the cutover sequence runs from inventory to decommission

The sequence moves Bookings services, staff and customer appointments onto a self-hosted Easy!Appointments install in controlled stages, so each step produces a signed-off artifact before the next one starts. Bookings stays live until the cutover is approved and the history is archived.

Inventory services, staff and active bookings
List every Bookings page, service, staff member, staff calendar and Exchange scheduling mailbox behind them. Export the appointment history with the Bookings report and the Graph or EWS methods your tenant allows, then record which future appointments are still open. The output is a service and staff inventory with a count of active bookings per service, reviewed by the business owner of each calendar. Confirm the export coverage for your tenant before treating the inventory as complete.
Build the service-to-provider map
Map each Bookings service to an Easy!Appointments service and each staff member to a provider, noting durations, buffers, locations and any service that has several staff members. Record where Bookings features have no direct equivalent, such as multi-staff service calendars or SMS reminders, and decide how each gap is handled. The output is a signed-off mapping sheet that the calendar owners approve. Work from the sheet, not from memory, when the test install is configured.
Pilot one service on a test install
Install Easy!Appointments on a test server that follows the PHP 8.2 or later, MySQL and web server requirements, then configure one low-risk service with its mapped provider. Connect a test calendar, book appointments as a customer would, and check that confirmations, reminders and cancellations reach the right people. The output is a pilot log listing each test booking, each result and each defect fixed. Do not move live customers until the pilot log shows no open defects for that service.
Rebuild and approve confirmation and reminder emails
Recreate each Bookings confirmation, reminder and cancellation message in Easy!Appointments, replacing Teams meeting links with the meeting method your organization uses, and test every template against the pilot bookings. Have the business owners and, where customer data is involved, the privacy lead sign off on the wording. The output is an approved email template set with a record of who approved each template and when. Confirm which reminder timings the installed version supports before you sign off.
Run both systems in parallel
For a defined period agreed in advance, let customers book through either Bookings or Easy!Appointments, with each new booking checked against both calendars to catch double bookings. Log every conflict, missed reminder and sync error, and fix the cause before the period ends. The output is a parallel-run report that shows zero unresolved conflicts for the agreed period. Set the length of the period with the calendar owners, based on booking volume in your environment.
Cut over and keep a rollback path
Redirect booking links, website embeds and email signatures to the Easy!Appointments pages, then set the Bookings pages to unpublished rather than deleting them. Keep the rollback plan written down: the steps to restore the Bookings links, who can trigger them and what happens to bookings made during the cutover. The output is a cutover record with the redirect list and a rollback plan approved by the service owner. Keep the Bookings pages available until the archive in the next step is verified.
Archive history and decommission Exchange mailboxes
After the retention owner confirms the appointment history is archived in a readable format, remove the Bookings pages and the Exchange scheduling mailboxes behind them. Check that calendar permissions, shared mailbox delegations and any mail flow rules referring to them are also cleaned up. The output is a decommission checklist with the archive location, the deletion date recorded by the mailbox owner and confirmation that no Bookings page still receives traffic. Confirm the retention requirements of your sector before deleting any data.

What drives migration cost and duration

This table lists the main factors that move the cost and effort of moving from Bookings to Easy!Appointments, with the reason each one matters and how to keep it down. Read it before requesting quotes, since the same driver can be cheap in one organization and expensive in another. No durations or fees are given because none were supplied; use the questions in the right-hand column to compare written quotes.

Driver	Why it changes cost or effort	How to keep it down
Number of staff and calendars	Each provider needs its own working hours, breaks, services and calendar sync, so effort grows with every staff calendar mapped.	Consolidate shared services before export and agree a provider list in writing. Ask the quote to state how many providers are included.
Depth of booking history	Bookings' 120-day report covers only recent appointments, so older history needs Microsoft Graph or EWS extraction and cleaning.	Decide which history must move. Migrate only active customers and future bookings, and archive the rest as read-only files.
Use of Teams meeting links	Each online appointment has a Teams link that must be replaced with another meeting method or a link you manage, and future bookings need rewriting.	List every service that issues Teams links. Ask whether the quote covers replacing links on existing appointments or only new ones.
Custom reminders and confirmation emails	Bookings templates must be rebuilt in Easy!Appointments, and any SMS or extra reminder logic is custom development, which the author describes as available.	Start with the standard notifications and add SMS only if it is required. Ask for each template to be listed as a line item.
Payments	Easy!Appointments does not take payments out of the box. Payment flows need a chosen provider, custom work and testing.	Confirm early whether payments are needed. If they are, price the payment integration separately from the core install.
Exchange and identity integration	Calendar sync and staff login depend on your mail and identity setup. Google Calendar sync is a supplied feature, so Exchange sync needs confirming with the platform and your admins.	Confirm the calendar protocol and sign-in method before starting. Ask the quote to state who tests sync with live staff calendars.
Exchange scheduling mailboxes	Removing the scheduling mailboxes needs sign-off, a record of their contents and a check that no other flows depend on them.	Inventory them early and agree a retirement date with the business owner. Ask who approves deletion.
Self-hosting versus Premium Services	Hosting it yourself means internal staff time for installation, PHP and MySQL upkeep, upgrades and support. The author sells Premium Services for installation, upgrades, migration, support and customization.	Ask whether the quote includes handover documentation. Compare an internal effort estimate against a Premium Services quote for the same scope.

How Easy!Appointments hosting fits your infrastructure

Easy!Appointments needs a web server running Apache or Nginx, PHP 8.2 or later, and a MySQL database. The install is manual: create the database, copy the files to the web root, edit the configuration file with the database settings and base URL, then open the install URL in a browser. Before you build anything, confirm that your target server image and PHP packages meet the PHP 8.2 floor, and check the version list on the Easy!Appointments releases page. Version 1.6.0 was published on May 27, 2026, and 1.6.1 is still in beta, so test the exact version you plan to run in production in a staging instance loaded with migrated data before cutover.

The server belongs inside your own boundary: a virtual machine in your cloud account, a data center host, or an internal VM on a network segment where booking data can stay. Calendar sync to Google Calendar is a supported integration, so decide whether outbound connections to that service are allowed from the segment, and whether customer records may leave it. Once live, the team owns everything the vendor does not: operating system and PHP patching, MySQL backups with tested restores, TLS certificates on the public booking URL, an outbound mail relay for confirmations and reminders, and access control for the admin console and database accounts. Write down who owns each item before go-live, because a booking system that customers reach daily tends to lapse without a named owner.

Installation is only the first step. Your team will also need a runbook for upgrades, since the author sells Premium Services for installation, upgrades, migration and support, and a partner or internal engineer can provide the same work. Ask any implementation partner for a written scope that covers hardening, backup verification, mail deliverability testing and the upgrade path, and confirm which of these your own staff can perform without the author's help.

What usually goes wrong and how to prevent it

Most failed Bookings migrations break at the seams: the export, the identity mapping, the notifications, and the mailboxes that quietly hold the only copy of history. The cards below cover six risks that recur, each with a check you can run before the cutover date. Work through them in order, because later steps depend on the data you verified earlier.

Treating the 120-day report as a full export

The Home tab report from Bookings covers a fixed window of recent appointments, so it does not hold the full history. Teams that import only that file lose older bookings, customer notes and no-show records that finance or compliance may still need. Before you retire anything, request the full history through Microsoft Graph and EWS, then compare appointment counts per calendar against what Bookings shows. Keep the raw exports as an archive alongside the Easy!Appointments database.

Mismatched provider and staff identities

Bookings staff are identified by Microsoft 365 accounts, while Easy!Appointments stores providers as its own user records with their own login and calendar settings. If a person is entered twice, or a shared mailbox is mapped as a provider, appointments land on the wrong calendar or appear unassigned. Build a mapping table from each Bookings staff member to one provider record and confirm that every migrated appointment resolves to exactly one provider before go-live.

Duplicate or missing reminders during parallel run

Running Bookings and Easy!Appointments side by side means customers can receive two confirmations or two reminders, or none if one system has been switched off early. Pick a single cutover point per service, disable Bookings notifications for that service first, and then enable Easy!Appointments reminders. Send a test booking to an internal address and check the reminder timing against a real appointment before you move customers across.

Broken Teams links in upcoming appointments

Bookings can attach Teams meeting links to appointments, and Easy!Appointments does not create those links. Future appointments that still point to Teams URLs will fail once the meeting is cancelled or the tenant changes its policies. List every upcoming appointment with a Teams link, decide whether it is kept or rebooked, and send replacement links from the video tool you have chosen. Do not assume the old links will keep working after the cutover.

Deleting Exchange mailboxes before verifying the archive

Each Bookings calendar is backed by an Exchange scheduling mailbox, and deleting it removes the calendar data that may not exist anywhere else. Teams often delete these mailboxes soon after the export, then discover a gap during a customer dispute or audit. Restore the archive into a test environment, confirm that appointment counts, customer details and timestamps match, and keep the archive under your retention policy before you delete any mailbox.

Time zone and recurring appointment errors

Bookings stores times with its own time zone handling, and recurring appointment series may be exported as separate records or lose their rule. A 9:00 appointment can shift by an hour after a daylight saving change, or a weekly series can stop after its first occurrence. Check the server and database time zone settings in your Easy!Appointments install, then compare a sample of recurring and cross-zone bookings against the source system on both sides of a daylight saving date.

How the migration differs by size and starting point

A solo practitioner or a practice with one or two staff usually has a small Bookings footprint: one or two calendars, a short list of services and a modest number of future appointments. The migration is mostly a configuration exercise. Easy!Appointments needs one provider record per person, the services you actually sell, working hours and a booking page. Because the data set is small, a full export and a manual reconciliation of upcoming appointments is realistic work for one person in a short session.

Scope: Confirm which future appointments must be carried over and which can simply end on the Bookings side with a clear notice to clients.
Testing: Book a test appointment for each service, then check the confirmation email, the calendar entry and the reminder before you publish the link.
Approvals: Usually none beyond the owner, but write down who owns the hosting account and the database credentials.
Mail and calendar: Decide whether Easy!Appointments writes to your personal calendar through Google Calendar sync or whether you keep working in Outlook and copy entries across.
Hosting: A small PHP and MySQL server, often a managed shared host that meets the PHP 8.2 requirement, may be enough.

Before you switch, ask your hosting provider to confirm PHP 8.2 or later and MySQL support, and remove the Bookings link from your website and email signature on the same day.

Questions buyers ask before moving off Microsoft Bookings

How much does a migration from Microsoft Bookings to Easy!Appointments cost?

The cost is driven by the work, not by a license fee, because Easy!Appointments is free with no recurring fees or booking commissions according to its website. The main cost components are the server and database you run, the time to map services and staff to providers, rebuilding confirmation and reminder emails, testing calendar sync, and any custom work such as SMS or payments. Hosting and staff time recur, while setup is largely one-time. Ask any provider for a fixed-scope quote that lists each component, the systems in scope, and what is excluded. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does it take to move booking data off Bookings?

The timeline depends on how many calendars, services and staff are involved, how much booking history you need to keep, and how many notification templates must be rebuilt. The Bookings 120-day report covers only recent history, so pulling older bookings through Microsoft Graph or EWS adds extraction and validation work. Parallel running, where Bookings and the new system both accept bookings during a cutover window, also extends the schedule. Ask for milestones in the written scope so each stage, from the server build to retiring the scheduling mailboxes, has a clear deliverable.

What does the internal team need to provide during the migration?

The internal team needs to provide decisions and access rather than building the system themselves. In practice that means a named owner for services and provider rules, someone who can confirm which staff members take which appointments, access to the Microsoft 365 tenant for the export, and approval for the MySQL server and PHP runtime. Staff who send confirmations or take reminders should review the new email templates. Ask the implementation partner which of these tasks they carry and which fall to your team, and confirm it in the scope document.

Can an administrator migrate Bookings to Easy!Appointments alone?

A capable administrator can install Easy!Appointments alone for a small setup, since the documented steps are to create a database, copy the files, edit the configuration file and open the install URL. The harder parts are extracting full history through Microsoft Graph or EWS, mapping Bookings staff and services to providers, configuring calendar sync, and rebuilding email flows. Those tasks need Microsoft 365 administrator rights, security review of app permissions, and testing. Decide early whether one person can cover all of it or whether a partner will take the export and cutover.

Can Teams meeting links and reminders be kept after the move?

Easy!Appointments does not create Teams meetings, so each booking that used a Teams link needs a replacement, such as a video link from a platform your organization already runs, or a manual link added to the confirmation. Reminders can be kept, but they must be rebuilt, since Easy!Appointments reminder behavior and any SMS or payment steps come from configuration or custom development that its website describes. Confirm with the vendor and in your own environment exactly which reminder channels you need before the cutover.

What should happen to the Exchange scheduling mailboxes?

Do not delete the Exchange scheduling mailboxes until the migrated data has been checked and the old booking pages are shut down. Export the booking history you must retain, confirm that customers can no longer book through Bookings, and record which retention rules apply to appointment records. Then remove the mailboxes or their scheduling role according to your records policy. Ask your compliance lead to confirm the retention period and how deletion is evidenced, because DeployOpen prepares controls and evidence but does not issue audit reports or certifications.

Does a migration need security review of the new server?

Yes. Appointment data includes customer names, contact details and sometimes health or service information, so the server, database backups, TLS configuration and access to the admin area need review. Easy!Appointments requires PHP 8.2 or later with MySQL and a web server such as Apache or Nginx, and each of those components needs patching and a documented owner. Include security testing and hardening in the written scope and ask for the controls evidence your auditors will request.

How DeployOpen scopes and runs this migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Bookings move, that means the Easy!Appointments server, its MySQL database, the web tier and the connection to the calendars your staff already use run in your cloud account, data center or restricted network, not in a DeployOpen environment. The first decision is where that boundary sits: which tenant or mailbox calendars are in scope, who owns the database credentials, and where backups are kept. Engagements are fixed-scope. Before any work starts, the scope, deliverables and timelines are agreed in writing. For this migration, the written scope should list the Bookings services and staff to be mapped to Easy!Appointments providers, the export method for historical bookings, the Teams meeting link replacement, the rebuilt confirmation and reminder emails, the test plan, and the retirement steps for the Exchange scheduling mailboxes. Ask for each item to be named as a deliverable so that acceptance can be checked against it. DeployOpen does not publish a price list. A quote follows from the written scope, so the fastest way to get an accurate one is to bring a complete inventory of services, staff, booking pages and integrations to the first call. Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope project. Easy!Appointments releases, including the 1.6.0 release published on May 27, 2026, will need patching and PHP and MySQL maintenance after go-live, and a retainer is one way to keep that work scheduled. Ask whether a retainer covers the version upgrades, backup restore tests and the hosting platform itself, and what the response expectations are, since those terms should be written into the agreement rather than assumed.

Migrate from Microsoft Bookings to Easy!Appointments