Tools do not fail on features
Almost nobody abandons a team tool because it lacked a feature. They abandon it because two weeks in, some conversations are happening in the new place and some in the old one, checking both is more work than checking one, and the old one wins because it is where everybody already is.
That fortnight is the whole risk. Everything before it is easy and everything after it is fine. A rollout plan is really a plan for surviving two weeks of split attention.
Which means the common preparation, comparing features and running a long trial, is preparation for the wrong problem. The decision is rarely the hard part.
Why the middle period is so dangerous
During the split, the team is genuinely worse off than before it started. Two places to check, uncertainty about where to put things, and the nagging sense that something is being missed somewhere. It is a real cost and people are right to feel it.
Human nature does the rest. When a change makes things temporarily worse, the instinct is to conclude the change was a mistake rather than that you are halfway through it. Somebody says "this is not working", which is true of that moment and not of the tool, and the team quietly reverts.
So the goal of a rollout is not to make the new tool appealing. It is to make the split period as short as possible.
Start with one thing that moves completely
The instinct is to move everything at once, so there is no split at all. This almost never works, because it demands that everybody change every habit simultaneously, and any one person's failure to do so drags a conversation back.
The better approach: pick one category of work and move it entirely. Not one team, not a trial group. One subject, for everybody.
Fulfilment exceptions work well. So does anything supplier-related. The criteria are that it has a clear boundary, it happens often enough to build a habit within a week, and it has a natural owner who can be relied on to keep it there.
Everything else stays exactly where it is. This is the part people skip, and it is what makes the rest work: nobody is being asked to change their whole day, only one recognisable slice of it.
The rule that has to be enforced
For the slice you moved, the old place is closed. Not discouraged. Closed.
This is the only genuinely difficult part of a rollout and it is where most fail. Someone will post a fulfilment exception in the old chat, because they always have and habits do not read announcements. What happens next determines the outcome.
What works is a specific, slightly annoying response: do not answer it there. Reply with one line pointing at the new place, and answer it there. It feels pedantic for about four days and then it stops being necessary, because people learn very quickly that the old place no longer produces answers.
What fails is answering it in the old place while asking people to use the new one. That teaches the opposite of what you said, and the old place stays alive indefinitely.
Who has to move first
Whoever answers the most questions. Not the most enthusiastic person, and not the most senior.
Every team has someone who is the de facto source of answers. If that person is in the new tool, everybody follows within days, because that is where answers come from. If they are not, nothing you do matters, and the rollout is dead before it starts.
Identify that person before you announce anything, and make sure they are genuinely on board rather than compliant. A reluctant answer-giver will keep replying in the old place out of kindness, which is the single most effective way to kill a rollout.
A workable four-week shape
- Week one: one category moves. The answer-giver is in the new tool. The old place is closed for that category only, and redirections are firm and friendly.
- Week two: nothing new moves. This week exists to let the first habit set. The temptation to accelerate because it is going well is how rollouts fail in week three.
- Week three: add a second category, chosen by whoever is using it most, not by you.
- Week four: ask what is still happening in the old place and why. The answers are usually specific and fixable, and they are the real feature requests.
What to measure
Not logins. Someone can open a tool daily and do nothing in it.
Measure whether the moved category still appears in the old place. That is the only number that matters, it takes thirty seconds to check, and it answers the question directly. If fulfilment exceptions have stopped appearing in the old chat, the rollout worked for that slice. If they have not, adding features will not help.
When to stop and accept it did not work
If, after four weeks with one category and a closed old place, the team is still going back, the tool is probably wrong for you and you should stop rather than push harder. That is a real outcome and worth naming, because the alternative is a year of half-use.
Before concluding that, check one thing: was the old place actually closed? In most failed rollouts it was not, and the tool was never given a fair test. A rollout where the old channel stayed open has not produced a verdict on the tool, it has produced a verdict on running two tools at once, which everybody already knew was worse.
If you do stop, say so clearly rather than letting it fade. A rollout nobody formally ended leaves the team in the split state permanently, which is the worst of the three possible outcomes and the one most teams drift into by not deciding.
The objections you will hear, and which are real
Three come up almost every time. Two are about the transition and one is a genuine signal.
"We already have too many tools." Usually true and usually not an argument against this, because a rollout done properly removes a destination rather than adding one. It becomes a real objection if you are adding a tool without closing anything, which is worth checking honestly before you dismiss it.
"I will miss things if they are not in the old place." Real during the split, imaginary after it. This is the fortnight talking. The answer is not reassurance, it is shortening the split, because the concern is legitimately true while two places exist.
"This does not fit how we actually work." Take this one seriously. It is the only objection that survives a successful transition, and the person raising it usually has a specific case in mind rather than a general reluctance. Ask what the case is. If the answer is concrete and the tool genuinely cannot handle it, you have learned something important early and cheaply.
What to do with the old archive
Moving history is almost always more effort than it is worth, and the fear of losing it stalls more rollouts than any feature gap does.
The practical answer is to leave the old place readable but not writable, and let it decay. Most questions about the past are asked in the first month and then almost never. Keeping the archive open for reading costs nothing and removes the objection entirely, while keeping it writable is what keeps the old place alive.
The exception is anything legally or financially significant, which should not have been living in a chat tool in the first place. If it is there, that is a separate problem and this rollout is a good moment to fix it.
Related reading: migrating team chat without losing history covers moving the archive, and whether you need a collaboration app at all is worth reading before any of this.
Common questions
Should we move everything at once or gradually?
Move one category of work completely rather than everything partially. A full move of one slice creates a habit; a partial move of everything creates two places to check, which is worse than where you started.
What is the most common reason a rollout fails?
The old place stays open. Someone posts in it, gets answered there, and learns the new tool is optional. Answering in the old place while asking people to use the new one teaches the opposite of what was announced.
Who needs to adopt it first?
Whoever answers the most questions, regardless of seniority. People go where answers are. If your main answer-giver stays in the old tool out of kindness, nothing else you do will matter.
How long before we know if it worked?
About four weeks with one category moved. The measure is whether that category still appears in the old place, not how many people logged in.
What if the team pushes back in week two?
Expect it. Week two is when the change has cost something and not yet paid anything back. Pushback then is about the middle of the transition rather than about the tool, and the answer is to finish rather than to add more change.