By mid-2015 the team messaging market looked like a two-horse race. Slack had the momentum, the developer affection and the growth numbers. HipChat had Atlassian behind it, a bundling relationship with the tools engineering teams already used, and a self-hosted option that enterprise security teams liked. The reasonable prediction at the time was a long competitive battle between them. What actually happened is the most useful part of the story. Microsoft announced Teams the following year, bundled it into a suite that enterprises had already bought, and within a few years the shape of the market was settled. HipChat was wound down and its customers were migrated toward Slack under a partnership arrangement. The two-horse race turned out to be a three-way contest that a third party won by not competing on product at all. For anyone planning a collaboration platform migration today, that history matters less as trivia and more as a warning about what you are actually committing to.
Why switching costs are higher than they look
Collaboration platforms present as low-commitment purchases. Per-user pricing, cloud delivery, no infrastructure, cancel any time. The migration experience says otherwise, and the reason is that these platforms accumulate three kinds of dependency that nobody costs at purchase. The archive. After two years, the platform contains the record of how decisions were made — the thread where a customer commitment was agreed, the channel where an incident was worked through, the direct message where a contract term was negotiated. Exports exist, but an export is a file, not a searchable archive with intact threading, permissions and file attachments. Organisations that migrate typically end up either running the old platform in read-only mode indefinitely or accepting that the institutional memory becomes practically inaccessible. The integrations. Alerts from monitoring systems, deployment notifications, ticket updates, approval workflows, custom bots written by someone who has since left. Each is a small piece of automation that someone built because it was easy, and collectively they are a substantial body of undocumented workflow. A migration project that inventories integrations always finds more than expected, and a meaningful fraction have no owner. The habits. Channel structures, naming conventions, notification discipline, the shared understanding of which conversations go where. That is organisational knowledge accumulated over years, and it resets on migration. The productivity dip is real, lasts weeks, and is the part that generates the most complaints. None of these appear in a licence comparison, and together they usually exceed the licence difference by a wide margin.
What actually decides these contests
The competitive history of this category points to three factors, in order of importance, and product quality is not first. Distribution wins. A capable product included in a suite the organisation already licenses beats a better product that requires a new contract, a new budget line and a procurement exercise. This is not a comment on any particular vendor; it is the repeated outcome across messaging, conferencing, file sharing and increasingly everything adjacent. Integration density follows. The platform that everything else already talks to accumulates an advantage that compounds, because each new integration raises the cost of leaving. Genuine user preference comes third, and it matters most in organisations where employees have the latitude to ignore the mandated tool. That latitude is more common than IT departments assume, which is why mandated platforms with poor adoption keep losing to whatever people actually open. The practical implication for a migration decision: if you are moving toward the bundled option, the economics are probably right even if the product is a step down, provided you can decommission the thing you are replacing. If you are moving away from a bundled option toward a specialist, you need a specific and defensible reason, because you will be paying twice.
Practical Guidance for Platform Migration Planning
- Decide the archive strategy before anything else. Migrate history, keep the old platform read-only, or export to a records system. Each has a cost and a retention consequence, and this decision constrains the entire timeline.
- Inventory every integration and bot, then identify an owner for each. Anything without an owner is a candidate for retirement rather than migration — and that discovery alone usually reduces scope.
- Run both platforms in parallel for a defined, short period with a hard cutoff date. Indefinite parallel running produces permanent fragmentation and doubles the cost. Announce the shutdown date at the start.
- Migrate by team, not by function or alphabetically. Teams that talk to each other constantly must move together, or they will route around the migration by staying on the old tool.
- Rebuild the channel structure deliberately instead of replicating it. A migration is the only realistic opportunity to clean up years of accumulated channels, and copying the mess forward wastes it.
- Configure retention, legal hold, export and eDiscovery before the first user is onboarded. Setting retention after the archive has grown is harder, and the default settings on most platforms are chosen for convenience rather than defensibility.
- Plan for the productivity dip and say so publicly. Several weeks of reduced efficiency is normal. Organisations that predict it manage expectations; organisations that promise a seamless transition lose credibility in week two.
- Negotiate exit terms in the new contract. Data export formats, assistance obligations and a defined transition-out period. You are negotiating from strength exactly once, and it is now.
Choose the archive strategy
Decide how history remains accessible and how retention requirements will be met.
Map integrations and owners
Identify the connectors to rebuild, retain or retire.
Move collaborating teams together
Set channel conventions and a defined parallel-running cutoff.
Complete the exit
Decommission the replaced platform and confirm the agreed export and transition obligations.
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The Regional Angle
Collaboration migrations in the Gulf carry a set of factors that global migration plans typically ignore. The incumbent is usually not the platform being replaced. Across much of the region, the real internal communication channel is WhatsApp — for coordination, approvals, supplier negotiation and client contact. A migration from one enterprise platform to another therefore competes with a third tool that nobody is decommissioning. Plans that treat the project as a two-platform transition consistently under-deliver, because the behaviour they need to change is not the behaviour they are measuring. The workable approach is to define which categories of conversation must live in the sanctioned platform — anything touching payroll or personal data, anything constituting an approval, anything that may later be needed as evidence — rather than attempting wholesale displacement. Workforce composition changes the licensing arithmetic. Groups with large frontline populations in construction, logistics, hospitality and retail cannot apply office-worker per-seat pricing across the full headcount. The migration design question is which population gets a full licence, which gets a limited one, and what the frontline experience is on a personal mobile device in a second or third language. Turnover intensifies the archive problem. Employment-linked residency produces high mobility, which means a substantial share of institutional knowledge sits in the messages of people who have already left. Deactivated-user message retention and the searchability of departed employees' channel history are not administrative details here; they are the difference between a usable archive and an empty one. Residency and retention obligations add the final layer. Financial services entities in DIFC or ADGM, healthcare providers and government-adjacent organisations may face record-keeping and data location requirements that constrain which platform tier or region is acceptable. Establish those constraints before shortlisting, not after. And a practical scheduling note: staged rollouts across a group with UAE, Saudi and other Gulf entities run into different weekend days and, during Ramadan, compressed working hours. A cutover weekend that works in one country may be a working day in another.
The objection worth taking seriously
The strongest argument against most of these migrations is that they are not worth doing. The benefits claimed for a platform change — better user experience, tighter integration, consolidated licensing — are frequently modest and hard to measure. The costs are concrete: project effort, integration rework, lost archive accessibility, weeks of reduced productivity and a period of internal frustration. A significant number of migrations are undertaken because a licensing renewal created a moment of decision, not because the current platform was failing anyone. There is also the fragmentation risk. Migrations that do not achieve full cutover leave the organisation running two platforms permanently, which is worse than either alone: conversations split, searches miss things, and new employees have to learn both. That outcome is common enough that it should be treated as the default risk rather than an edge case. The defensible position is that a collaboration migration needs a reason that survives contact with those costs — a genuine consolidation saving with something decommissioned, a compliance requirement the current platform cannot meet, a vendor exiting the product, or adoption so poor that the incumbent is not actually being used. "The other one is better" is not sufficient, and the history of this market suggests the product you migrate to may itself be replaced by its own vendor within a few years.
Common Questions
Should we migrate message history or start clean?
Most organisations that migrate history find the result disappointing — threading, permissions and attachments degrade, and search quality suffers. The pragmatic pattern is to keep the old platform in read-only mode for the length of your retention obligation while starting clean on the new one, unless a regulatory requirement forces consolidation.
How long should parallel running last?
Weeks, not months, with a publicly announced hard cutoff. Every additional week of overlap increases the chance that some teams never move, and partial migration is the most expensive possible outcome.
What is the most underestimated cost?
Integration rework, closely followed by the archive decision. Both are discovered mid-project by teams who scoped the migration as a user-onboarding exercise.
How should AI features affect the choice?
They raise the value of consolidation and the cost of fragmentation. Summaries, search and agents only work across the conversations the platform can see, so a split estate degrades the capability that increasingly justifies the licence. They also make the archive decision more consequential: a migration that strands years of history removes the corpus those features would otherwise draw on. And they introduce a governance question worth settling before signing — what the vendor does with your message content, whether it trains anything, and where inference happens.
Platform Migration Planning — the licence comparison is the cheapest part of the decision; the archive, the integrations and the habits are what you are actually moving.