> 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/default.md).

# Migrate from Default

Rebuild Default queues, policies, forms, and workflows in Distro.

Default and Distro use familiar building blocks: workflows, queues, reusable routing behavior, and meeting events. Recreate the configuration and verify each path before moving its traffic.

This guide uses the naming in [Default OS documentation](https://docs.os.default.com/). If you use Default v1, inventory the actual settings in your workspace; labels and form installation may differ.

## Find the Distro equivalent

| In Default                                      | Set up in Distro                                                            |
| ----------------------------------------------- | --------------------------------------------------------------------------- |
| Queues                                          | Queues with members, weights, status, and calibration.                      |
| Routing Policies                                | Routing profiles.                                                           |
| Rules of Engagement                             | Published rulebooks and Apply Rulebook.                                     |
| Round-Robin node                                | Assign from Queue.                                                          |
| Display Scheduler                               | Show Scheduler.                                                             |
| Events                                          | Event types.                                                                |
| Forms and Pixel capture                         | Lead forms or connected external forms; review website tracking separately. |
| Tables                                          | People and company Records.                                                 |
| Enrich Data and Waterfalls                      | Enrich Lead and enrichment chains.                                          |
| Deep Research                                   | Web Research with a connected provider.                                     |
| Multi-Branch / Run Experiment                   | Branch / Split Traffic.                                                     |
| Time Delay / Create Variable / Date Transformer | Wait / Set Variables / Shift Date.                                          |

Use Default's [node reference](https://docs.os.default.com/workflows/node-reference.md) to list the steps you need, then check the [Distro step reference](/workflows/step-reference.md) for the available action and its setup.

## Rebuild in dependency order

{% stepper %}
{% step %}

### Reconnect the workspace

Invite members and reconnect calendars, conferencing, CRM identities, and action providers. Credentials and member mappings belong to the new workspace.

Review [Feature availability](/get-started/availability.md) before planning a live run. An available editor does not establish that execution is enabled.
{% endstep %}

{% step %}

### Recreate routing resources

Translate [Default policies](https://docs.os.default.com/policies.md) into [routing profiles](/routing/profiles.md). Review Records versus Meetings, single-host versus pooled times, rotation, weights, exclusions, resets, and refunds explicitly.

Create queues next, followed by rulebooks. Preserve rule order and declared inputs. Use CRM Match steps to supply owner fields before Apply Rulebook.

Check **Resolved**, **Else**, and fallback behavior rather than assuming every Rules of Engagement edge has identical semantics. In Distro, a rulebook that selects a queue also selects a member; do not add a second assignment to the same path.
{% endstep %}

{% step %}

### Recreate events and workflows

Prepare event types before adding Show Scheduler. Map each trigger and step using Distro's own fields and outputs; rebuild references to the new queues, rulebooks, events, and CRM connections.

Put CRM writes and notifications at the same business stage as the previous flow. A booked-meeting action belongs on **Booked**; a qualification rejection needs its own path.
{% endstep %}
{% endstepper %}

## Move form capture deliberately

Keep the existing website form where possible and [connect it to Distro](/forms/existing-forms.md). Review the selector or provider callback, answer types, exact approved origins, and the scheduler interaction mode.

Install the Distro SDK using the new connection's instructions. Activate its compatible published workflow version separately from saving the connection. The Default Pixel configuration is not a Distro form connection.

Rebuild visitor-identification and consent settings separately if the previous Pixel also supplied website intent. See [Website tracking](/forms/website-tracking.md).

## Review before switching

Queue counts, calibration, run history, records, and active scheduler sessions need individual handling. A [CSV import](/records/import-csv.md) can bring supported record fields into Records; it does not restore a Default workspace or workflow graph.

Validate and simulate each branch, then make a controlled live test through the actual source. Confirm the host, CRM owner, booked meeting, follow-up, and external provider results.

Use the [source switch checklist](/migrate-to-distro.md#switch-one-source-at-a-time). Replace Default embeds, extension entry points, API calls, and campaign destinations only after the corresponding Distro journey passes.


---

# 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/default.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.
