The Switch

Switching a team workspace

Everything about a personal switch still applies, and three new problems arrive with it: the data is not all yours, the deadline affects people who did not choose it, and access is removed centrally rather than by each person deciding to stop.

The sequence is the same sequence, with a communication step in front of every irreversible one.

Establish who can export what

The first question is structural: in a shared workspace, an administrator and a member generally have different export capabilities, and the split varies by product.

Find out, early, which of these is true for your workspace: whether an admin can export the whole workspace, whether individual members must export their own conversations, and whether member content is visible to admins at all. These are the facts the whole plan depends on and they cannot be guessed — check them in the account itself.

Plan for the worst case, which is that each member must export their own. If that is true, the switch has as many export deadlines as it has people, and none of them are under your control.

Tell people before anything is irreversible

The announcement needs to happen while the old workspace still works, and it needs to contain three things:

  • the date access ends
  • what each person must do before then, specifically
  • where to ask questions

That is it. What people do not need is the rationale, which is a separate conversation and tends to crowd out the deadline.

Send it far enough ahead that someone on leave for two weeks still has time. The person who misses this notice is the person whose data is lost, and they will not discover it until afterwards.

Give people the individual checklist

Every member has a personal migration inside the team one, and it is the same one: export, verify, rebuild instructions and prompts, replace shared links, revoke integrations.

Point them at the order of operations and be explicit that the export must be verified before access ends, because the members who do this at the last minute are the members who discover a problem with no time to fix it.

One thing worth stating in the announcement: an export is a snapshot, so exporting early and then working for three more weeks means three weeks are missing. People who do this promptly and correctly still get caught by that.

Two categories that are nobody’s personal responsibility and therefore no one’s.

Shared projects and workspace-level instructions. Rebuilding these needs one person to own it, and it should happen on the new side before the old one closes, so people have somewhere to go rather than a gap.

Links in internal documentation. Every shared conversation link in a wiki, a ticket or a runbook breaks when the workspace closes. Search the team’s systems for the service’s domain and replace them with text. This is the single most visible failure of a team switch, because it surfaces months later to someone who was not involved.

Sequence the seats and the billing carefully

Removing a member’s seat generally removes their access, and their access is what they need to export. Order matters: exports complete, then seats are removed, then the plan is cancelled.

Two specifics to confirm rather than assume. What happens to a removed member’s conversations — whether they persist in the workspace, transfer to an admin, or become inaccessible — varies by product and is worth knowing before you remove anyone. And whether cancelling the plan is a separate action from removing seats, since doing them in the wrong order can cut access earlier than you planned.

Time the whole thing against the renewal date and leave a margin. For a team, the margin is not a courtesy — it is the mechanism by which stragglers still get their data.

What moves

WHAT MOVES — a shared workspace

  · Each member's conversation text
                    → exports, if that member exports it
                      or an admin can.

  · Workspace-level instructions and shared
    projects
                    → STAYS BEHIND. Rebuild centrally,
                      before access ends.

  · Links in internal documentation
                    → STAYS BEHIND, broken, for people
                      who were not part of the switch.

  · Conversations of a member who missed the
    deadline
                    → STAYS BEHIND. Nobody finds out
                      until later.

  · Removing a seat
                    → IRREVERSIBLE for that member's
                      access, and access is what the
                      export needs.

  · Cancelling the plan
                    → IRREVERSIBLE for everyone at once.
                      Last step, with margin.

Keep a central record of what was done

One document: the announcement, the deadline, who confirmed they exported, what was rebuilt on the new side, and where the shared archive lives if there is one.

Its purpose is the question three months later — “what happened to the conversations from the old workspace?” — asked by someone who will otherwise ask you to check an account that no longer exists. The document is the answer, and it takes ten minutes to keep while the work is happening.

What a team switch loses

The members who do not act. Some fraction of any team will not export by the deadline no matter how the notice is written, and their history goes when access does. You can extend the deadline once and send one reminder; past that it is not a solvable problem.

And the institutional part of the workspace: which conversations lived where, who set up which project and why, the accumulated shape of how the team used the thing. That has no export format anywhere, and it is the reason what a departing member can actually take is a narrower question than most people assume.

accountsexportingcancelling