Migrate from Calendly to Cal.diy

Migrate from Calendly to Cal.diy: what the move involves

Moving personal booking pages from Calendly to self-hosted Cal.diy is a realistic project for one person's event types and calendar connections, but team routing, SSO and workflows are not available in Cal.diy at all, because the fork removes Teams, Organizations, Workflows, SSO and SAML from Cal.com. Most organizations that take this path do so because of a Calendly renewal, a per-seat pricing change or a data residency requirement that the hosted service cannot meet, and the work is usually done by an internal administrator with server skills or by an implementation partner they hire for the installation. Expect the effort to be concentrated in the hosting, not in the booking pages themselves.

The core work is rebuilding each event type (duration, buffers, locations and questions), recreating weekly availability, connecting the Google Calendar or Microsoft 365 calendar from the Settings, Integrations page, and adding Zoom if meetings should carry video links. Cal.diy needs Node.js 18 or later and PostgreSQL 13 or later, so the server, database backups, TLS and secret handling all become your responsibility. Before cutover, confirm with your Microsoft 365 or Google administrator that the OAuth consent and calendar permissions Cal.diy requests are allowed in your tenant, and test a booking end to end on a staging domain.

The Cal.diy README is direct about the risk: self-hosting is at your own risk, it is strictly recommended for personal, non-production use, and it requires advanced knowledge of server administration, database management and securing sensitive data. If your booking pages collect personal data from customers or must serve a team, treat the fork as a stopgap, and plan for Cal.com's hosted pricing or an alternative such as Easy!Appointments before you decommission Calendly. Confirm the current release with the Cal.diy releases page before you pin a version.

Which Calendly capabilities map to Cal.diy and which need rework

This table maps the Calendly capabilities most personal users rely on to their Cal.diy equivalents and labels each as clean, needs rework or gap. Read the rows as a checklist before cutover, and confirm each item in your own instance because Cal.diy is a self-hosted, non-production fork.

Calendly capability	Cal.diy equivalent	Status
Event types (one-to-one booking links)	Event types created in the dashboard with duration, location and booking link settings	Clean: rebuild each event type by hand
Weekly availability and date overrides	Availability schedules attached to each event type	Clean: confirm time zone and buffer settings
Google Calendar connection	Google Calendar integration added from Settings, Integrations	Needs rework: create your own Google API credentials and test two-way busy checks
Microsoft 365 or Outlook calendar	Microsoft Graph (Office 365) integration from Settings, Integrations	Needs rework: register your own app in Microsoft Entra and grant consent
Zoom meeting links	Zoom integration from Settings, Integrations	Needs rework: create Zoom app credentials and verify links on test bookings
Invitee questions and confirmation emails	Custom booking questions per event type, with default email notifications	Needs rework: rewrite question text and check that invitee data stays on your server
Reminders and follow-up sequences	Basic notifications only; Workflows were removed as Enterprise-only	Gap: rebuild reminders outside Cal.diy or with a workflow tool
Website embeds and booking links	Public booking page URL and embed snippets on your own domain	Needs rework: replace every Calendly link and embed after DNS and TLS are live
Team scheduling, round robin and routing forms	Teams, Organizations and routing were removed from Cal.diy	Gap: move to Cal.com Teams or Organizations, or to another tool
Insights, SSO and SAML	Insights and SSO were removed from Cal.diy	Gap: use Cal.com for commercial or enterprise scheduling, which the README directs to Cal.com

Migration sequence from inventory to Calendly shutdown

This sequence moves personal booking pages from Calendly to a self-hosted Cal.diy instance in controlled stages, so each event type, availability rule and calendar connection is verified before any public link changes. The output is a Calendly account that no longer receives bookings and a documented Cal.diy setup your team can operate.

