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

# Migration checklist

Use this checklist for each router you replace. Finish the source switch and controlled acceptance test before calling the migration complete.

## Record the current behavior

* [ ] Router name, published version, entry URLs, embeds, and website destinations.
* [ ] Form questions, field mappings, defaults, and required values.
* [ ] CRM objects, owner mappings, rule order, and qualification conditions.
* [ ] Receiving teams, selected members, weights, counts, and credits.
* [ ] Strict/flexible distribution and availability exclusions.
* [ ] Default event type, rule-specific event overrides, and attendees.
* [ ] Confirmation, unqualified, no-availability, and no-booking behavior.
* [ ] CRM writes, meeting activities, notifications, and reminders.
* [ ] Booker access, link expiry, reusable links, and offered-time capabilities.

## Prepare the new resources

* [ ] Connect host calendars, CRM identities, and required providers.
* [ ] Create routing profiles with the intended work units, rotation, times, and refunds.
* [ ] Create queues with the correct roster and weights.
* [ ] Decide which flows share a queue and its rotation history.
* [ ] Create and publish rulebooks where needed.
* [ ] Prepare event types, co-hosts, booking questions, and messages.
* [ ] Agree on any required history, fairness, URL, or active-session preservation with Distro support.

## Build and simulate

* [ ] Choose the correct trigger and declare or refresh its fields.
* [ ] Recreate owner matching and qualified new-lead distribution.
* [ ] Connect missing-data, No match, unassigned, Else, and Error paths.
* [ ] Keep flexible host selection at booking time where required.
* [ ] Put CRM owner writes and meeting actions at the intended stage.
* [ ] Validate and simulate representative success and failure cases.
* [ ] Confirm access and provider dependencies in the actual workspace.

## Publish and activate

* [ ] Publish the workflow and turn it On.
* [ ] Confirm workspace enrollment and execution are available.
* [ ] For native forms, select the intended published workflow version and publish the form.
* [ ] For external forms, activate the compatible connection version.
* [ ] For extension or API journeys, confirm the caller and complete scheduling handoff.
* [ ] Install the new capture or replace the campaign destination.
* [ ] Ensure one integration owns each website form.
* [ ] Review old in-flight requests and links before retiring the old source.

## Run controlled acceptance tests

| Case                            | Verify                                                                 |
| ------------------------------- | ---------------------------------------------------------------------- |
| Existing CRM owner              | Correct record, mapped member, and fallback if unusable.               |
| New qualified lead              | Intended pool, event, and host selection timing.                       |
| Disqualified or incomplete lead | Clear follow-up or redirect.                                           |
| Paused or unavailable member    | Profile rules and fallback behave as intended.                         |
| Booking succeeds                | Calendar event, conferencing, attendees, CRM activity, and messages.   |
| Visitor does not book           | Intended Not booked action.                                            |
| Original form fails             | New workflow does not start through the confirmed-success integration. |
| Duplicate delivery              | Same event is not treated as a second unrelated journey.               |
| External action is uncertain    | Inspect and reconcile before repeating it.                             |
| Personalized campaign           | Distinct recipient identity and isolated session.                      |

## Review after the switch

* [ ] New events appear in the intended workflow Logs.
* [ ] Queue Usage log and Assignment log reflect the new flow.
* [ ] Bookings and CRM records match the expected results.
* [ ] No duplicate capture, owner writes, activities, or notifications.
* [ ] Sellers and support know which links and logs to use.
* [ ] Old campaign templates and website snippets have been reviewed.

Keep your previous settings record and a written rollback plan. A rollback must switch the source deliberately; it does not undo completed CRM actions, messages, or bookings.


---

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