Skip to main content
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 is a short list intended for distribution to the wider team.

​
How the migration works

1

Default provisions the new workspace

The organization, its users, and their routing and scheduling settings are loaded before anyone signs in. The previous workspace continues to operate unchanged.
2

Accounts are created in advance

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.
3

The previous workspace stays live

Routing, scheduling, and automation continue to run there. Administrators can sign in to the new workspace and complete the setup below in parallel.
4

Users sign in and complete their own setup

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 for the full invite flow and Single Sign-On 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 for the full provider list, and 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

1

Publish a test page on its own hostname

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.
2

Register the test hostname as its own domain

On the Domains tab, select Add new Domain for the test hostname. It receives its own Pixel key and snippet, separate from production.
3

Install the snippet and run the connection test

Add that domain’s snippet to the <head> 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.
4

Submit the form and confirm all four signals

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

1

Register each 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.
2

Deploy the new snippet

Select Copy Pixel script and provide it to whoever maintains the site. It replaces the existing snippet rather than running alongside it.
3

Confirm the Connected status

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.
4

Review detected forms

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 for installation detail and field mapping.

​
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 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 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 reports the same condition per queue member.

​
What works differently

​
Where functionality moved

​
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

Routing activity

A filterable, searchable activity log, plus assignment resets on a monthly, quarterly, or manual cadence.

Run logs

Every workflow execution: the version that ran, the record processed, and the path taken.

Multiple triggers

A single workflow can start from several triggers, removing the need to duplicate it per entry point.

Multi-host meetings

Meetings support more than one host, with a record of host changes.

Meeting messages

Reminders and messages configured per event, for hosts and attendees.

Single sign-on

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.