Skip to main content
A Default workspace migration moves the configuration of an existing Default workspace into a new one. This guide is for the administrators who complete it. Default’s migration team transfers your existing configuration: users, working hours, queues, booking links, and workflows. Authorization granted per user or per company does not transfer. Calendar access, integration credentials, and website tracking belong to your accounts, not to the workspace. You re-establish each one after the migration completes. This guide covers administrator tasks. Member setup is a short list you can send to the wider team.

​
How the migration works

1

Default provisions the new workspace

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

Accounts are created in advance

Default creates an account for every user as part of the migration. It sends no invitations, 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 sign in to the new workspace and complete the setup below in parallel.
4

Users sign in and complete their own setup

When the workspace is ready, each user connects a calendar. Each user also 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. Default ports workflows 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, not from a backlog routed to whichever member sorts first. Default also creates accounts without invitation emails. You control when to tell the team to sign in.

​
What does not transfer

The following items do not transfer. This guide covers how to re-establish each one below.
  • Passwords. The new workspace authenticates through single sign-on or a one-time code sent by email.
  • 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. You register each domain again.
  • Personal booking links. Shared and team events transfer. The migration excludes single-host personal events by default.
  • Named booking links. Individual shareable links generated from an event, each with its own custom URL, expiry, or tracking parameters, do not transfer. The underlying events do, so regenerate the links from them.
  • Meeting history. Past meetings do not migrate. Export anything you need for reporting while the previous workspace is still live.
  • Pending invitations. Only users who accepted an invitation transfer. Send a new invitation to anyone still pending.
  • Cross-system references inside workflows. Re-select Slack channels, sequences, events, and queues in the workflow builder.
  • Published state on workflows. Migrated workflows arrive as drafts.
The new workspace recreates records with new URLs, and no redirect exists. Bookmarks, links shared in Slack, and record links stored in CRM notes all 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. The identifier in front of it does not match, so the old link still fails.
Set the identifier early, before anyone shares a new link. Open Settings, select Branding, then set Workspace Identifier under Workspace Details. Until you set it, booking URLs fall back to an internal ID. Calendar invites also leave out reschedule and cancel links.

​
Administrator setup

Complete steps 2 and 3 in order, because user mapping requires a connected integration. Complete the remaining steps in any order.

​
1. Sign in and reconcile the user list

Passwords do not transfer. Initial sign-in uses single sign-on or a one-time code sent by email. 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 select Set up SSO to create the connection. There is no directory sync, so membership changes remain manual. Next, open Users under Workspace Settings. 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 Owner, Admin, Editor, 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 Connections under Workspace Settings. The page groups providers by category: CRM, Sequencing, Notifications, Enrichment, Website Intent, Calendar, and Conferencing. Open a provider. 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. You connect conferencing once for the workspace, not per user.
  • Slack, if workflows post notifications.
  • Any sequencing platform in use: Outreach, Salesloft, Gong Engage, Apollo.io (Sequencing), Amplemarket, or Smartlead.
Default manages Enrichment providers, so they do not require an API key. Website Intent providers are available at an additional cost. Speak to the Default CS team to learn more. You cannot delegate this step. Members and viewers see only calendar and conferencing providers on the Connections page. Only administrators see all other providers.
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, because you set up the connection from scratch.
See Connections 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 a connection mapping. Without it, a workflow cannot assign the correct owner or notify the correct recipient. When you connect Salesforce, HubSpot, Zoom, Salesloft, Slack, or Apollo.io (Sequencing), Default maps users automatically by email address. Default also reports the number of users it matched. Verify that count against headcount. A user whose Default email differs from their address in the connected system does not match and requires manual mapping. Default never maps Outreach, Amplemarket, Gong Engage, and Smartlead automatically. Configure these mappings by hand. To review or complete mappings, open Settings, select Users, then open the Mappings tab. The tab shows a consolidated grid. To map an individual, open their row and select Connections.
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.Unrelated fields on the same step then also fail to save. Check mappings first when a workflow appears to be only partially working.

​
4. Reinstall the Pixel and add your forms again

Begin this step early. It is the only task that requires a change to the website, which is outside the administrator’s control. The new workspace issues its own Pixel key. The snippet currently deployed points at the previous workspace and reports nothing. Pixel setup lives in Settings → Domains, under Workspace Settings. You need admin access. Replacing the snippet on a live site is a cutover. From the moment the new snippet goes live until you add every form in the new workspace, Default does not record submissions from the forms it does not know yet. Rehearse the sequence on a test page first. Then repeat it on the production domain, knowing what to expect.
Give every form a stable HTML id before you deploy the Pixel. Default uses a matching form ID to select the saved form for workflow routing. Field names never select a saved form. If no ID matches, Default records the submission without a saved-form ID or workflow only when all fields of at least one active saved form are present and that form accepts submissions on the page. Extra submitted fields are allowed. Otherwise, the submission is not recorded.
Submission attribution keeps only utm_source, utm_medium, utm_campaign, utm_term, and utm_content from utmParams. Other keys in that object are ignored, not used as submission fields. They do not cause the submission to be rejected.

