> 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.md). # Move from the old routers Recreate form routers, outbound routers, and click routers in Distro 3.0. Recreate your existing routing journeys with Distro 3.0 workflows, queues, routing profiles, and rulebooks. Start with one router and verify its complete journey before replacing the rest. ## Choose your migration


Form Router	Rebuild website capture, qualification and scheduling.	Move a Form Router	distro3-form.webp
Outbound Router	Recreate seller inputs and SDR-to-AE handoffs.	Move an Outbound Router	distro3-queue.webp
Click Router	Plan campaign links, identity and ownership routing.	Move a Click Router	distro3-tracker.webp
Migration checklist	Check publication, source cutover and the whole journey.	Migration checklist	distro3-migration.webp

## What changes The old router bundled capture, routing, distribution, scheduling, and outcome settings. In Distro 3.0 you configure those parts separately and connect them in a workflow. | Previous configuration | Distro 3.0 configuration | | -------------------------------- | ------------------------------------------------------------------------------ | | Router canvas | Workflow canvas. | | Form Submission | New form submission trigger and saved form connection. | | Ownership Rules | CRM matching plus rulebook owner rules, or scheduler CRM record owner. | | Distribution Rules | Rulebook or Branch for eligibility, plus queues and profiles for distribution. | | Fallback team / selected members | Queue membership, weights, and fallback host or rule. | | Strict round robin | Pre-picked member, or explicit assignment followed by Earlier assignee. | | Flexible distribution | Any available member with scheduling directly from the queue. | | Display Scheduler | Show Scheduler with the event type and host source. | | Booking confirmation | Scheduler confirmation and booked redirect settings. | | Unqualified redirect | Branch or rulebook Else leading to Redirect. | | After routing actions | Explicit steps after the routing outcome. | | After booking actions | Steps on Show Scheduler's Booked outcome. | | Router versions | Workflow versions plus the form or connection's selected active version. | | Routing Logs | Workflow Logs, rulebook Logs, and queue Assignment/Usage logs. | | Rule credits | Queue calibration, counted turns, and profile refund settings. | The same queue can be used by several workflows. Decide whether that should also mean shared rotation history. ## Preserve the behavior, not only the shape Document your current rule order, fallback, host selection timing, event types, CRM writes, and messages before rebuilding. Explicit assignment selects a member immediately. Flexible scheduling selects the host for the time booked. Recreating both with the same Assign from Queue step would change the visitor's experience. A matched rule's old event-type override becomes an explicit workflow path with the appropriate Show Scheduler event. ## Links and history need separate review These are setup guides for rebuilding the journey. They do not promise an automatic import of old versions, assignment history, existing sessions, or link credentials. Confirm the transition plan with Distro support if you need historical fairness, active meetings, old URLs, or in-flight sessions preserved. Do not enable two capture integrations for the same form. Follow the [checklist](/migrate/checklist.md) to switch one source deliberately. --- # 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.md?ask=&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.