Move a team off Git without a flag day

Running both, and how to cut over.

Written By Dustin

Last updated 29 minutes ago

A big-bang migration is the riskiest way to do this and it is not necessary. The bridge exists so both can be true at once.

A workable sequence

  1. One person evaluates. Import the repository into a fresh TOVIO repo, bridge bidirectionally to the existing Git remote, work in TOVIO. Nobody else changes anything.
  2. Decide which side is authoritative. While bridging, keep Git authoritative. It is where CI, reviews, and the rest of the team still live.
  3. Move the people who benefit most first. Usually whoever deals with large binaries, or whoever is running AI agents against the repository.
  4. Look at CI early. tovio ci check reports how each imported .github/workflows/ job classifies on TOVIO compute — native, shimmed, needs a container, or unsupported with the reason. It fails toward unsupported when it is unsure, so the report is a floor rather than a hope. Run it before you plan the CI move, not during it.
  5. Cut over. Make TOVIO authoritative, keep the Git remote as a mirror for a while, then stop bridging.

What to decide before you cut over

  • Where reviews happen. Proposals need a Forge. Until you run one, reviews stay on the Git host — or arrive through refs/for/<lane> if you have a Forge but the team is still pushing with git.
  • Whether you need policies, and when. A repository starts in Simple mode; tovio init --mode team starts it in Team mode, and tovio identity init upgrades an existing Simple repository later. Upgrading does not retroactively encrypt existing history — only newly-protected paths seal going forward. If per-file encryption is why you are moving, that is the reason to write the policies before the content you care about lands.
  • Who holds keys. Every person runs tovio key export <file> --passphrase-file <pw> and verifies the backup restores with tovio key import, before TOVIO becomes the only copy.
  • Your dotfiles. Decide which hidden paths keep travelling with the repository and write the negations into .tovioignore on day one, not after someone notices .github/ vanished.

The one thing not to skip

Do not make TOVIO the sole copy of anything until key backups are tested. It is pre-release software, and a lost key is not recoverable by support.