Slack Workspace Migration: What to Do Before, During, and After the Move

The Migration No One Plans For (Until It's Urgent)

Picture this: your company has just acquired a promising startup - or two companies have merged to build something greater than the sum of their parts. The deal is signed, leadership is excited, and everyone is talking about “one unified team.” Then someone opens their laptop and asks the question nobody planned for: what do we do about Slack?

Your 300-person team is in one Slack workspace. The newly acquired company’s 80 employees are in another. Everyone needs to collaborate - but they’re in completely separate digital environments, with different channels, bots, integrations, workflows, and years of institutional knowledge locked inside each workspace. You now have two Slack workspaces for your employees, and consolidating them just became your next big operational challenge.

In this guide, we focus specifically on migrating one Slack workspace to another Slack workspace - the most common scenario teams face after an acquisition, a company merger, or a long-overdue consolidation of workspaces that grew without a plan. If you need to combine Slack workspaces, preserve your Slack message history, or move Slack data from one workspace to another without breaking integrations, this step-by-step guide is for you.

What looks like a simple move quickly turns into broken integrations, confused teams, and disconnected external partners. Slack workspace migrations are not technically hard. They are operationally hard. This guide gives you the plan.

What "Slack Workspace Migration" Actually Means

Slack workspace migration covers three distinct operations. Confusing them is the most common planning mistake.

1. Workspace-to-workspace import Export data from one standalone workspace and import it into another. Works on Free, Pro, and Business+ plans using Slack's Import & Export tools. You control what moves and how users are mapped.

2. Migration into an Enterprise Grid organization A platform-level move - not a copy. The entire workspace including members, history, channels, apps, emoji, and DMs is promoted into an Enterprise Grid org. Workspace URLs redirect automatically. See Slack's official Enterprise migration guide.

3. Moving channels within an Enterprise org Once inside a Grid org, Org Owners can move individual channels between workspaces - including message history, threads, pinned items, and emoji reactions - without a full migration. See how channel moves work.

One constraint that derails most plans: Slack does not support direct imports into Enterprise organizations. If your destination is a Grid org, you must import into a standalone workspace first, then migrate that workspace into the org. Plan for two steps, not one.

How to Choose the Right Destination Workspace

This decision shapes everything downstream. Make it deliberately - not by default.

Signal	What to Look For
Daily active users	Where work actually happens, not just where people are members
Channel and message activity	Pull analytics from both workspaces before deciding
Integration depth	The workspace with more apps, workflows, and Salesforce connections wins
Governance infrastructure	SSO configured? SCIM active? Retention policies set? That is your destination
Workspace URL	Embedded in bookmarks, SSO configs, and partner communications - harder to change than history
Admin access	The Primary Owner must be reachable. For Enterprise migrations, their approval is required to proceed

The general rule: export from the smaller or less active workspace, import into the larger more active one. But member count alone is misleading - integration depth and governance readiness matter more.

Not sure which workspace should be your destination? Talk to our migration team - we audit both workspaces and make the call with you, not for you.

How to Handle the Migration

Step 1: Audit Before You Touch Anything

Run a full inventory first - every channel (public, private, archived, Slack Connect), every installed app and bot, every Workflow Builder automation, every webhook and API connection, every guest and external member.

Export a Channel Audit Report from Workspace Settings → Security → Import & Export. This CSV gives you every channel with membership and activity data. Use it to decide what migrates, what gets archived, and what gets retired.

Step 2: Map Your Users

Email address is the matching key. Here is how Slack handles each user type by default:

• Matching email in destination → accounts merged automatically

• Active user, no email match → messages imported, no active account created

• Deactivated user, no email match → imported as deactivated

• Guest users → must be imported as deactivated full members, then manually reactivated as guests post-import

• External Slack Connect users → cannot be imported

  
  

Run a full email audit across both workspaces before you begin. Post-acquisition scenarios are especially prone to domain mismatches. Unresolved mismatches create duplicate accounts and orphaned message history.

Step 3: Decide What to Move

• Same-named public channels → default to merging with existing channels in the destination

• Unique-named public channels → default to creating new channels

• Private channels → cannot merge with existing private or Slack Connect channels; a new private channel is created

• Archived channels → default to "Don't import." If imported, they arrive as active channels and must be manually re-archived

• DMs → available on Business+ (with Slack's approval) and Enterprise Grid only

  
  

Archive anything with no meaningful activity in the past 90 days. A bloated channel list after migration kills adoption.

Step 4: Validate After Cutover

Keep the origin workspace active for at least two weeks. Before you decommission it, confirm:

• Message history intact across key channels

• Apps and bots functioning correctly

• Automations firing as expected

• Salesforce and CRM integrations connected

• Slack Connect channels accessible to the right members

Rebuilding Integrations After Migration

This is where migrations fail silently. Everything looks fine in Slack. External systems have quietly stopped talking to it.

Workflow Builder automations do not migrate automatically in workspace-to-workspace imports. Document every workflow - trigger, steps, connected apps, target channels - and rebuild in the destination. Test before cutover, not after.

Webhooks are workspace-scoped. Every external system posting to Slack - monitoring alerts, CI/CD pipelines, ticketing systems, CRM updates - has a webhook URL tied to a specific workspace. After migration, those URLs break. Generate new webhooks in the destination and update every external system before cutover.

Salesforce and Agentforce need a dedicated audit. For Enterprise Grid migrations, Salesforce features including Salesforce channels, Agentforce, and Sales Home move to the Enterprise org - but configurations do not always survive intact. Before migration, audit:

• Apex and Flow automations posting to Slack via webhook

• Agentforce agent configurations referencing specific channels

• Sales Home and Salesforce channel setups

• Salesforce for Slack app installation level - workspace vs. org

  
  

Custom apps face a user ID problem. After an Enterprise Grid migration, user IDs change from local workspace IDs to global org IDs. Any custom app storing Slack user IDs needs to use Slack's migration.exchange API post-migration. Skip this and user-specific automations break without any visible error.

Slack Connect Channels: Handle Separately

Slack Connect is your external relationship layer. It behaves differently from internal channels in every migration scenario.

During a workspace-to-workspace import: External Slack Connect members cannot be imported. Their messages come across in the export, but the live connection is not preserved. The channel arrives in the destination as a new private channel - without the external partner.

During an Enterprise Grid migration: Slack Connect conversations go temporarily inaccessible during the migration window. After migration, those channels become org-wide multi-workspace channels and inherit the org's privacy setting. That privacy change is easy to miss and can expose channels to a wider internal audience than intended.

Before migration day:

1. Inventory every active Slack Connect channel and DM

2. Identify the external contact responsible for each connection

3. Notify external partners of your migration timeline in advance - if a channel goes dark without warning, they will not know why

4. Plan for re-invitation: Slack Connect connections may need to be re-established post-migration

5. Review privacy settings for every Connect channel becoming a multi-workspace channel

   
   

External partners will not receive a Slackbot notification about your internal migration. That communication is yours to send.

Onboarding Users Into the Main Workspace

The technical migration takes hours. The human side takes weeks.

Communicate 2–4 weeks early. Post in #general and send a direct email - not everyone reads Slack announcements. Explain what is changing, when, and what users need to do (often nothing, but say that explicitly).

Answer the obvious questions before they are asked:

• Will my messages still be there?

• Will my channels look different?

• Do I need to log in differently?

• Where do I find channels I used to use?

• 
  

Build a channel guide. Two teams with different naming conventions merging into one workspace creates immediate confusion. A Slack Canvas or pinned document mapping channels by function - what to use for what, who to contact for what - saves hours of repeated questions in week one.

Staff a #migration-help channel for two weeks. Volume is highest in the first 48 hours. Respond fast. How well you support users in this window determines whether they trust the new environment or find workarounds.

Track adoption at 30, 60, and 90 days. Low engagement in specific channels or teams signals onboarding gaps. Catch them early before disengagement becomes the norm.

What Your Slack Plan Supports

Your plan determines what is possible. Full details are in Slack's plans and features documentation.

Capability	Free	Pro	Business+	Enterprise Grid
Export public channels	✅	✅	✅	✅
Export private channels + DMs	❌	❌	✅ With approval	✅
Workspace-to-workspace import	✅	✅	✅	❌ Not as a destination
Migrate into Enterprise org	As origin	As origin	As origin	✅ Org Owner initiates
Move channels between workspaces	❌	❌	❌	✅
SSO required	❌	❌	Optional	✅ Mandatory
Slack Connect	❌	✅	✅	✅
Discovery API / eDiscovery	❌	❌	❌	✅
Audit Logs API	❌	❌	❌	✅

Three things to know before you plan:

1. Business+ private export is not instant. It requires a formal application from the workspace Primary Owner, reviewed by Slack. Build 1–5 business days into your timeline.

2. Free plan file history is capped at 90 days. File links older than 90 days will not be accessible in the export.

3. Enterprise Grid requires SSO before migration can proceed. This is a hard prerequisite - not a recommendation. If SSO is not yet configured, add it to your pre-migration timeline.

Migration Readiness Checklist

Work through this before you schedule any migration date.

Discovery & Planning

• Identified migration type - workspace import, Enterprise org migration, or channel move

• Chosen destination workspace with documented rationale

• Exported Channel Audit Report from both workspaces

• Completed email and user mapping audit including domain mismatches and guest accounts

  
  

Integrations

• Inventoried all apps, bots, and Workflow Builder automations

• Listed all webhooks and every external system using them

• Audited Salesforce, Agentforce, and CRM integrations

• Identified custom apps storing Slack user IDs

  
  

Data

• Exported audit logs from origin workspace before Enterprise migration

• Made channel-level decisions: migrate, archive, or retire

• Confirmed DM import plan and verified plan eligibility

  
  

People & Communication

• Inventoried all Slack Connect channels and identified external partner contacts

• Notified external Slack Connect partners of migration timeline

• Drafted user announcement - email and in-Slack

• Built channel guide and one-page FAQ

• Assigned internal migration champions per team

  
  

Security & Access

• SSO configured and tested in destination

• SAML auto-provisioning disabled in IDP before migration window

• Guest account reactivation plan confirmed

  
  

Post-Migration

• Two-week parallel running period scheduled before decommissioning origin

• Post-migration validation review booked

• #migration-help channel coverage planned for first two weeks

Frequently Asked Questions

1. Can I merge two Slack workspaces without losing message history? 

   Yes - on Free, Pro, or Business+ plans. Using Slack's Import & Export tools, you export channels, members, and messages from the origin and import them into the destination. Message history is preserved for users whose email addresses match. On Business+ or Enterprise Grid, private channel and DM history can also be included.

   
   

2. What is the difference between a Slack workspace merge and an Enterprise Grid migration? 

   A workspace merge moves data between two standalone workspaces using import/export tools. An Enterprise Grid migration promotes an entire workspace into a Grid organization at the platform level. Slack does not support direct imports into Enterprise organizations - if your destination is a Grid org, you need both steps.

   
   

3. Do Slack integrations survive a migration automatically? 

   Not always. Apps and webhooks move with the workspace during Enterprise migrations, but custom apps may break due to user ID changes and webhook URLs may need updating in external systems. Workflow Builder automations do not migrate in workspace-to-workspace imports and must be rebuilt manually. A pre-migration integration audit is essential.

We’ve Done This Before - And We Can Help You Too

Our team has handled several Slack workspace migrations over the years - from straightforward workspace-to-workspace imports to complex, multi-phase consolidations involving hundreds of integrations, custom-built apps, Salesforce connections, and Slack Connect channels shared with external partners. We’ve supported post-acquisition merges, internal restructures, and full upgrades to Enterprise Grid, each with its own set of constraints and surprises.

No two Slack migrations are the same. The right approach for a 50-person post-acquisition merge looks very different from consolidating two active 500-person workspaces with deep Salesforce integrations and dozens of Workflow Builder automations. We bring real-world experience to every engagement: auditing both workspaces, mapping users and integrations, building a migration plan that accounts for the edge cases, and being hands-on through cutover and post-migration validation.

Please reach out to us for your Slack workspace migration requirements. Whether you need a complete migration from one Slack workspace to another, help with Enterprise Grid onboarding, or simply a second set of eyes on your plan - no matter the complexity, we’ve likely seen it before and we’d be glad to help you navigate it.

Ready to Plan Your Migration?

Slack migrations go wrong when they are treated as technical projects rather than operational ones. The planning matters as much as the move itself.

If you are preparing for a workspace consolidation, an acquisition, or an upgrade to Enterprise Grid - talk to the Implementology team. We scope the migration, handle the complexity, and make sure your teams land in a Slack environment that actually works.