Inventory event types, availability and live links
Before touching anything, list every event type in Calendly with its duration, location, buffers, questions and reminders. Record each availability schedule, each connected calendar (Google or Microsoft 365), each Zoom link, and every place a Calendly URL appears, such as email signatures, websites, job postings and recurring invitations. Ask the account owner to export meeting history from Calendly's reports so past bookings are kept outside the tool. The step is done when you have one inventory document that a second person has reviewed and that lists every live link.
Stand up a non-production Cal.diy pilot
Deploy Cal.diy on a test host you control, using the Docker image published on Docker Hub or a Node.js build, backed by PostgreSQL 13 or later and Node.js 18 or later. Because the project's README describes self-hosting as at your own risk and recommends it for personal, non-production use, keep the pilot off any address your invitees use and restrict access to the people running the test. Confirm the version you deploy against the latest release listed on the project's GitHub releases page, which was v6.2.0 when this was written. The step is done when the instance loads, creates an account and survives a restart.
Rebuild event types and availability
In the pilot, recreate each event type from the inventory with the same name, duration, location and booking questions, then set the weekly availability, time zone, date overrides and buffers. Keep event slugs identical where possible so that future links remain predictable. Have the owner of each calendar compare the slots shown in Cal.diy against their Calendly page for the same two weeks. The step is done when every event type produces the same bookable slots as its Calendly counterpart, with any gap recorded as an open item.
Connect Google, Microsoft 365 and Zoom in Settings
In Cal.diy, open Settings and then Integrations, and connect Google Calendar, Microsoft Graph for Office 365 and Zoom using accounts the owner controls. Each provider requires its own OAuth client or app registration, so the people who hold those credentials must be involved from this point. Check that busy times from each connected calendar block slots, that new bookings write events to the right calendar, and that Zoom meeting links are generated on confirmation. The step is done when a test booking creates a calendar event and a Zoom link in each connected account.
Run a parallel period with both tools live
For a defined window agreed by the team, keep Calendly active and point a small group of internal users at the Cal.diy pages. Compare bookings, cancellations, reschedules and reminder emails across both tools, and log any difference in time zone handling, invitee fields or calendar blocking. Keep Calendly's exports current during this period. The step is done when the team has reviewed the comparison log and every difference is either fixed in Cal.diy or accepted in writing by the owner.
Replace links and cut over
Update the Calendly links in email signatures, the website, documents, calendar invitations and any automation, using the inventory as the checklist. Where the Calendly URL is embedded in other systems, change those references as well. Leave a redirect or a notice on the old Calendly page for a period the owner approves. The step is done when a search of the inventory shows no remaining Calendly links that receive new bookings and the owner confirms the new links in writing.
Decommission Calendly and archive records
Once no new bookings arrive through Calendly, disconnect its calendar integrations, revoke its access to Google, Microsoft and Zoom, and remove team members from the account. Store the exported meeting history, the inventory and the comparison log in the organization's records system, and confirm with the account owner that the subscription has been cancelled. Record which Calendly plan and seat count were in use, so the cancellation is documented. The step is done when the subscription is cancelled, the integrations are revoked and the archive is filed where your retention policy requires.

Which data and integrations to move and rebuild by hand

Calendly does not hand over a complete, ready-to-import account, so the move is split between data you export and records you rebuild. Each card below covers one piece of that split, from meeting history to the OAuth connections that must be registered in your own cloud accounts.

Meeting history from CSV reports

Calendly's meeting reports can be exported as CSV from the Calendar page, filtered by date and event. Use these files as your archive of past meetings, since Cal.diy does not import Calendly history. Check which fields you need before you export, because the file does not contain every field you may want to keep, and confirm the export covers the date range your retention policy requires.

Invitee fields the CSV carries

The meeting export includes invitee names, emails, event names and any answers collected by booking questions, along with UTM parameters and payment fields where they apply. Treat this file as personal data. Decide who may open it, where it is stored, and how long it is kept before you copy it to your new server.

API v2 and webhooks for scheduling data

Calendly's API v2 and webhooks expose scheduling and contact data programmatically, which is useful when you need records the CSV does not cover or want a continuous feed during cutover. Assign a developer to the export, confirm which endpoints your plan allows, and keep the extracted data in your own storage rather than in a script on a personal laptop.

Calendar credentials to recreate

Google Calendar and Microsoft 365 connections are not transferred with your data. Each user must reconnect their calendar on the new Cal.diy server, which means the existing grants tied to Calendly will not carry over. Plan a short window in which each user signs in and confirms that busy times are read correctly.

Integrations added from Settings

Cal.diy's README documents integrations for Google Calendar, Microsoft Graph (Office 365), Zoom, Daily.co, Webex, HubSpot, Zoho and Pipedrive. Each is added from the Settings, Integrations page of the instance. Confirm the exact integration list in the release you deploy, since availability can change between versions.

OAuth apps in your own accounts

The Google Calendar, Microsoft Graph, Zoom and CRM integrations depend on OAuth applications registered in your own Google Cloud, Microsoft Entra, Zoom and vendor accounts, with your own redirect URLs pointing at your Cal.diy domain. Assign ownership of these registrations, store client secrets in your secrets manager, and check consent scopes against what your security team has approved.

