Trying to bring everything
The scope becomes 'move all of it' because deciding what to drop requires someone to be accountable for dropping it. The project then inherits every problem the old system had, plus the cost of moving them.
Slack · Migration & Consolidation
Moving onto Slack is not a data problem. It is a decision about what to leave behind.
Teams arrive at this asking how to move ten years of threads. The more useful question is which of them anyone will ever open again. A migration onto Slack around a Salesforce org is mostly structural work — deciding the channel model, retiring what should not come across, and cutting over a team at a time without losing the conversation. Retire before you move.
12+
500+
250+
15+
Trusted by 500+ organizations — including field and office teams who moved off phone calls, texts and paper onto one workspace.
What We Move
- Salesforce Partner
- Chatter Workflows
- Email Processes
- Workspace Consolidation
- Channel Architecture
- Slack Connect
- Salesforce Channels
- Retention & Governance
What makes a move harder than it needs to be
Almost none of the difficulty in a Slack migration is technical. It is decisions nobody wants to take, deferred until they become blocking.
No target structure
Channels get created as people arrive, so the new workspace reproduces the old chaos with better search. Within a year it is the thing somebody proposes migrating away from.
Two systems, indefinitely
The cutover is soft, nobody is told when the old system stops, and both run in parallel forever. Half the team is in each, which is worse than either alone because now nobody knows where to ask.
Chatter left ambiguous
Record-feed conversation in Salesforce and account conversation in Slack overlap, with no rule about which is authoritative. One quietly becomes the version nobody checks, and it is not always the same one per team.
Guests and externals carried over blindly
External participants from the old system are recreated in the new one without anyone re-checking whether those relationships are still live. Access that was stale becomes access that is stale and freshly provisioned.
Retention decided by the migration tool
What history comes across, and how long it is then kept, ends up being whatever the tooling did by default — rather than what the organisation's actual obligations require.
What a migration onto Slack actually involves
A Slack migration for a Salesforce organisation is the work of moving an existing way of working — Chatter threads, email workflows, or a separate or duplicated workspace — onto one governed Slack workspace organised around how the business actually operates, and connected to the CRM. The content that moves is usually the smallest part of it.
What actually needs deciding. Which conversations are worth carrying, what the target channel structure is, which system is authoritative for what afterwards, who owns each channel, and when the old one is switched off. These are organisational decisions, and a migration that defers them produces a new workspace with the old problems in it.
On Chatter specifically. Salesforce Chatter and Slack overlap, and the useful answer is rarely 'replace one with the other' but 'decide which is authoritative for which conversation'. Record-level commentary that belongs permanently to the record has a good case for staying in Salesforce; cross-functional discussion has a better case in Slack, tied to the record through a Salesforce channel. We make that rule explicit rather than leaving it to drift.
What Twopir does. We run the keep-or-drop decision, design the target structure, pilot with one team, cut over in phases with a stated end date for the old system, and set the governance that stops the new workspace decaying. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Five sources — and what stays behind
The third column is the one that makes migrations succeed. Every item left behind is one that does not have to be moved, governed, retained or explained afterwards.
| Source | What it becomes | What does not come across | The decision needed |
|---|---|---|---|
| Chatter record feeds | Salesforce channels tied to the same records, for cross-functional discussion. | Historic record commentary, which usually stays where it is and remains retrievable. | Which system is authoritative for record-level commentary from now on. |
| Email threads and distribution lists | Channels with a named owner, plus workflows for the requests that arrived as email. | The archive. It stays in mail, under its existing retention. | Which lists become channels and which are simply retired. |
| A second or shadow workspace | Merged into the primary workspace, with duplicate channels reconciled. | Duplicate and dead channels, and apps nobody can justify. | Which workspace is primary, and who arbitrates naming collisions. |
| Shared drives of process docs | Canvases and pinned references attached to the channel that uses them. | The drive itself, which remains the system of record for documents. | What is genuinely a reference versus what is a document. |
| Guests and external participants | Slack Connect channels under an approval path, or nothing. | Relationships that are no longer live — which is more of them than expected. | Who re-approves each external relationship before it is recreated. |
Migration patterns; specific tooling depends on the source platform and plan
Decide before you move
The keep-or-drop pass runs first and is deliberately uncomfortable. Every conversation carried across becomes something to govern and retain, so the default answer is to leave it where it is and keep it retrievable.
Structure around work, not the org chart
The failure mode we see every time is a channel structure copied from the organisation chart. Channels organised around sites, accounts, crews or deals match how people actually work and survive reorganisations.
Cut over a team at a time
A pilot, then phased groups, each validated before the next — with a stated date when the old system stops. An open-ended parallel period is how organisations end up running both indefinitely.
Retention set by obligation
What is retained and for how long is decided against your actual legal and regulatory requirements, not left to whatever the migration tooling did by default.
The work inside a migration
Six workstreams. The first two are the project; the rest follow from them.
Discovery and keep-or-drop
Where work currently happens, what is actually used, and an explicit decision per source about what comes across. Most of the value of the engagement is here.
Target channel architecture
A channel model built around how the business operates, with naming conventions, ownership and lifecycle rules defined before anyone starts creating channels.
Chatter and Slack boundary
An explicit rule for which system is authoritative for which conversation, so the two stop competing and the record keeps what genuinely belongs to it.
Workspace consolidation
Merging duplicates, reconciling naming collisions, rationalising apps and deciding which workspace is primary.
Phased cutover and enablement
Pilot first, then groups, each validated before the next, with training on the new structure and a stated date when the old system closes.
Governance from day one
Channel creation policy, external access approval, retention set against obligation, and named owners — so the new workspace does not become the thing you migrate away from next.
From scattered to one place
Five phases, none of them an overnight switch. Each is validated before the next begins.
Discovery and workflow audit
We look at where work actually happens rather than where it is supposed to. On a field-service migration that meant shadowing crews; in an office it means reading the channels and inboxes where requests really arrive.
Channel architecture design
The target structure, organised around sites, accounts, crews or deals as the business requires — with naming, ownership and archival rules agreed before a single channel is created.
Pilot with one group
Mobile-first where the workforce is non-desk, integrations connected, and the structure tested against real work before it is imposed on everyone.
Phased rollout
Group by group, each validated, with Salesforce connected so the CRM side arrives with the move rather than as a later project.
Governance, training and optimization
Training on the new structure, governance rules in force, and a review after the first weeks — because the first version of a channel model is always slightly wrong.
A move we have already run
A delivered Slack workspace implementation for a field-service business moving off phone calls, text threads and paper checklists. The figures are the ones published on the case study.
Slack Workspace · 75+ Field Crews
A commercial cleaning and janitorial provider coordinating dispersed, mostly non-desk crews through phone calls, texts and paper checklists — moved onto a Slack workspace structured around sites, crews and client accounts.
75+ Field and office staff onboarded
5,000+ Businesses served by the client
4 Operational gaps closed
Five phases, each validated before the next
Discovery and workflow audit, channel architecture design, a mobile-first pilot with integrations, full rollout with swarming, then governance, training and 30/60/90-day optimization. No forced cutover and no overnight switch.
5 Phases, each validated
★★★★★
The goal was never to replace Salesforce — it’s still the system of record. We just made sure the team never had to leave Slack to know what was happening in their pipeline.
Twopir Project Lead SaaS technology client · 2025 Slack Sales Elevate
Slack Sales Elevate · Salesforce Integration
The Salesforce side of a move: Sales Cloud connected so pipeline arrived with the new way of working rather than as a later project.
5 Systems connected into one workflow
5 User groups aligned on one system
We move less than you expect to
The measure of a good migration is how little came across and how quickly the old system could be switched off.
We run the keep-or-drop decision properly
It is the uncomfortable part and the one that determines everything downstream. Every conversation carried across becomes something to govern, retain and explain — so the default is to leave it retrievable where it is.
We structure around the work
Sites, accounts, crews, deals — whatever the business actually organises around. A channel model copied from the org chart is the failure mode we see every time and it does not survive a reorganisation.
We set an end date for the old system
An open-ended parallel period is how organisations end up running both forever, with half the team in each and nobody sure where to ask.
We make the Chatter boundary explicit
Which system is authoritative for which conversation, written down. Left implicit, one of them quietly becomes the version nobody checks.
We connect Salesforce as part of the move
Not as a follow-on project. A migration that leaves the CRM connection for later delivers a workspace that is disconnected from the system of record on day one.
Answers before the first call
Usually not, and this is the question we most often talk clients out of. Historic record commentary generally belongs where it is and stays retrievable there; what is worth moving is the way of working, not the archive. The decision that actually matters is which system is authoritative for record-level conversation going forward, and we make that rule explicit rather than letting it drift.
For cross-functional discussion around a record, generally yes — a Salesforce channel ties the conversation to the record while keeping it in the tool people are already in. For commentary that belongs permanently to the record and should travel with it in Salesforce, there is still a case for Chatter. The failure mode is running both with no rule about which is authoritative, because one then quietly becomes the version nobody checks.
Yes, and it is a common engagement. The technical merge is the straightforward part; the work is deciding which workspace is primary, reconciling duplicate and colliding channel names, rationalising the apps installed across both, and re-approving external participants rather than recreating stale access. We would also use the consolidation as the moment to impose a naming convention, since everything is being touched anyway.
It depends on how many groups are moving and how much has to be decided rather than moved. The published field-service engagement ran in five phases — discovery, architecture, pilot, full rollout and then governance, training and 30/60/90-day optimization — with each validated before the next. We scope after discovery rather than quoting a duration first, because the variable is the decisions, not the data.
That is a structural question rather than an afterthought, and it changes the design. On the published field-service engagement the workforce was mostly non-desk, which meant a mobile-first rollout and a channel structure organised around sites and crews rather than departments. If a meaningful part of your workforce is in that position, it should shape the architecture from phase one.
We handle the organisational side — discovery, target channel structure, cutover sequencing, governance and the Salesforce connection — which is where these projects actually succeed or fail. For bulk content movement the available tooling varies by source platform, plan and what you have decided to carry across, so we scope that specifically rather than promising a particular mechanism up front. In most cases far less content moves than clients initially assume.
Governance in force from day one rather than added later: a channel creation policy, a naming convention, named owners, an archival rule and an approval path for external channels. Without those a new workspace reproduces the old chaos with better search, and becomes the thing somebody proposes migrating away from in three years.
Next Step
Tell us where work happens now, we will tell you what not to move
A migration review covers where conversation currently lives, what is genuinely worth carrying across, and what the target channel structure should be. You leave with a keep-or-drop view and a phased plan.
Retire before you move, and set a date for switching the old one off
