Team collaboration migration: a grounded overview, 2027 edition

A message archive is the hardest thing to move in the productivity estate, and the reason is structural.

Mail is a pile of self-contained items, but a conversation is a graph: messages point at threads, threads sit in channels, and half the content is attachments stored elsewhere.

Almost nothing carries that graph across a boundary intact. So the first decision is not which product to move to. It is whether the history moves at all.

What to take away

Three honest strategies

The middle option is chosen far less often than it should be, usually because ending a history feels like losing something. In practice, message history older than a few months is retrieved rarely, and when it is retrieved, it is for a specific reason that a searchable archive serves as well as a live product would.

Price the three options before you pick. A read only archive is the easiest to cost. At typical list prices of 6 to 22 US dollars per user per month for business tiers, 200 seats run about 14,000 to 53,000 dollars a year.

Full transfer adds migration tooling and staff time on top, which is why it comes out ahead of the other two.

What retention rules do to the choice

A technical decision becomes somebody else's decision. If your organization has record keeping obligations, some conversations are records. They cannot be deleted on the schedule that suits the migration.

The distinction depends on what a message is about, not which product it sits in. That is the logic behind published records control schedules: a retention period attaches to a class of content, not a container.

Two practical consequences. First, ask your legal or compliance contact before you set a date, not after.

Second, if anything is under a hold, say so in writing to whoever runs the migration. An export that quietly drops held material is worse than no export. Holds and legal review also shape business email migration, where a dropped mailbox can break discovery.

There is a related right worth knowing about even if it does not apply to you. Where data protection law reaches your organization, people can ask for their own data in a portable form.

The regulator's description of data portability is a good plain description of what an adequate export looks like. Use it as a specification when you ask a supplier what their export contains.

What almost never survives

Check each of these against your own pair of products rather than assuming. The list below is what teams report losing.

Number five deserves a specific test. Post a file in a conversation in the old product, run whatever export you plan to rely on, then open the result on a machine with no session in the old system.

If the file is a link rather than a file, your archive is just pointers to something you are switching off.

Ask what the export actually contains. A Slack corporate export gives you JSON, and the attachments arrive in a separate directory you have to copy as well. Mail exports from Microsoft 365 and Google Workspace are usually PST or MBOX files, which most archive tools read.

Sequence that works

The order below assumes the read only archive strategy, because it is the one most teams should pick.

Step four is where the value is. The structural decisions you make while building the new estate outlast the migration by years, and copying the old shape across carries the old confusion with it.

The part that is not technical

People do not experience this as a data move. They experience it as losing the place where their working relationships lived. Expect a fortnight of lower output, expect complaints that are really about habit rather than about features, and do not argue with them.

Two things reduce it. Name a person per team who answers questions, so the answer is local rather than a ticket. And do not change the working agreements at the same time as the product. Change the tool this month and the norms next quarter; changing both at once means nobody can tell which one is causing the friction.

Where this connects

If the reason for the move is cost, check the cost model first. A migration is a one off expense that can outweigh several years of the difference.

If the reason is control, answer the access and retention questions first. And if the tool was never the problem, read the alternatives before you spend the money.

Common questions

What do we do about direct messages?

Decide deliberately and say so. Many organizations treat them as out of scope for transfer, which is defensible, but people should be told before the switch rather than after, and anyone with an obligation to keep a specific exchange needs a way to save it.

Can we run both products for a month to be safe?

You can, and it is the most common way a migration goes badly. Two live places means every conversation happens in the wrong one at least once, and the people who dislike the change get a reason to stay put. Overlap for retrieval, not for use: old product read only, new product live, from one named hour.

How much history do people actually need?

Ask rather than guess. A fair test is to look at how far back your own searches went over the last month. For most teams the honest answer is under ninety days, with a small number of exceptions that matter enormously, such as a channel where a contract was negotiated.

The new product offers to import everything. Should we let it?

Import a sample first, of about two hundred messages including threads, files, and a private group. Read the result as a person rather than checking a count. Import tools report success when the transfer completed, not when the conversation is still readable.