Moving a Deployment to a New Team
Buying a team edition creates a team. It does not move the deployment you were already running — that stays bound to your personal account, which is the safe default and occasionally the surprising one. Nothing has moved and nothing is at risk. But if you want the team's deployment to be the one you have been using, there are three ways to get there, and they are not equally safe.
This applies when a purchase creates a new team. A team that moves to a larger edition of the same kind keeps the subscription it holds, and no deployment has anything to redo.
Three ways forward, best first
The order is the advice. The first way is not merely the easiest: it is the one with nothing at risk. The last is an expert path.
- Stand up a new deployment for the team. Nothing to migrate and nothing at risk, and the deployment you already run stays yours. The right answer for anyone whose solo work was exploratory.
- Back up your graph, then carry it across. The safe route if the data has to come with you. Take the backup first — there is no refund window and no undo, so a restore is the only thing standing between a bad move and starting again. Taking and restoring a backup is covered in Backing up and restoring the graph.
- Re-point the running deployment in place. The expert path, and it is genuinely dangerous. Disconnecting removes your content mounts, your installed artifacts and the knowledge-graph connection; reconnecting restores only the last of those, and what is left behind is deleted at the next platform start. Record what is mounted and installed before you touch anything — nothing can reconstruct that list afterwards — and talk to us before you run it, at support@dether.net.
This guide gives no step-by-step sequence for the third way. Talk to us first. What is here is the part that holds regardless: what the risk is, and what to record before you touch anything.
Why the third one is dangerous
A disconnect removes all three kinds of cloud module — content mounts, installed artifacts and the knowledge-graph connection — and a reconnect restores only the knowledge-graph connection. The other two are separate operator actions on separate controls, and nothing keeps a record of what was swept. A deployment left that way loses the classes those modules declare, and every relationship those classes are in, at its next platform start.
What a disconnect costs is set out in full in Disconnecting.
And putting the files back is not proof
What protects a module is loading healthily, not being present on disk. The startup sweep builds its keep-list from the modules that loaded, so a directory that is there and fails to load is not skipped — it is invisible to the keep-list and goes with its classes. Verify every module came back healthy, because a silent load failure looks exactly like success until the classes are gone.
One precondition on all of it
The new team's edition has to cover at least what the deployment mounts today. Anything it does not cover cannot be re-mounted, and goes the same way: its classes, and every relationship they are in, at the next platform start.
Related
- Your subscription — subscribing, and where your deployment's values are on the portal.
- Check the connection — three checks for a deployment once it is connected to the team.
- Changing who may sign in — narrowing a connected deployment to some of the team's members.