​
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, field names, and field types.A form that differs from production tests something you are not shipping.Keep the page out of search results. Also keep these words out of its path.The Pixel skips any path containing /login, /signin, /account, /checkout, /oauth, or /admin/. It skips them without reporting anything.
2

Register the test hostname as its own domain

In Settings → Domains, select Add domain and enter the test hostname. Default matches each page to the most specific domain you added, so the test page’s forms stay separate from production.
3

Install the snippet

On the domain’s page, check Connect your domain. If a CNAME record is provided and the connection is not already Record connected, add its exact values at your DNS provider, then select Check status to set up and verify the custom connection. If it stays pending, allow time for DNS propagation and check again; correct any mismatch and select Check again. Wait for Record connected before testing the custom-host snippet.If custom hosting is unavailable and no record is provided, skip the DNS setup; the snippet loads from Default’s CDN. Select Copy under Add the snippet to your site and add the snippet to the <head> of the test page. Your workspace has 1 Pixel key. Copy the snippet from each domain’s page so its loading hostname matches that connection.
4

Add the form and map its fields

In Forms, select Create new, then Catalog forms for the test domain. Add the form on the page, then map its fields to Person and Company fields. See Your Forms.
5

Submit the form and confirm all 3 signals

Load the page. Submit the form once, with values you recognize later.Then confirm all 3 signals:
  • The test domain shows Live in Settings → Domains.
  • The form appears in Forms with the fields on your page.
  • The values you submitted land on the fields you mapped.
Anything short of all 3 is a finding worth resolving before the site changes.
To check routing as well, point a workflow at the test form with the Form Submission trigger. This writes to live systems, as step 5 describes, 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.Default identifies a form on your domain by its HTML id, not by its fields. A copy of your real form on the production domain, with the same id, is the same form to Default, so test submissions land on the real form and start its workflows.

​
Cut over the production domain

1

Register each domain

In Settings → Domains, select Add domain for every tracked site. A domain also covers its subdomains, so acme.com covers try.acme.com. Add a subdomain separately only when you want it tracked as its own entry.
2

Deploy the new snippet

On each domain’s page, check Connect your domain. If a CNAME record is provided and the connection is not already Record connected, add its exact values at your DNS provider, then select Check status to set up and verify the custom connection. If it stays pending, allow time for DNS propagation and check again; correct any mismatch and select Check again. Wait for Record connected before deploying the custom-host snippet.If custom hosting is unavailable and no record is provided, skip the DNS setup; the snippet loads from Default’s CDN. Select Copy under Add the snippet to your site and provide the script to whoever maintains the site. It replaces the existing snippet rather than running alongside it.
3

Add and map each form

In Forms, select Create new, then Catalog forms for each domain. Add every form on the pages where it lives, then map its fields.Forms belong to the domain they were added on. The mapping from the test page does not carry over, so repeat it here.
4

Confirm the Live status

A domain shows Live once Default receives traffic from it or it has a form in Default. Until then, a domain with a custom connection shows Waiting for DNS while its CNAME record is pending and Ready once it verifies. A domain without one shows Add snippet.
Keep the test domain registered after go-live. It gives you a place to verify the next form change before it reaches production. To stop tracking the test domain, open its detail page and select Delete Domain under Danger Zone. Confirm with Delete domain. See Domains for domains and the install snippet, and Your Forms for adding forms and mapping fields.

​
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 to verify 3 items:
  • Cross-system references. Slack channels, sequences, events, and queues are workspace specific, so re-select them. A step that references nothing does not run.
  • Publish. Select Publish to promote the current draft to the live version.
  • Go live. A migrated workflow starts paused, and publishing does not change that. After you publish, turn on the deployment switch so the status reads Live.
The workflow list shows a Draft, Paused, or Active badge on each card. The badges give 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 you test at scale.

​
Member setup

Every member completes 2 tasks after their first sign-in. An administrator cannot do either task, because both authorize access to that member’s own accounts.
  1. Connect a calendar. Open Settings, then Connections, and connect either Google Calendar or Outlook Calendar. Until then, Default cannot book the member 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 under Event Types in the sidebar.
First and last names, profile pictures, and working hours transferred. 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 also 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. Confirm coverage rather than assume it. Routing that books meetings excludes any member without a connected calendar. Default raises no error and does not notify the member. Workflows still assign records to the member, so the member continues to receive work. The gap goes unnoticed until someone asks why the member stopped getting meetings. Open Settings, then Users. Review these columns: 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. Default still captures UTM values, but no configuration surface exists for mapping them to fields.
  • 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.
Last modified on October 29, 2026