Key Takeaways
- Your AI employee's real value lives in written briefs, not in the chat tool. Runbooks, recurring task descriptions, and connected tools are what you migrate. The platform is just the room the work happens in.
- Treat the move as a re-onboarding, not a copy-paste. Set up the Teams workspace, reconnect the tools that matter, and re-establish your recurring tasks from your written briefs. Done deliberately, this is an afternoon, not a project.
- Running both is a legitimate end state, not a failure to decide. Plenty of companies keep engineering on Slack and operations on Teams. Put the AI employee where each team actually talks.
- Migrate routines in order of pain. Move the recurring reports people rely on first, personal drafting habits last. The Monday summary that stops arriving is what makes a migration feel broken.
- Use the move to prune. A platform switch is the one moment you audit every standing task anyway. Kill the reports nobody reads instead of faithfully porting them.
The question behind the question
When a company asks "can our AI employee move from Slack to Teams," they are rarely asking about software. They are asking whether the six months they spent teaching a teammate how the company works just evaporated because the CIO signed a Microsoft contract.
The honest answer: some of it transfers automatically, some of it transfers because you wrote it down, and some of it you will be glad to leave behind. This post walks through each pile, in the order you should handle them.
Viktor runs natively in both Slack and Microsoft Teams, and the capability set is the same on both sides. So the question is never "will it work over there." It is "what do we carry across, and in what order."
What actually transfers
Think of your AI employee's setup as three layers.
The platform layer does not transfer, and should not. Channel memberships, chat history, who can @mention what: these belong to Slack or Teams, not to you. A Teams workspace is a full workspace in its own right, not a mirror of your Slack. You will set up channel access fresh, which takes minutes and forces a useful question: does the AI employee still need to be in all fourteen of those channels?
The tool layer transfers with a reconnect. Your CRM, your email, your accounting stack: the integrations themselves are all available from Teams, but authorizations are granted per workspace. Reconnecting is conversational, ask for the tool, click the authorization link, done. Budget ten minutes for the three or four tools your recurring work actually reads from. If you connected eleven tools in Slack and only four ever got used, you just learned something.
The knowledge layer transfers if it was ever written down. This is the layer people worry about, and it is the one entirely in your control. Every recurring task worth having started as a written brief: what to pull, when to run, where to post, what shape. If those briefs exist as runbooks, re-establishing them in Teams is paste-and-confirm. If they exist only as "Viktor just knows," the migration is the moment you pay that debt. We covered how to write briefs that survive exactly this kind of move in how to write a runbook for your AI coworker.
The migration, in order of pain
Move things in the order their absence hurts, not in the order they are easy.
First: the shared recurring work. The Monday pipeline summary, the Friday numbers roundup, the daily support digest. These are the routines other people rely on without asking for them, which means they are the routines whose silence gets noticed by Wednesday. Re-establish each one in its new Teams channel from the written brief, run the first cycle with a checkpoint so you can confirm the output matches, then let it run.
Second: the review-first flows. Anything where the AI employee drafts and a human approves, like outbound email or record updates. These move next because they involve other people's expectations about where approvals happen. Announce the new location once, in the channel where approvals used to happen.
Third: personal habits. Your own drafting, research, and prep work moves whenever you do. Nobody else is waiting on it.
There is one step zero that gates all of this: the Teams install itself. If your organization restricts app installs, an admin approves Viktor once in the Teams admin center and can install him for everyone directly, so nobody has to find the app store. That one-time admin setup is the difference between a migration and forty people individually asking IT.
From walking real teams through this move, the single most common snag is not the install at all. It is the separate Microsoft admin consent prompt: the app is approved, people can add it, and then a permissions screen appears at first sign-in and everyone assumes the install failed. It did not. An Entra admin grants that consent once for the whole organization and the prompt never appears again. Knowing those are two different approvals, done by possibly two different admins, saves the most confused hour of the whole migration.
Running both, on purpose
Not every company that starts this conversation finishes it with a migration. A common end state, especially after an acquisition or in companies with a technical and a non-technical half, is both platforms running indefinitely: engineering stays on Slack, operations and field teams live in Teams.
This works better than the tidy-minded expect, for one reason: the AI employee follows the conversation, not the org chart. The rule that keeps a hybrid setup sane is the same rule as everywhere else, put the work where the people who consume it talk. A pipeline summary for a sales team on Teams belongs on Teams, even if the founder who set it up lives in Slack. What you should not do is post the same report to both platforms "to be safe": now there are two places to check whether it ran, and one of them will quietly become the stale copy nobody trusts.
The one genuine cost of hybrid: your written runbooks become more important, not less, because they are the single source of truth that spans both rooms. Keep them somewhere platform-neutral.
The prune nobody schedules
Here is the part that makes a forced migration weirdly valuable. Standing tasks accumulate. Every team that runs recurring work for six months is carrying reports that outlived their launch, digests nobody opens, and summaries that were one person's preference and that person left.
Normally there is no natural moment to clean this up. A platform migration is that moment, because you have to touch every routine anyway. So before porting anything, get the full list and put each item through one question: if this stopped arriving, who would ask where it went? No name, no port.
Companies that do this typically end up porting noticeably fewer routines than they had, and nobody misses the rest. That is not migration loss. That is the audit you were never going to schedule voluntarily.
Frequently Asked Questions
Do we lose the AI employee's memory when we switch?
The knowledge that was written down as briefs and runbooks moves with you, and re-teaching from a written brief takes one message. Working habits established purely through months of unwritten back-and-forth do not transfer between platforms, which is one more argument for writing your routines down while things are calm.
Can we keep Slack and Teams both, permanently?
Yes, and many companies do. The capability set is identical on both platforms. Put the AI employee where each team actually talks, keep each recurring task on exactly one platform, and keep your runbooks somewhere both sides can read.
Our IT restricts Teams apps. How much friction is that?
Very little. Viktor is a published app in the Teams app store; an admin approves him once under Manage apps in the Teams admin center and can install him for the whole organization or a specific group directly, so individual users never touch the app store. One separate detail worth knowing: if a permissions prompt appears when people first sign in, that is standard Microsoft admin consent, and an Entra admin can grant it once for the whole organization so nobody sees it again.
Do we have to reconnect every tool?
Tool authorizations are granted per workspace, so yes, but only for the tools you actually use. Reconnecting is conversational and takes about a minute per tool. Most teams find that far fewer tools are load-bearing than they had connected.
What breaks most often in practice?
Nothing breaks; things go silent. A recurring report that was never re-established on the new platform simply stops arriving, and nobody notices until someone needs it. That is why you migrate shared recurring work first and confirm the first run of each routine.
How long should the switchover take?
For the AI employee specifically: an afternoon for a team with written runbooks, a couple of days if you are reconstructing routines from memory. The overall Slack-to-Teams migration your company is doing will take far longer than the AI employee part.
Move the briefs, not the chat history
A platform migration feels like it threatens everything you have built with an AI employee. In practice it threatens exactly one thing: routines that were never written down. Write the briefs, reconnect the handful of tools that matter, re-establish the recurring work in order of pain, and prune while you are in there. The chat tool is the room. The teammate walks between rooms just fine.
Add Viktor to Microsoft Teams and bring your routines with you
Related reading: