> For the complete documentation index, see [llms.txt](https://docs.distro.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.distro.so/migrate-to-distro/cal-com.md).

# Migrate from Cal.com

Move Cal.com events, routing forms, embeds, and meeting messages to Distro.

Start with your most-used event. Recreate its hosts, availability, questions, and messages in Distro, then test the complete booking before replacing its link or embed.

## Find the Distro equivalent

| In Cal.com                       | Set up in Distro                                                          |
| -------------------------------- | ------------------------------------------------------------------------- |
| Individual event type            | Solo event with a member as primary host.                                 |
| Round-robin team event           | Queue-hosted event with a routing profile.                                |
| Collective event                 | Shared event with the required co-hosts.                                  |
| Routing form                     | Lead form or connected external form, a workflow, and routing conditions. |
| Availability schedules           | Working hours, named sets, event availability, and calendar checks.       |
| Booking questions                | Event questions; use pre-scheduling form fields for qualification.        |
| Reminder and follow-up workflows | Event messages/reminders or a meeting lifecycle workflow.                 |
| Booking links and embeds         | Distro booking links or the new form installation.                        |

Cal.com's guides describe [routing forms](https://cal.com/blog/unlock-the-power-of-routing-forms-for-your-team-or-organization) and [team event types](https://cal.com/blog/cal-com-s-team-appointment-types-exploring-collective-round-robin-and-managed-eve). The Distro column is a suggested setup, not an automatic conversion.

## Rebuild a booking event

{% stepper %}
{% step %}

### Connect calendars and set availability

Invite the hosts and reconnect their calendar and conferencing accounts. Review conflict calendars, time zones, working hours, and time off.

Follow [Calendars and availability](/scheduling/availability.md). Check date-specific availability separately instead of assuming every Cal.com schedule override has transferred.
{% endstep %}

{% step %}

### Configure the event and hosts

Create an [event type](/scheduling/event-types.md) with the same intended duration, location, questions, notice, and buffers.

For round robin, create a queue and profile. **Any available member** offers pooled eligible times; **Pre-picked member** offers one selected host's times. Select the behavior that matches your current booking experience.

For collective scheduling, make the event shared and add **Required co-hosts**. Required attendees restrict the offered times to shared availability. Optional co-hosts are invited without restricting those times.
{% endstep %}

{% step %}

### Recreate messages and verify a booking

Configure [meeting messages](/scheduling/messages.md) and [reminders](/scheduling/reminders.md). Check recipients, timing, and conferencing details.

Create the intended [booking link](/scheduling/booking-links.md) and run a controlled booking. Confirm the actual calendar event, conference link, required attendees, and messages.
{% endstep %}
{% endstepper %}

## Rebuild a routing form

Create a lead form or [connect the existing form](/forms/existing-forms.md). Start a **New form submission** workflow and map the fields used for qualification.

Use Branch for a few simple paths or a [rulebook](/routing/rulebooks.md) for reusable ordered rules. Send qualified visitors to Show Scheduler with the appropriate event; send unqualified visitors to an explicit destination or follow-up.

If a rulebook selected the host, choose **Earlier assignee** in Show Scheduler. To keep host selection flexible until a slot is booked, schedule directly from the queue.

## Review features that need a separate decision

Managed-event permissions, payments, recurring bookings, booking approval, and self-hosting are separate requirements. This guide does not establish matching Distro support for them. Check any feature you rely on with Distro support before switching that journey.

Cal.com API calls, webhook payloads, and embed attributes must be rewritten against the Distro interfaces. Use [API authentication](/developers/authentication.md) and [Form SDK](/forms/sdk.md) for the new integration.

## Switch links after acceptance

Test a busy host, a required co-host conflict, time zones, qualification outcomes, cancellation, and rescheduling. Confirm which platform still manages already-booked meetings.

Replace website embeds, email signatures, and campaign links using the [source switch checklist](/migrate-to-distro.md#switch-one-source-at-a-time). Existing Cal.com URLs and management links need their own transition plan.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.distro.so/migrate-to-distro/cal-com.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.