Slack Enterprise Grid Migration: The Complete 2026 Technical Guide

Salesforce now auto-provisions Slack workspaces for every new CRM customer starting May 15, 2026. Quip subscriptions stop renewing after March 2027, pushing teams toward Slack Canvases. And Slack's own deprecation deadlines — legacy Salesforce connections, classic apps — are stacking up through 2026. Together, these create the strongest forcing function for Enterprise Grid consolidation since Grid launched in 2017.

This guide covers what actually survives the migration, what breaks, how the 5-phase migration sequence works, and where the DIY path stops working.

Why Slack Enterprise Grid Migrations Are Spiking in 2026

Three forcing functions are converging, and together they push more organizations into Enterprise Grid than at any point since Grid launched.

Salesforce Auto-Provisioning (May 2026)

Salesforce announced that starting May 15, 2026, Slack will be automatically provisioned, connected, and ready for all new Salesforce customers — AI-powered and Salesforce-aware from day one. (salesforce.com) This is not optional. Every new Salesforce CRM org gets a Slack workspace wired to it out of the box.

For existing Salesforce shops that already have two or three Slack workspaces scattered across business units, this creates yet another workspace that needs to be consolidated — or it becomes another island of unmanaged data with duplicate users, inconsistent SSO, and disconnected Salesforce mappings.

The Quip Sunset (March 2027)

Salesforce is retiring all Quip products. Subscriptions cannot be renewed after March 1, 2027. After a customer's term ends, the shutdown sequence is 90 days read-only, 30 days blocked logins, then approximately 30 days of deletion processing. (help.salesforce.com)

The official migration path pushes teams toward Slack Canvases. That's useful, but it is not a promise of one-to-one recreation for every Quip workflow or embedded dependency. If Quip is in scope, read our Quip End-of-Life Playbook next.

Slack's Own Deprecation Deadlines

Slack is retiring several legacy components on a staggered timeline:

(slack.com)

The classic apps deadline is the one most likely to break things during a Grid migration. Classic apps use legacy OAuth scopes and the old bot permission model. If you migrate a workspace to Grid while it still depends on classic apps, those apps will stop receiving events and their API calls will be rejected before the year is out.

What Is Slack Enterprise Grid?

Slack Enterprise Grid (referred to as "Enterprise organization" in current Slack docs, with "Enterprise+" packaging in some Salesforce materials) is a single organization containing multiple workspaces under unified administration. It is the only Slack plan that supports multiple connected workspaces. (slack.com)

Slack Pro and Business+ plans operate as isolated islands. Each workspace has its own billing, user directory, app approvals, and settings. Grid changes all of that:

• Org-level administration. Policies, SSO, SCIM provisioning, and app governance are managed at the organization level and override individual workspace settings.
• SSO is mandatory. On Business+, SSO is optional. On Grid, it's required. If your identity provider isn't configured before migration, users get locked out. (slack.com)
• Unified user identity. Users get a single global ID across all workspaces in the org. DMs and group DMs move to the org-level database shard, making them accessible regardless of which workspace a user is signed into.
• Cross-workspace channels. Channels can be shared across multiple workspaces within the org.
• Admin APIs and Audit Logs API. Programmatic management of workspaces, users, and compliance exports — available only on Grid.
• Org-level app governance. Apps can be installed at the organization or workspace level. Apps using admin, Discovery, or SCIM APIs can access org data once installed at the org level. (slack.com)

The biggest structural shift: a workspace stops being the top-level control boundary. Org policies override workspace settings. The migrated workspace URL redirects to the org sign-in page. The Org Primary Owner takes the Workspace Primary Owner role. And if you're migrating multiple workspaces, only one workspace's settings can seed the org — so migration order matters from day one. (slack.com)

What Survives vs. What Breaks: The Master Reference Table

Every row below represents a data type or configuration with its actual behavior during a Grid migration.

The 5-Phase Enterprise Grid Migration Sequence

Grid migrations follow a predictable sequence. Skip a phase and you'll pay for it during validation.

Phase 1: Pre-Migration Audit

Inventory every workspace slated for migration. For each one, document:

• Installed apps (classic vs. modern)
• Custom profile fields
• Salesforce connections and their status
• Slack Connect channels with external partners
• SAML/SSO configuration
• Custom bots and integrations
• Audit log export requirements
• Claimed domains