How Cal.diy, its database and calendar APIs fit together

Cal.diy is a single application built with Next.js, tRPC, React, Tailwind CSS and Prisma, and it stores its state in a PostgreSQL database that the operator must provide. The repository requires Node.js 18 or later and PostgreSQL 13 or later, and the project publishes a Docker image on Docker Hub, so a typical deployment runs the container next to a PostgreSQL instance inside your own network. Before you write any configuration, confirm the exact image tag you intend to run against the v6.2.0 release published on March 1, 2026, and check that the PostgreSQL version in your environment meets the stated minimum of 13.

Event types, availability rules, bookings, invitee names, emails, answers to booking questions and the link between each booking and its host all sit in the PostgreSQL database. Calendar and conferencing connections add a second class of data: when you connect Google Calendar, Microsoft Graph for Office 365 or Zoom from the Settings, Integrations page, the application stores OAuth tokens that let it read free and busy time and create events on the user's behalf. These tokens are as sensitive as passwords, because anyone who reads them can act on the connected calendars, so the database backups, the environment file holding the encryption and secret values, and the container host all need the same access control as the rest of your identity data.

Plan the operator side before the first booking page goes live. Decide who can reach the database host, how backups are encrypted and where they are kept, and how the application is served over HTTPS. Set up a separate OAuth client for each provider in your own Google Cloud or Microsoft Entra tenant so that you control consent and can revoke access. The Cal.diy README says self-hosting is at your own risk and requires advanced knowledge of server administration, database management and securing sensitive data, so confirm that someone on your team owns patching, backups and token rotation before you move any customer-facing link.

What usually goes wrong in a Calendly to Cal.diy move

Most failed booking migrations break at the edges: links that still point to Calendly, availability that shifts by an hour, and calendar connections that quietly stop syncing. The cards below cover the failure points we see most often, each with a check to run before cutover, plus the Enterprise-only features Cal.diy does not provide.

Broken booking links on websites

Calendly links live in website buttons, email signatures, LinkedIn profiles, proposals and recurring invitations, and most of them are not in one place. When the Calendly account is closed, those links stop working and invitees hit a dead page. Build an inventory by searching your website, marketing templates and mail signature tools for calendly.com before cutover. Keep the old account active with a redirect notice for a period you agree internally, and confirm each new Cal.diy link opens the correct event type on a clean browser profile.

Time zone and daylight saving errors

Availability re-created by hand often uses the wrong time zone on the host profile or on individual event types, and a rule set in local time can shift by an hour when clocks change. The result is bookings offered at 8:00 when you meant 9:00, which is hard to spot until someone misses a meeting. Test each event type by booking it from at least two time zones, including dates just before and after a daylight saving transition in your region. Compare the slots shown with your own calendar view.

Calendar connections lapsing

Google Calendar and Microsoft Graph connections depend on OAuth credentials you create and maintain, and on consent that an administrator or user can revoke. When a connection lapses, Cal.diy may keep offering slots that are already taken on the external calendar. Confirm which account owns each connection, check the Settings, Integrations page after the first week, and set a recurring reminder to review the OAuth client configuration in your Google Cloud or Microsoft Entra tenant. Ask the team to confirm a new booking blocks the expected calendar entry.

Double bookings during parallel running

Running Calendly and Cal.diy side by side is useful for testing, but both tools can offer the same free time to different invitees. A slot booked in one system may not block the other, which produces double bookings. Pick a cutover date, disable Calendly event types for the same host on that date, and keep a single shared calendar of bookings during the overlap. Remove any link to the old page from your booking flow before the first live day in Cal.diy.

Missing invitee reminders

Calendly sends confirmation and reminder emails through workflows and notification settings that you may have tuned over years. Cal.diy does not provide the Workflows feature that Calendly users often rely on, so reminders can stop without any visible error. List every reminder and confirmation your invitees currently receive, then decide which ones you will rebuild, which will move to a calendar invitation, and which you will drop. Send a test booking to an external address and confirm the message arrives outside spam filters.

Team routing and SSO gaps

