GitHub Organization
Migration Guide

Why we're doing this

• Stop sharing one login. Everyone currently commits under the same account — we lose track of who changed what, and one compromised laptop exposes everything.
• The company should own the code. Repos shouldn't live under any individual's personal account.
• Follow a standard workflow. Separate accounts make branches, PRs, and reviews actually meaningful.

The approach: new org + transfer repos

We could not convert the shadstoneofficial personal account into an org (GitHub blocks conversion for accounts already tied to other orgs — it owns BuildMyOnlineStore, headlessdomains, etc.).

So the path is:

1. Create a new organization (a different name, since shadstoneofficial is already taken by the personal account).
2. Transfer the repos into it.
3. Reconnect deployment services and re-point local clones.

Note on the org name

• The name shadstoneofficial is held by the existing personal account and can't be reused unless that account is renamed/deleted (which risks the other orgs tied to it — not worth it).
• Pick a clean new name, e.g. shadstone, shadstone-dev, shadstone-hq. Confirm availability before committing.
• Repo URLs will change (shadstoneofficial/REPO → NEW-ORG/REPO). GitHub auto-redirects old paths for a while, so nothing breaks instantly — but we update everything properly during migration.

Access model

• The three of us (Manly, Mike, Christian) are all org Owners. Full access to everything, no per-repo granting. Simplest for a trusted core team.
• Every owner account must have 2FA enabled. Three owners = three possible ways in; lock them all down.
• Future hires default to member, not owner. Use Teams then to group people and grant scoped repo access. Owner = keys to the whole org; reserve it for the core team.

Before you start (prep)

1. Each person has their own personal GitHub account (Manly, Mike, Christian).
2. Enable 2FA on all three accounts.
3. Decide and check the org name is available.
4. Audit what currently logs in as shadstoneofficial so nothing gets stranded:
   • Railway, Vercel, Netlify connections
   • Any "Sign in with GitHub" using the shared account
   • Scripts/services using the shared account's tokens
5. Back up the shared account's credentials (recovery email, 2FA) in case access is needed during the process.

Migration steps

1. Create the org

• Create the new organization under the chosen name.
• (Free plan is fine to start. Upgrade to Team later only if we want enforced branch protection on main.)

2. Add members as Owners

• People → invite Manly, Mike, Christian.
• Set each one's role to Owner.

3. Transfer the repos

• For each repo: repo → Settings → scroll to Danger Zone → Transfer ownership → enter the new org as the destination.
• Transfer (don't recreate) — this preserves all history, issues, PRs, and sets up redirects from the old paths.
• Repeat per repo.

4. Reconnect deployment services

Repo URLs changed, so the GitHub connections in hosting services need re-pointing.

For each Railway service:

• Service → Settings → Source.
• Disconnect the old source repo.
• Reconnect to the repo at its new org path (NEW-ORG/REPO).
• Re-select branch main.
• Confirm "Auto deploys when pushed to GitHub" is on.

Do the same for any Vercel / Netlify projects connected to these repos.

5. Re-point local clones (everyone, every clone)

Nobody needs to re-clone. Each person just updates the remote URL on each local copy:

# check current remote
git remote -v

# update to the new org path
git remote set-url origin git@github.com:NEW-ORG/REPO.git
#   (use the https://github.com/NEW-ORG/REPO.git form if you clone over HTTPS)

# verify
git remote -v

• Each of us does this on every repo, on every machine we have it cloned.
• Tip: copy the exact new URL from each repo's green Code button on GitHub to avoid typos.

6. Test

• Push a trivial commit to main on one Railway-connected service and confirm it auto-deploys.
• Each person runs git pull on a re-pointed clone to confirm the new remote works.

After migration

• Everyone commits under their own account — no more shared login.
• Adopt the workflow in our Contributing Guide (branches + PRs + 1 review).
• Optional later: upgrade to GitHub Team (~$4/user/month) to enforce branch protection on main (block direct pushes, require approval). On free, the workflow runs on the honor system.

Quick reference: what changes vs. what doesn't

Cautions

• Transfer, don't recreate. Recreating loses history, issues, PRs, and redirects.
• Redirects are a grace period, not a permanent fix. Update remotes and service connections rather than relying on them.
• Don't rename/delete the shadstoneofficial personal account to free its name — it owns other orgs (BuildMyOnlineStore, headlessdomains) and that risks breaking them. Not worth it.