Export audit logs now — not the day before migration. If the workspace uses SAML for identity provisioning, disable automatic provisioning in your IdP to prevent accounts from being deactivated when you disconnect the SAML connector.

Decide which workspace has the settings you want copied into the org. Slack only lets one migrated workspace's settings seed the org, and custom profile fields plus audit logs need separate handling. (slack.com)

Phase 2: SSO and Directory Configuration

SSO is mandatory on Enterprise Grid. Configure your identity provider (Okta, Azure AD, OneLogin, etc.) with SAML 2.0 and ensure that every user's email address in the IdP matches their Slack account email. A mismatch here means lockout. (slack.com)

Test with a pilot group before the production cutover. Configure guest access bypass if you have contractors or temporary users who authenticate with email/password instead of SSO. This is also where you claim domains to stop new shadow workspaces and review org-level app governance before the first migration.

Phase 3: Conflict Resolution and ID Mapping

When you initiate the migration from Organization Settings → Workspaces → Migrations, Slack identifies user accounts that exist in both the workspace and the org:

• Exact matches (same email, same account type) can be merged automatically.
• Partial matches (some fields match, others don't) require manual review.
• Conflicting settings between the workspace and org need to be resolved — org-level policies win.

This is also when you handle user ID translation. Any app that stores local Slack user IDs needs to call migration.exchange post-migration to map them to global Enterprise IDs:

curl -G https://slack.com/api/migration.exchange \
  -H 'Authorization: Bearer $TOKEN' \
  --data-urlencode 'users=U06UBSUN5,U06UEB62U'

The response maps local IDs to global IDs: (api.slack.com)

{
  "ok": true,
  "team_id": "T1KR7PE1W",
  "enterprise_id": "E1KQTNXE1",
  "user_id_map": {
    "U06UBSUN5": "W06M56XJM",
    "U06UEB62U": "W06PTT6GH",
    "U06UBSVB3": "W06PUUDLY"
  },
  "invalid_user_ids": ["U21ABZZXX"]
}

Do not hard-code logic around the first letter of the ID alone. The real requirement is local-to-global translation. Update every reference in your internal ticketing systems, HRIS platforms, deployment bots, and any other system that stores Slack user IDs. If your app is still a classic app or still assumes legacy RTM-era behavior, modernize it before the workspace move becomes a production incident.

Phase 4: Scheduling and Execution

Schedule the migration through the admin dashboard during off-peak hours. Migration requests must be accepted within 30 days or they expire.

The workspace will be unavailable to members for a portion of the migration while DMs migrate to the org shard. Members can continue using the workspace for channel-based work while DMs process in the background, but Slack Connect conversations go dark until migration completes. Larger workspaces (10,000+ users) can take several hours.

Schedule around revenue operations, support coverage, incident rotation, and quarter-end sales workflows — not around whoever shouts loudest in the steering meeting.

Phase 5: Post-Migration Validation

After migration completes, verify:

• All users can sign in via SSO
• Custom profile fields have been recreated at the org level
• Installed apps are responsive (check for migration_in_progress errors in app logs)
• Slack Connect channels are accessible to both parties
• Salesforce connections are active and Sales Home loads correctly
• Workspace roles are correctly reassigned
• The old workspace URL redirects properly
• Custom bots have successfully processed the ID translation

If you also need to move channels between workspaces within the org post-migration, Slack's channel-move tools preserve history, files, pins, retention policies, topic, and description. But apps and bots may need reinstallation after the channel move, and Slack resets channel analytics. (slack.com)

For our full approach to zero-downtime validation, see Zero Downtime Guaranteed.

Multi-Workspace Consolidation: Order of Operations

The most common Grid migration scenario in 2026 is not a single workspace upgrade — it's consolidating 3, 5, or 15 workspaces that accumulated through M&A activity or organic department sprawl.

Pick the Right First Workspace

Only one workspace's settings can be copied to the org. If multiple workspaces are migrated, profile details from the first workspace apply by default. That means the first workspace should be the cleanest: best naming conventions, best retention defaults, cleanest Salesforce mapping, and the fewest legacy apps. (slack.com)

Claim and Verify Domains First

You cannot migrate a workspace into a Grid org unless you have claimed and verified the domains associated with its users. Claiming domains early also prevents people from creating new unsanctioned workspaces outside the org while you're still cleaning up old ones. (slack.com)

Migrate Sequentially, Not in Parallel

Slack does not support parallel workspace migrations. Each workspace must complete its migration before you start the next one. Forcing parallel moves risks locked states and failed migrations. Slack's backend processes these moves sequentially to protect database integrity. (slack.com)

Handle Duplicate Users Before Migration

If User A exists in Workspace 1 and Workspace 2, migrating both into Grid merges their accounts based on email address. Ensure email addresses are unified across workspaces before you begin. Workspaces acquired through M&A often have different SSO configurations, guest policies, and app inventories — each one needs its own pre-migration audit.

You Cannot Import Directly into Grid

Slack's import/export tooling is not supported directly into Enterprise Grid organizations. The official workaround is to import into a separate workspace and then migrate that workspace into the org. This is one reason native export/import is not the same thing as a Grid consolidation plan. (slack.com)

API Rate Limits and What Breaks at Scale

Under the hood, Slack's data model collocates all data for a workspace on a single MySQL database shard. When a workspace joins Enterprise Grid, DMs and cross-workspace data must move from the workspace shard to the org-level shard. Slack's engineering team built a migration framework with dedicated job queues and worker pools — each data handler (messages, files, emoji, user records) exposes validation, transformation, and insertion interfaces, and each handler is idempotent so restarts don't corrupt data. (slack.engineering)

Even Slack had to rate-limit their own migration infrastructure to keep CPU utilization and replication lag within acceptable bounds. If your in-house plan is "we'll just crawl every conversation and replay it," you're choosing the hardest possible path.

The implications for your migration scripts and third-party tooling:

• Rate limits vary by app type. For internal customer-built apps, conversations.history is Tier 3 (~50+ requests per minute, up to 1,000 objects per request). Commercially distributed apps outside the Slack Marketplace are throttled to 1 request per minute, 15 objects per request for new apps and installs after May 29, 2025 — a rate that makes bulk extraction effectively impossible. (api.slack.com)
• Intermittent API unavailability during migration. migration.exchange can return team_migration_in_progress errors during the migration window. Web API and Events API become intermittently unavailable. Your apps need exponential backoff: 1s → 3s → 10s → 30s → 1m.
• Discovery API is not your bulk migration escape hatch. The Discovery API is for approved eDiscovery and DLP partners, limited to security and compliance use cases. It can expose messages and files to approved third parties, but Slack says partner support varies. It is not a drop-in replacement for a migration engine. (slack.com)
• Compliance export gaps. Native Enterprise Grid exports generate massive JSON archives. They do not natively support splitting shared channels between teams. Processing a 500 GB JSON export in-memory to map team IDs will crash standard parsing scripts.
• User ID translation at scale. Every user who existed pre-migration has two IDs (local + global). If you have 50,000 users, that's 50,000 migration.exchange lookups. Batch them aggressively.

When to Escalate to a Migration Engineering Partner

Slack's admin dashboard walks you through a single-workspace-to-Grid upgrade. The DIY path works when:

• You have 1–2 workspaces with fewer than 5,000 users each
• No classic apps or legacy bots in production
• A clean SSO configuration with matching email domains
• No active Slack Connect channels with external partners
• No downstream systems storing Slack user IDs

The DIY path breaks down when:

• You're consolidating 5+ workspaces with different IdP configurations
• Custom apps depend on local user IDs and need automated translation
• You have compliance or regulatory requirements around DM archival during migration
• Salesforce connections span multiple orgs and need coordinated migration
• You need to extract data from Quip and map it into Slack Canvases before the 2027 sunset
• Your migration window is tight and you can't afford extended workspace downtime

These are the scenarios where we've built our migration practice. ClonePartner handles the rate-limit management, user ID translation automation, and zero-downtime execution that in-house teams shouldn't have to build from scratch.

Plan the Move as an Identity Project, Not a File Copy

Slack preserves a lot of content for you. What it does not preserve is the logic your company built around that content: who can sign in, which app owns which token, which workflow still has permission, and which workspace's defaults should win when duplicates collide.

The cleanest Enterprise Grid migration plans look more like dependency cutovers than data imports. Get the identity layer right, audit your apps, sequence your workspaces deliberately, and validate everything post-migration. The data moves itself — the hard part is making sure everything still works after it lands.