Round-robin routing, collective event types, team-wide admin controls and SAML or SCIM provisioning belong to features that Cal.diy has removed because they were Enterprise-only in Cal.com. If your Calendly setup depends on any of them, a personal Cal.diy instance cannot replace them. Document each team routing rule and login requirement before you start. Then decide whether to keep Calendly for those workflows, move to Cal.com's hosted plans, or ask Cal.com sales about on-premises access, and confirm the chosen path in writing before you retire the Calendly team.

How the move differs for solo users, small groups and regulated teams

A single person with a few event types usually has the simplest move. Cal.diy covers personal booking pages: you define event types, set weekly availability, connect a calendar, and share a link. Because the README recommends the fork for personal, non-production use, a solo user who accepts that position can run it on a small server they administer.

Event types: Rebuild each Calendly event type by name, duration and location, then test one booking end to end.
Calendar connection: Connect Google Calendar or Microsoft 365 from the Settings, Integrations page and confirm that busy times block correctly.
Video links: Add Zoom or another conferencing integration only if you use it, and confirm the link appears in invitations.
Link replacement: Update email signatures, website buttons and LinkedIn profiles, and keep the old Calendly link active for a short overlap period.
Upkeep: You become the administrator for updates, database backups and certificates, which Calendly previously handled for you.

Before cutting over, confirm with the Cal.diy README that self-hosting for your use case fits its stated scope, and decide who will apply updates.

What drives the cost and duration of the migration

This table lists the factors that change how much work a move from Calendly to self-hosted Cal.diy takes and what it costs to run afterward. Read each row as a question to answer in your own environment before asking a partner or internal team for a scope.

Driver	Why it changes cost or effort	How to keep it down or what to ask for
Event types and availability rules	Each event type needs its duration, buffers, notice periods, questions and host availability rebuilt by hand, so effort grows with the count of active types.	Export and prune unused event types first. Ask the written scope to list each event type to be recreated and who verifies its availability.
Connected calendars	Every Google or Microsoft 365 calendar that checks conflicts needs its own account connection and consent, and shared or delegated calendars add review time.	Inventory which calendars block availability. Ask for the list of accounts to connect and whether shared calendars are in scope.
Conferencing accounts	Zoom and other video integrations each need an authorized account, and each one must be tested with a real booking to confirm the meeting link is created.	Confirm which conferencing accounts hosts actually use. Ask whether testing covers one booking per integration.
Live links to replace	Booking URLs in email signatures, websites, job postings and partner documents must be found and swapped, and old Calendly links need a redirect or notice plan.	Count published links from web analytics and sent email. Ask whether the scope includes a link inventory and a cutover date agreed with the business.
OAuth app registration in your tenants	Google and Microsoft integrations usually need an OAuth client registered in your own cloud tenant, with redirect URLs, consent settings and secrets managed by your administrators.	Ask who holds the Google Cloud and Microsoft Entra administrator roles. Confirm the approval path before work starts, since tenant policies can delay it.
Server hardening and backups	Cal.diy requires Node.js 18 or later and PostgreSQL 13 or later, and its README says it needs advanced server administration and secure handling of sensitive data. Hardening, TLS, patching and tested database backups are work that continues after launch.	Ask for the hardening baseline, backup schedule and restore test in the scope. Decide who owns patching of the Node.js and PostgreSQL runtime.
Who performs the work	An internal engineer costs salary time and carries knowledge risk. A partner costs a fixed-scope fee and a retainer for later support, upgrades and testing.	Compare internal hours against a written fixed scope. Ask whether handover documentation and a runbook are included.
Recurring operating costs	Hosting, database storage, backups, monitoring, email delivery for notifications and staff time for upgrades recur every year. Cal.diy's README ties upgrades to the main repository, where the latest release listed is v6.2.0 from March 1, 2026.	Ask for a monthly estimate of hosting and support hours, and for an upgrade plan that names who reviews each new release before it goes live.

Questions buyers ask before moving from Calendly to Cal.diy

Does Cal.diy cover team scheduling and routing?

No, not in the form Calendly sells it. Cal.diy removes Teams, Organizations, Insights, Workflows and SSO and SAML, which were Enterprise-only features in Cal.com. It works well for personal booking pages with event types, availability and calendar connections. If you need round-robin or collective team events, routing forms or workflow automation, the Cal.diy README directs commercial and enterprise scheduling users to Cal.com, where those features sit in the hosted plans or in the enterprise on-premises option sold by Cal.com sales. Compare the feature list in the Cal.com pricing page against your Calendly plan before you decide which edition fits.

Is Cal.diy safe to run in production?

