Which fits: Bookings or Cal.diy for a Microsoft Bookings replacement?
Microsoft Bookings fits a department that needs shared service calendars with several staff members, customer booking pages and Microsoft 365 administration already in place. Cal.diy fits personal event types on infrastructure you manage yourself, and its README strictly recommends it for personal, non-production use only, at your own risk. If your team needs a production scheduling service with multi-staff calendars and support you can rely on, that caveat decides the question before features do.
Start with the calendar model. Bookings organizes availability around shared service calendars that staff are added to, which is the pattern most departments depend on. Cal.diy is built around each person's event types and connected personal calendars. Cal.diy's README removes Teams and Organizations features, so a shared calendar that several people book against is not a supported pattern in the fork. Confirm this with a test booking across two staff accounts before committing. Also confirm which calendar providers your staff use, since Cal.diy lists Google Calendar and Microsoft Graph integrations on its Integrations page.
Next, assess operations. Cal.diy requires Node.js 18 or later and PostgreSQL 13 or later, and it is typically deployed from its Docker image. Someone on your team must own patching, backups, database administration and the security of the booking data, including invitee names and contact details. The README states this requires advanced server administration knowledge. If you cannot staff that role, or you need a vendor to answer for uptime, a supported Cal.com plan or a different self-hosted tool such as Easy!Appointments may be the better route. Record the decision in writing with the owner, the data residency requirement and the review date.
Which option fits each scenario
This table maps common situations to the better fit between Microsoft Bookings and Cal.diy and gives the reason for each. Read it against your own scale, support capacity and whether the booking data must stay inside your network. The main takeaway is that Cal.diy suits personal use and evaluation, while shared departmental or production scheduling needs a supported path.
| Scenario | Better fit | Reason |
|---|---|---|
| One practitioner with personal booking links | Cal.diy, if you can run the server | Personal event types and calendar connections match Cal.diy's design, and the README recommends it for personal, non-production use. |
| Department with shared service calendars and several staff | Microsoft Bookings, or a different self-hosted tool | Bookings shares service calendars across staff within Microsoft 365. Cal.diy removed Teams features, so shared multi-staff scheduling is not its strength. |
| Team that must keep bookings inside its own network | Cal.diy, or confirm options with a self-hosted appointment tool | Cal.diy can run on your own servers, but Bookings runs in Microsoft's cloud. Confirm that Microsoft Graph integrations work in your environment before relying on them. |
| Production deployment with internal SLAs | Microsoft Bookings, or a supported commercial or self-hosted product | The README says self-hosting is at your own risk and directs commercial and enterprise users to Cal.com, so Cal.diy lacks vendor backing for SLA commitments. |
| Team without server administration skills | Microsoft Bookings, or a hosted Cal.com plan | The README requires advanced knowledge of server administration, database management and securing sensitive data. Hosted options shift that work to a vendor. |
| Evaluating self-hosted scheduling before a decision | Cal.diy, in a non-production environment | A test instance lets you check integrations, such as Google Calendar and Microsoft Graph, without exposing live bookings. |
Where bookings and invitee data live under each option
Microsoft Bookings keeps booking records inside the Microsoft 365 tenant and its scheduling mailboxes, while Cal.diy keeps them in a PostgreSQL database that your team operates. The cards below cover where that data sits, who signs in to reach it, and what compliance evidence you would need to produce for each option.
Tenant-held booking records
Bookings stores appointments, customer details and staff calendars inside your Microsoft 365 tenant, with each calendar backed by an Exchange scheduling mailbox. Your data residency position therefore depends on the tenant's region and on Microsoft's operational controls, which you review through Microsoft's contractual and compliance documentation rather than through a database you can inspect. Confirm which tenant region holds each mailbox before you map data flows.
Client-run PostgreSQL database
Cal.diy keeps event types, bookings and invitee names and emails in a PostgreSQL 13 or later database that your organization hosts. You decide the database location, backup schedule, encryption at rest and access list, so the data never leaves your boundary unless you send it there. The trade-off is that your team owns every one of those controls, and the README says self-hosting is at your own risk.
Hosting model and runtime responsibility
Bookings runs as a managed service with no servers for you to patch. Cal.diy runs as a Next.js application on Node.js 18 or later, usually from the published Docker image, and your team must handle patching, scaling, TLS and monitoring. Ask who will own each layer after go-live, and whether the platform team has the skills to run a Node.js service next to a database.
Entra ID sign-in versus local accounts
Bookings uses your Entra ID identities, so staff access follows existing sign-in policies, conditional access and joiner and leaver processes. Cal.diy uses its own local accounts, and the Enterprise-only SSO and SAML features are removed from the MIT-licensed fork. Plan how staff will be provisioned and deprovisioned without a central directory, or confirm with Cal.com whether a commercial edition fits your identity model.
Shared calendars and admin roles
Bookings lets a department share a service calendar across several staff members through its managed admin roles. Cal.diy removes the Teams and Organizations features, so each person typically keeps personal event types and connected calendars. Before you choose, list every department calendar that needs shared administration and test whether personal event types can cover it.
Compliance evidence and readiness work
Under Bookings, much of the evidence for the data layer comes from Microsoft's own assurance reports, which your compliance team requests and reviews. Under Cal.diy, your organization must produce the access reviews, backup restore tests, change records and hardening baselines itself. DeployOpen prepares those systems, controls and evidence for an assessment, but independent auditors issue any audit report or certification.
Why Cal.diy's removed team features matter for departments
Cal.diy removes the features that most department-level scheduling depends on. Its code is a fork of Cal.com with enterprise and commercial code taken out, and the fork drops Teams, Organizations, Insights, Workflows, SSO and SAML. For a single person managing personal event types, that may not matter. For a department that wants shared calendars, several staff members taking bookings from one public page, or a rule that spreads bookings across people, it does. Microsoft Bookings handles shared service calendars as a built-in part of the Microsoft 365 service, so teams moving to Cal.diy should not assume that the staffing pattern they use today carries across.
The Cal.diy README is explicit about who the fork is meant for. It says self-hosting is at your own risk, strictly recommended for personal, non-production use, and requires advanced knowledge of server administration, database management and securing sensitive data. It also directs commercial and enterprise scheduling users to Cal.com, and says enterprise on-premises access is handled through Cal.com sales. Read that as a boundary on what the fork is for, and raise the question with Cal.com before you plan a department rollout rather than after.
Before any decision, run a test instance and check each team workflow against the actual build. List the shared calendars, the number of staff who must share one booking page, how assignments are made, and which integrations (such as Microsoft Graph for Office 365) must write to each person's calendar. Confirm each item in your own environment and against the current Cal.diy repository, since the README is the authority on what the fork supports. Where a needed capability is missing, record it as a gap to fund, host elsewhere, or accept, and decide that with the department owners.
What each option costs to run
Bookings costs are folded into a Microsoft 365 plan, so the real decision is what you stop paying for and what you start operating. Cal.diy moves the cost into hosting, database operations and staff time, and those costs depend heavily on how many people administer the system and how much support you buy.
Microsoft 365 plan share
Bookings has no standalone license. Its cost is part of the Microsoft 365 plan your department already pays for, so the saving from leaving Bookings is only real if the plan is also reduced or the seats are used for other workloads. Ask finance which plan lines would change, whether any Exchange or Teams licensing would remain for mail and meetings, and whether Bookings is bundled in a way that makes its share hard to isolate. This cost is recurring and set by the plan, not by Bookings usage.
Server and container hosting
Cal.diy runs as a Node.js application with a Docker image published on Docker Hub, so you pay for compute, storage, networking and the load balancer or reverse proxy in front of it. This is recurring infrastructure, and it grows with the number of staff and booking pages rather than with a per-seat fee. Ask your platform team whether it will run on existing virtualization or cloud accounts, and what the monthly infrastructure line would be under your own rates.
PostgreSQL and backups
Cal.diy requires PostgreSQL 13 or later. Someone must size the database, run backups and test restores, and keep those backups inside your retention rules, because booking records contain invitee personal data. Backup tooling and storage are recurring costs, while the initial database build is one-time. Ask whether the quote includes restore tests, point-in-time recovery and an agreed recovery target.
Patching, TLS and credentials
The Cal.diy README places self-hosting at your own risk, so patching the application, its dependencies and the operating system falls to your team. You also manage TLS certificates and the credentials for Google Calendar, Microsoft Graph, Zoom and other integrations, including rotation when they expire. These tasks recur every month and are the main source of unplanned staff time. Ask who owns each task and how security updates are tested before production.
Staff time and external support
Staff time for administration is the largest cost that is easy to miss, and it recurs. External support, such as a retainer for upgrades, monitoring and security testing, is optional and priced per engagement, so you can buy it for the parts your team does not want to run. Ask for the expected monthly administration hours, the escalation path for outages, and whether the quote is fixed-scope or a retainer. DeployOpen issues quotes from written scope rather than a price list.
Hosted reference point
Cal.com's hosted pricing, as read in October 2026, lists Free for 1 user, Teams at $12 and Organizations at $28 per user per month on yearly billing. That per-seat model is the reference point for a hosted alternative, not a cost of Cal.diy. Compare it with your own infrastructure, database and staff estimate over the same period, and remember that Cal.diy omits Teams and Organizations features. Ask any vendor for a written quote covering the same users, integrations and support level.
What moving from Bookings to Cal.diy involves
The sequence turns Bookings' services, staff and booking pages into a Cal.diy instance on your own servers, with each feature checked before cutover. It ends with DNS moved and Bookings and its scheduling mailboxes retired.
Inventory Bookings services, staff and pages
Someone who administers the Bookings calendars lists every service, staff member, booking page and public link in use, along with each one's duration, buffer times, availability and confirmation or reminder emails. Record which Exchange scheduling mailbox sits behind each calendar. The step is done when the list has been reviewed by the department owner and every booking page has an owner who will approve its rebuild.
Confirm Cal.diy covers required features
Compare the inventory with the Cal.diy README and the features it documents, such as Google Calendar and Microsoft Graph (Office 365) calendar connections, Zoom, Daily.co and Webex video links, and the Settings and Integrations page. Note that Cal.diy removes Teams, Organizations, Workflows and SSO, so any requirement that depends on those, including multi-staff team scheduling or SMS reminders, must be marked as a gap or confirmed with the Cal.com sales team before you proceed. The step is done when each requirement is marked as covered, a gap or a decision to be made.
Stand up a non-production Cal.diy instance
An administrator with server, database and secrets handling experience deploys Cal.diy in a non-production environment using the Docker image on Docker Hub or a Node.js build, backed by PostgreSQL 13 or later and Node.js 18 or later. The README advises self-hosting at your own risk and strictly recommends it for personal, non-production use, so treat this instance as a test bed until your security review approves production use. The step is done when the application loads, an admin account signs in and the database backup has been tested.
Connect calendars and meeting providers
Connect the test instance to a pilot mailbox or calendar through Google Calendar or Microsoft Graph, then add the video provider the department uses from the Settings, Integrations page. Confirm that the connected calendar shows busy times and that new bookings write back to it. The step is done when a test booking appears on the pilot calendar and the chosen video link is generated.
Rebuild event types and booking pages
Recreate each Bookings service as a Cal.diy event type with matching length, availability, buffers and visibility, and build the booking pages that point to them. For each shared calendar, decide whether the page should offer individual personal event types or whether the department needs a feature Cal.diy does not provide. The step is done when every inventory item has a matching event type or a recorded gap, and the department owner has signed off on each page.
Test invitations and meeting links
Book from outside the organization and from inside it, then check the confirmation email, the calendar invitation, the time zone, the cancellation and reschedule links and the meeting URL. Repeat for each event type and each connected calendar. Compare the results with the messages customers receive today from Bookings, and fix any wording or link differences before cutover. The step is done when a written test log shows each event type passing without errors.
Decide what happens to historical bookings
Agree with the department whether past appointments must be kept for reporting, audit or customer service, and whether they will be exported from Bookings or left in place until retention ends. Migrating the history itself is covered on the export and migration pages, so this step only sets the decision and the owner. The step is done when the retention decision is recorded and the export method has been agreed.
Cut over DNS and retire Bookings
Point the public booking links at the Cal.diy instance, update any websites, email signatures and intranet pages that reference the old Bookings URL, and then disable the Bookings page for the department. Once the cutover is confirmed, remove the Exchange scheduling mailboxes and calendars that Bookings used, following your records retention rules. The step is done when the new links resolve, a live test booking completes and the retired mailboxes are removed or archived as approved.
Questions buyers ask before switching from Bookings to Cal.diy
Can Cal.diy be used in production for a department?
The Cal.diy README says self-hosting is at your own risk and strongly recommended for personal, non-production use. Treat that as the project's official position, not a technical verdict. Before a department relies on it for customer bookings, validate the deployment yourself: a tested backup and restore of the PostgreSQL database, a patching routine that follows the upstream releases, TLS and access control on the booking pages, a review of how invitee personal data is stored and retained, and a load and failure test on the booking flow. The README also notes that the work requires advanced knowledge of server administration, database management and securing sensitive data. If your team cannot meet those points, the README's own guidance points away from Cal.diy for production.
What cost and effort drivers apply when moving from Bookings?
Bookings has no standalone license, so its cost sits inside the Microsoft 365 plan, and that cost does not disappear until the plan changes. Cal.diy itself is MIT licensed, so the recurring costs are infrastructure, PostgreSQL hosting, backups, monitoring, staff time for upgrades, and any integration work. One-time costs include setup, rebuilding event types, connecting calendars, and testing. The main drivers are the number of calendars and staff, the number of integrations (Google Calendar, Microsoft Graph, Zoom, Webex and others), whether bookings must stay in your own boundary, and how much support you need after go-live. When requesting a quote, ask for each of these as a separate line item and for the assumptions behind them.
How long does a move from Bookings to Cal.diy take?
No timeline is fixed by the product, so the duration depends on your own scope. The main drivers are the number of event types and staff calendars to recreate, how many Microsoft 365 integrations must be reconnected and tested, whether you need historical bookings, and how many approvals your security and compliance reviews require. A small single-team setup is much shorter than a multi-department rollout with custom notifications. Agree on a written scope and milestones before work starts, and ask any implementation partner for its own timeline based on that scope.
What does the work need from our own staff?
Expect to need a named owner for the platform, someone who can administer a Linux server, manage PostgreSQL and maintain DNS, TLS and email delivery. Your identity and calendar administrators must approve the Microsoft Graph or Google connections and define who can see which calendars. Business owners need to review event types, availability rules, and the wording of invitee-facing messages. Plan time for testing with real users before cutover. These roles stay in place after go-live, because upgrades and backups are recurring work.
Can our team set up Cal.diy without outside help?
A team with solid Linux, container, database and identity skills can deploy Cal.diy from the published Docker image and the repository, and the README documents the Node.js and PostgreSQL requirements. The harder parts are integration with Microsoft 365 and Google calendars, security hardening, backup and restore testing, and keeping the fork current. If those skills are thin in-house, an implementation partner can plan, implement, harden and document the platform under a fixed-scope agreement, and offer ongoing support. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure. It does not issue audit reports or certifications.
Does Cal.diy support shared department calendars and team features?
No, not in the form Bookings offers. Cal.diy removes the Teams, Organizations, Insights, Workflows, SSO and SAML features that were Enterprise-only in Cal.com. Bookings' shared service calendars and multi-staff scheduling therefore have no direct equivalent in Cal.diy. Personal event types and individual calendar connections work, so a department can run one booking page per person or use separate accounts. If shared team scheduling is a hard requirement, check the current Cal.diy feature set against your needs before committing, and consider the hosted or enterprise options from Cal.com described below.
When should we choose Cal.com hosted or enterprise instead?
Choose Cal.com instead of Cal.diy when you need team scheduling, organization administration, SAML SSO or SCIM provisioning, or a supported commercial platform. Cal.com's hosted pricing, as read in October 2026, lists Free for 1 user, Teams at $12 and Organizations at $28 per user per month on yearly billing, with SAML SSO and SCIM on Organizations and US or EU hosting choices. Enterprise pricing is custom. Hosted Cal.com is a different trade-off: you pay per user but do not run the servers. The Cal.diy README directs commercial and enterprise scheduling users to Cal.com, and enterprise on-premises access is handled through Cal.com sales. Compare the per-user cost against the staff and risk cost of running Cal.diy yourself.
Confirm these points before you commit
Start with the staffing model, because it decides whether Cal.diy fits at all. Cal.diy removes the Teams, Organizations and Workflows features that Cal.com reserves for paid tiers, so a department that needs round-robin assignment across a pool of staff, shared service calendars or approval steps should test those exact flows on a staging instance before committing. Write down how your bookings are assigned today, then confirm each rule works in the version you plan to run. Calendar connections are worth the same scrutiny: check the Google Calendar and Microsoft Graph integrations against your tenant's mailbox and consent settings, not only against the README.
Next, be explicit about support and risk. The Cal.diy README states that self-hosting is at your own risk, is strictly recommended for personal, non-production use, and requires advanced knowledge of server administration, database management and securing sensitive data. If your department handles client or patient details, ask who will answer for a security incident and whether that person has the skills to patch Node.js, PostgreSQL 13 or later, and the application itself. If the answer is unclear, the README directs commercial and enterprise scheduling users to Cal.com, and a hosted or on-premises Cal.com arrangement is a fair comparison point to request in writing.
Then pin the release and the data location. The latest GitHub release of the calcom/cal.com repository is v6.2.0, published on March 1, 2026, according to the Cal.diy releases page. Record the exact tag you deploy, check the releases page again before go-live, and decide who will apply later updates. Confirm where calendars, invitee details and the PostgreSQL database must reside under your data residency rules, and whether backups must be encrypted and stored in the same jurisdiction. Finally, confirm that your team can own patching and tested backups on a regular schedule. If it cannot, the cost of that work belongs in your comparison, even though no licence fee is involved.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Microsoft Bookings vs Cal.diy, that means first deciding whether Cal.diy fits your departmental use case at all, then building and handing over only what the written scope covers.
How we scope
- Confirm which Bookings calendars, staff and booking pages the department actually uses today
- Check whether the use case is personal or non-production, the use Cal.diy's README recommends
- Agree in writing whether a commercial Cal.com plan or a different platform is the better fit
How we build
- Deploy Cal.diy with Node.js 18 or later and PostgreSQL 13 or later inside your environment
- Connect calendar sync for Google Calendar or Microsoft Graph (Office 365) from the Settings, Integrations page
- Test booking flows, reminders and access controls against the scope before any user goes live
How we hand over
- Document the deployment, server administration tasks, database backups and calendar integration settings
- Record which Teams, Workflows and SSO features are absent and how staff should work around them
- Provide a runbook for updates, so your team can track releases such as the March 2026 v6.2.0 release
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review new Cal.diy releases and plan upgrades on a schedule your team agrees in advance
- Keep an explicit boundary, so retainer work covers only the systems named in the written scope
