> ## Documentation Index > Fetch the complete documentation index at: https://docs.os.default.com/llms.txt > Use this file to discover all available pages before exploring further. # Migrating your workspace > What Default migrates into your new DefaultOS workspace, what your team re-establishes, and what differs from the previous product. This guide is for administrators migrating an existing Default workspace to a new one. Default's migration team transfers your existing configuration: users, working hours, queues, booking links, and workflows. What cannot transfer is authorization granted per user or per company. Calendar access, integration credentials, and website tracking are issued to your accounts rather than to the workspace, so each must be re-established once the migration completes. Administrator tasks are covered below. [Member setup](#member-setup) is a short list intended for distribution to the wider team. ## How the migration works The organization, its users, and their routing and scheduling settings are loaded before anyone signs in. The previous workspace continues to operate unchanged. An account is created for every user as part of the migration. No invitations are sent, so no one is notified before you choose to notify them. Routing, scheduling, and automation continue to run there. Administrators can sign in to the new workspace and complete the setup below in parallel. Once the workspace is ready, each user connects a calendar and recreates any personal booking link. Your Default team confirms the go-live date directly. ## What Default migrates The following transfers with the workspace. None of it requires rebuilding. * **Organization and branding**, including logo and workspace colors. * **User records**, with first and last names and profile pictures. * **Working hours** for every member, so availability is accurate from day one. * **Queues and queue membership**, together with their assignment history. * **Shared and team events**, their booking form questions, and their hosts. * **Workflows**, including their steps and branching logic. Workflows are ported on a separate track from the rest of the migration, so your Default team confirms when they land. Assignment history is the detail most worth knowing about. It transfers with the queues, so round robin resumes from its existing position rather than routing a backlog to whichever member happens to sort first. Accounts are also created without invitation emails, so you control when the team is told to sign in. ## What does not transfer The following must be re-established. Each is covered below. * **Passwords.** The new workspace authenticates through single sign-on or a magic link. * **Calendar connections.** Each user reconnects their own Google or Outlook calendar. * **Workspace integrations.** Salesforce, HubSpot, Slack, Gong Engage, Salesloft, Outreach, Apollo.io, Amplemarket, Smartlead, and Zoom all require reconnection. * **The Pixel.** The new workspace issues its own Pixel key and snippet, and each domain is registered again. * **Personal booking links.** Shared and team events transfer. Single-host personal events are excluded by default. * **Named booking links.** Individual shareable links generated from an event, each with its own custom URL, expiry, or tracking parameters, are not carried over. The underlying events are, so regenerate the links from them. * **Meeting history.** Past meetings are not migrated. Export anything required for reporting before the previous workspace is retired. * **Pending invitations.** Only users who accepted an invitation transfer. Anyone still pending must be invited again. * **Cross-system references inside workflows.** Slack channels, sequences, events, and queues are re-selected in the workflow builder. * **Published state on workflows.** Migrated workflows arrive as drafts. Records are recreated in the new workspace with new URLs, and no redirect exists. Bookmarks, links shared in Slack, and record links stored in CRM notes all resolve against the previous workspace and will break. Plan to reshare any link the team depends on. Previously shared booking URLs break as well, for a separate reason. Every booking URL includes your workspace identifier, and a new workspace starts without one. Events transfer and keep their existing slug, so the end of a booking URL often matches the old address, but the identifier in front of it does not, so the old link still fails. Set the identifier early, before anyone shares a new link. Open **Settings**, select **Branding**, then set **Workspace Identifier**. Until it is set, booking URLs fall back to an internal ID, and reschedule and cancel links are left out of calendar invites. ## Administrator setup Steps 2 and 3 are sequential: an integration must be connected before users can be mapped to it. The remaining steps can be completed in any order. ### 1. Sign in and reconcile the user list Passwords do not transfer. Initial sign-in uses single sign-on or a magic link. To authenticate through an identity provider, open **Settings**, then select **Single Sign-On (SSO)** under **Workspace Settings**. Select **Add domain** to verify the domain, then **Set up SSO** to create the connection. There is no directory sync, so membership changes remain manual. Next, open **Users** under **Workspace Settings** and reconcile the list against the previous workspace. Users whose invitations were still pending did not transfer, so select **Invite People** to add them. When a CRM is connected, **Add from Salesforce** and **Add from HubSpot** import the user list directly. Roles are **Admin**, **Member**, and **Viewer**. A role change takes effect at that user's next sign-in, not immediately. See [Users](/settings/users) for the full invite flow and [Single Sign-On](/settings/enterprise) for domain verification. ### 2. Reconnect workspace integrations Open **Settings**, then select **Integrations** under **Workspace Settings**. Providers are grouped by category: **CRM**, **Sequencing**, **Notifications**, **Enrichment**, **Website Intent**, **Calendar**, and **Conferencing**. Open a provider and select **Connect**. An administrator connects the following once for the entire workspace: * A CRM, either **Salesforce** or **HubSpot**. Connect this first, as user mapping in step 3 depends on it. * **Zoom**, so booked meetings include a conferencing link. Conferencing is connected once for the workspace rather than per user. * **Slack**, if workflows post notifications. * Any sequencing platform in use: **Outreach**, **Salesloft**, **Gong Engage**, **Apollo.io (Sequencing)**, **Amplemarket**, or **Smartlead**. **Enrichment** providers are managed by Default and do not require an API key. **Website Intent** providers are available at an additional cost. Speak to the Default CS team to learn more. This step cannot be delegated. Members and viewers see only calendar and conferencing providers on the **Integrations** page. All others are restricted to administrators. Connect Salesforce through a dedicated integration user rather than a named individual's login. A connection tied to a personal account fails when that person changes roles or leaves. A migration is the natural point to correct this, since the connection is being established from scratch. See [Integrations](/settings/integrations) for the full provider list, and [Salesforce](/settings/integrations/salesforce) for the managed package setup. ### 3. Map users to connected integrations Default resolves each member to their corresponding Salesforce user, HubSpot owner, or Slack account through an integration mapping. Without it, a workflow cannot assign the correct owner or notify the correct recipient. Connecting **Salesforce**, **HubSpot**, **Zoom**, **Salesloft**, **Slack**, or **Apollo.io (Sequencing)** maps users automatically by email address and reports the number matched. Verify that count against headcount. Any user whose Default email differs from their address in the connected system will not match and requires manual mapping. **Outreach**, **Amplemarket**, **Gong Engage**, and **Smartlead** are never mapped automatically and must be configured by hand. To review or complete mappings, open **Settings**, select **Users**, then open the **Mappings** tab for a consolidated grid. To map an individual, open their row and select **Integrations**. An unmapped user fails silently, and the failure extends beyond that user. When a workflow writes an owner value the CRM does not recognize, the CRM rejects the entire update, so unrelated fields on the same step also fail to save. Check mappings first when a workflow appears to be only partially working. ### 4. Reinstall the Pixel and re-approve forms Begin this step early. It is the only task with a dependency outside the administrator's control, as it requires a change to the website. The new workspace issues its own Pixel key, so the snippet currently deployed points at the previous workspace and reports nothing. Open **Settings**, select **Data Model** under **Workspace Settings**, then open **Pixel**. Replacing the snippet on a live site is a cutover, not a test. From the moment the new snippet goes live until every form has been approved and mapped, real submissions are arriving against forms Default has not yet been told the shape of. Rehearse the sequence on a test page first, then repeat it on the production domain knowing what to expect. Assign every form a stable HTML `id` before deploying the Pixel. A form without one is detected in the browser but rejected on the server, a common condition on Framer, Webflow, and Carrd. Fix this before building the test page, so the test page matches what you will ship. #### Rehearse on a test page Use a separate hostname, such as `pixel-test.acme.com`, or a preview URL from your site host. Copy the real form onto it unchanged: the same HTML `id`, the same field names, and the same field types. A form that differs from production tests something you are not shipping. Keep the page out of search results, and keep these words out of its path. The Pixel skips any path containing `/login`, `/signin`, `/account`, `/checkout`, `/oauth`, or `/admin/`, and it skips them without reporting anything. On the **Domains** tab, select **Add new Domain** for the test hostname. It receives its own Pixel key and snippet, separate from production. Add that domain's snippet to the `` of the test page, then run the connection test on the domain in Default. It reports the snippet, the script, and a test event in sequence, so a failure tells you which of the three to look at. Load the page and submit the form once, using values you will recognize later. Then confirm that the domain reports **Connected**, the form appears on the **Forms** tab, its detected fields match the form you built, and the values you submitted land on the fields you mapped. Anything short of all four is a finding worth resolving before the site changes. To check routing as well, point a workflow at the test form using the **Form Submission** trigger. Be aware that this writes to live systems, as described in step 5, so use records you are willing to create. Host the test page on its own hostname. Do not put it on a path of your production domain. Forms are deduplicated per domain by their field structure, so a copy of your real form on the production domain claims the entry the real form needs, and deleting the copy does not release it. #### Cut over the production domain On the **Domains** tab, select **Add new Domain** for every tracked site. Subdomains are registered separately, so `acme.com` and `try.acme.com` are two entries. Select **Copy Pixel script** and provide it to whoever maintains the site. It replaces the existing snippet rather than running alongside it. A domain reports **Connected** only once the Pixel has received a form from that site. This is the definitive confirmation that the installation succeeded, rather than that the script loaded. On a low-traffic page, load it yourself instead of waiting for a visitor. Forms appear on the **Forms** tab as the Pixel identifies them. Approve each one and map its fields. Forms belong to the domain they were seen on, so the mapping done on the test page does not carry over and is repeated here. If a duplicate appears for review, edit the existing form rather than approving the new entry. Keep the test domain registered after go-live. It gives you somewhere to verify the next change to a form before it reaches production. To stop tracking it, open the domain's menu and select **Remove**. See [Pixel](/settings/pixel) for installation detail and field mapping. {/* TODO screenshot: connection test on a domain, showing the snippet / script / test event sequence */} ### 5. Review and publish workflows Migrated workflows arrive as drafts. A draft does not process live traffic, so nothing executes until this step is complete. Open each workflow and verify three items: * **Cross-system references.** Slack channels, sequences, events, and queues are workspace specific and must be re-selected. A step that references nothing will not run. * **Publish.** Select **Publish** to promote the current draft to the live version. * **Enabled.** The **Enabled** switch remains off until a workflow has been published at least once. Publishing alone does not activate it, so enable the switch as well. The workflow list displays a **Draft**, **Paused**, or **Active** badge on each card, giving a quick view of what remains outstanding. **Test** executes against live systems, not a sandbox. It creates and updates real CRM records and sends real messages and webhooks. Review [Workflows](/workflows) before testing at scale. ## Member setup Every member completes two tasks after their first sign-in. Neither can be done by an administrator, because both authorize access to that individual's own accounts. 1. **Connect a calendar.** Open **Settings**, then **Integrations**, and connect either Google Calendar or Outlook Calendar. Until this is done, the member cannot be booked for meetings. 2. **Recreate personal booking links.** Shared and team events transferred with the migration. Personal single-host events did not, so members who used one rebuild it in **Scheduling**. First and last names, profile pictures, and working hours transferred, so members can skip those parts of [Member onboarding](/member-onboarding) and use the rest as reference. Display name, job title, and phone number did not transfer, so ask members to fill those in on their profile. A phone number is also what turns on the SMS notification channel. ## Verify calendar coverage before go-live Calendar connections are the one part of the migration that depends entirely on individual users, so confirm coverage rather than assuming it. A member without a connected calendar is excluded from any routing that books a meeting. No error is raised and the member is not notified. Records assigned by workflows are unaffected, so the member continues to receive work and the gap goes unnoticed until someone asks why they have stopped getting meetings. Open **Settings**, then **Users**. The **Calendar** column shows **No calendar** for anyone without a connection. **Integrations** and **Conferencing** show missing tooling, and **Status** shows **Active**, **Inactive**, or **Pending**. [Queues](/queues) reports the same condition per queue member. ## What works differently ### Where functionality moved | Previous workspace | Current location | Change | | ----------------------------------- | --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Forms | **Workflows** | A form and its automation were a single object. They are now separate: a **Workflow**, and the **Trigger** that starts it. A workflow can have multiple triggers. | | Queues | **Routing** app, **Queues** tab | Relocated without change. | | Routing rules configured on a queue | **Routing** app, **Policies** tab | Distribution and tiebreaker rules moved out of the queue into a reusable **Policy** that queues reference, allowing one policy to drive many queues. | | Events and Meetings | **Scheduling** app | Consolidated under a single app. | | Personal events | **Quick event** | Renamed. A single fixed member hosts. | | Global and group events | **Team event** | Two previous types consolidated into one. Group events retain their hosts as named users or queues rather than a hidden internal queue. | | Field manager | **Settings**, then **Data Model**, then **Objects** | Renamed and restructured. The workspace is provisioned with a set of default field mappings. | | Queue seeding | Assignment credits | Pinning the next assignment is no longer supported. Adjust a member's credits to influence distribution instead. | ### Not available today * Custom domains for booking links. * Tags, and lead or lifecycle stage management. * UTM field mapping. UTM values are still captured, but no configuration surface exists for mapping them to fields. * The Chrome extension. * The available, away, and paused selector on a queue member's row. Use out of office, or set the member inactive on the queue. * The separate "My meetings" and "Booked by me" views. The Meetings page is a single list segmented by status, so filter by host instead. ## What's new A filterable, searchable activity log, plus assignment resets on a monthly, quarterly, or manual cadence. Every workflow execution: the version that ran, the record processed, and the path taken. A single workflow can start from several triggers, removing the need to duplicate it per entry point. Meetings support more than one host, with a record of host changes. Reminders and messages configured per event, for hosts and attendees. Domain verification and authentication through your identity provider. ## Get help Direct questions about migration scheduling to your Default team in the shared Slack channel. For product questions, see [Support](/support).