How to archive a GitHub organization before shutting down a company

What does a complete GitHub organization archive include?#

A complete GitHub organization archive includes the git history of every repository plus the collaboration record around it: issues, pull requests, review comments, discussions, wikis, releases, packages and the Actions history worth keeping. Engineers often treat the code as the archive, but for a later buyer, auditor or successor the reviews and discussions record the reasoning behind each change.

Start with an inventory. List every repository, including private, internal, archived and forked ones, and note which personal accounts own repositories the company depends on. Add teams, installed apps, webhooks and the names of organization secrets, because they document how the engineering system worked.

Prioritize by what would be hardest to recover. Review threads and issue discussions on the main product repositories come first, followed by release history and the wikis that explain deployment; experimental repositories and stale forks can wait until the core record is verified.

Which records a mirror clone captures, and which it misses#

A mirror clone captures the git data of a repository and very little else. The table shows where each GitHub record lives and how to capture it.

Feature names and export options change, so check GitHub's current documentation on migration and export tooling before writing custom scripts. Built-in tools can save time, but verify their output against the inventory either way.

Step by step: archiving the organization#

Archiving the organization works best as a fixed sequence, run by one engineer with a second checking the results. Each step produces a file or log entry that goes into the archive manifest.

Verification is the step most often skipped under shutdown pressure. A clone that fails its integrity check, or an issue export that silently stopped at an API rate limit, looks complete until someone needs it; compare counts for every repository, not a sample of them.

• 1Step 1: freeze changes. Announce the point after which no new repositories are created and pushes stop, except for archive work.
• 2Step 2: inventory repositories, owners, teams, apps, webhooks and secret names, including repositories in personal accounts.
• 3Step 3: mirror-clone every repository and its wiki, then fetch all LFS objects.
• 4Step 4: export issues, pull requests, review comments, discussions and project boards to structured files, keeping IDs, authors, timestamps and cross-links.
• 5Step 5: download releases, release assets, packages and the Actions logs and artifacts that document builds and deployments.
• 6Step 6: verify. Run an integrity check on each clone, compare repository and issue counts with the inventory, and open a sample of exported threads.
• 7Step 7: store two encrypted copies in separate locations, with a written manifest of contents, methods and dates.
• 8Step 8: transfer organization ownership and billing to the person who will control the records after shutdown, then archive the repositories on GitHub.

Ownership, billing and access before the shutdown#

Ownership, billing and sign-in decide whether the archive can be finished at all. If the last organization owner leaves, the payment method fails or the company's identity provider is switched off while the organization requires single sign-on, people can lose access to repositories or paid features before export is complete. Keep at least two owners, keep paying and keep sign-in working until the manifest is signed off.

Choose the post-shutdown owner deliberately: a founder, the wind-down officer, an acquirer of the assets or a records custodian. Document the transfer, because a later buyer of the records or a court-appointed officer may need to show who controlled the archive and when.

Repositories owned by former employees' personal accounts need the same attention. Ask owners to transfer them into the organization while they are still reachable, and record who created each one.

What to keep out of the archive#

Secret values do not belong in the archive. Repository and organization secrets cannot be read back once set, and tokens, deploy keys and cloud credentials should be revoked at shutdown. Record which secrets existed and what they unlocked, not their values.

Credentials committed to git history are a different problem, because they travel with every clone. Open-source scanners can find them: gitleaks, an MIT-licensed secret detector whose maintainer now describes it as feature complete, and TruffleHog, which can confirm whether a discovered credential still works by trying it against the issuing service. Because that verification contacts the service with the credential, limit it to keys the company owns and agree the scan with whoever leads security.

Note personal data in the manifest too. Customer names in bug reports or logs pasted into issues mean the archive needs a privacy review before any future reuse.

Illustrative: a project management software company archives its GitHub organization#

Illustrative: a fictional project management software company is winding down after selling its customer contracts to a competitor that did not want the code. The CTO keeps the GitHub plan active through the wind-down and adds the wind-down officer as a second organization owner.

The team mirror-clones every repository and wiki, fetches LFS objects, and exports issues, pull requests and review threads to JSON files with authors, timestamps and links to commits. A scan of the mirrors finds old cloud keys in history; they are revoked and listed in the manifest. Two encrypted copies go to separate storage the wind-down officer controls, the repositories are archived on GitHub, and the archive later supports a records assessment without anyone needing the original accounts.

How SourceX approaches archived engineering records#

SourceX does not take custody of multi-terabyte archives; they remain on the owner's storage or travel on encrypted drives. If the owner later considers licensing, the fit check collects only metadata, such as repository counts, years of history and which record types were exported. Any license then follows the SourceX five-step transaction, and the SourceX Evidence Packet records provenance, licensing rights and release authorization for what is delivered.