The Cal.diy README does not recommend it for production. It describes self-hosting as at your own risk and strictly recommended for personal, non-production use. It also says self-hosting requires advanced knowledge of server administration, database management and securing sensitive data. If a booking page carries client, patient or executive invitee data that your business depends on, treat Cal.diy as a candidate for a trial or a personal workload, or choose a commercially supported edition of Cal.com. Make that call with your security and risk owners before cutover.

How long does moving from Calendly to Cal.diy take?

The duration depends on how many event types, calendars and integrations you have, and on whether anyone is available to test them. Recreating a few personal event types with availability and calendar connections is a short task for one administrator. Adding a production-grade deployment, backups, monitoring, email delivery and a rehearsed cutover of booking links takes longer. No timeline is set by the product itself, so ask for a written schedule from any implementation partner based on your inventory, and confirm the Cal.diy release you plan to deploy against the Cal.diy releases page.

What does the work need from our team?

Plan for four inputs: a host for the Cal.diy application, a PostgreSQL 13 or later database, Node.js 18 or later for a source build or the published Docker image, and someone who can manage DNS, TLS and email for booking notifications. You also need credentials for Google Calendar, Microsoft Graph for Office 365 and Zoom, created in each provider's console and tied to your domain. Confirm exact configuration steps in the README, since integrations are added from the Settings, Integrations page after the app is running.

Can an internal admin set up Cal.diy without outside help?

A capable internal administrator with Linux, Docker, database and identity provider experience can usually deploy a personal instance without outside help. The harder part is ongoing ownership: patching, backups, restore tests, upgrades and handling provider credential expiry. If nobody on your team has run a web application with a database in production, bring in a partner for the initial build and handover. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under a written, fixed scope, and offers retainers for ongoing support.

How do we export our data from Calendly?

Start with the meeting CSV reports filtered from Calendly's Calendar page, which include invitee, event, UTM and payment fields. Those files capture meeting history but do not carry over event types, availability rules or calendar connections, so you will rebuild those in Cal.diy by hand. For bulk or structured data, Calendly offers API v2 and webhooks for scheduling and contact data. Confirm with Calendly which fields and records the export covers, and keep a dated copy of exports before you cancel, since access ends with the subscription.

What happens to SSO if we move to Cal.diy?

Single sign-on is not available in Cal.diy. The edition removes SSO and SAML, which Cal.com provides on its Organizations plan with SCIM. Users sign in with local accounts or the sign-in methods the release supports, so plan account creation and offboarding as a manual or scripted process. If central identity control is a requirement, the practical options are the Cal.com Organizations tier or a different self-hosted scheduler, and that decision should come before you start the migration. Check current sign-in options against the README for the release you deploy.

How DeployOpen scopes and runs a Cal.diy migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a Calendly move to Cal.diy, that work usually means agreeing who hosts the application, where the PostgreSQL 13 or later database lives, how the Node.js 18 or later service is deployed from the Docker image, and how backups and restore tests are handled. Before any work starts, the written scope should name the Google Workspace or Microsoft 365 tenants, the Zoom account, the domain for booking links and the number of personal booking pages being moved. Decisions about the server, the database and the OAuth applications for calendar access belong to the client's own administrators, and we document them as part of the handover.

Most engagements are fixed-scope. The written scope, deliverables and timelines are agreed before work begins, and the quote follows from that scope. DeployOpen does not publish a price list, so the reader should ask for a quote built from the components above: infrastructure set-up, calendar and Zoom connection, rebuilding event types and availability, testing bookings end to end, cutover of links and documentation. Each item should show who does the work and what the client must provide, such as tenant admin consent and a named owner for the cutover date. Ask the vendor to separate one-time costs from recurring ones, and say which items are excluded, such as team routing or SSO, which Cal.diy does not provide and which the scope should treat as a decision rather than a build task.

After cutover, the recurring work is upgrades, security patches, backups and monitoring of the calendar integrations. DeployOpen offers these as optional retainers, which can cover upgrades and support for the deployed Cal.diy instance and continuous testing of the booking flow. Whether a retainer is needed depends on how much internal capacity the organization has to run a Node.js and PostgreSQL service. The Cal.diy README itself says self-hosting is at your own risk and is strictly recommended for personal, non-production use, so the reader should confirm with their own risk and compliance owners whether a personal booking deployment is acceptable, and agree the support model in writing before the scope is signed.

Migrate from Calendly to Cal.diy