Before you archive or delete an old repository, remove what it still holds: secrets, deploy keys, webhooks, installed apps and tokens. Then redirect people to the monorepo, keep the history readable for audit, and record the decision. An abandoned repo with live credentials is the part of a migration most often forgotten.
What an old repo still carries
GitHub's transfer documentation shows what attaches to a repository: webhooks, services, secrets and deploy keys remain associated with it. The same is true of a repo you stop using. Nothing expires because you moved the code.
Each of those is a way in:
- Secrets may still work against production.
- Deploy keys may still have write access to infrastructure.
- Webhooks may still send data to a third party.
- Collaborators and teams may still have Write.
Checklist
- Confirm the monorepo builds, tests and deploys every service the old repo did. Do this for a full release cycle where you can.
- List and delete repository and environment secrets. Rotate any value that was shared with other systems.
- Remove deploy keys and revoke any personal access tokens that were created for the repo's automation.
- Remove webhooks and uninstall integrations that no longer apply.
- Remove published artifacts' links: update package metadata, such as the repository field in a manifest, so users are sent to the new location.
- Replace the README with a short pointer to the monorepo path and the date of the move.
- Reduce access: leave read access for those who need history and drop write access.
- Archive the repository, or follow your retention policy if it requires deletion.
- Record the repo name, date, owner and what was removed.
Keep history, or not
The audit angle matters. Original signed commits and review records live in the old repo, and rewritten commits in the monorepo are new objects. If you may need to show who approved what before the move, keep the old repo readable. Our post on archive, transfer or delete when retiring a repository covers the decision for open source projects.
Do not reuse the name
The transfer documentation notes that if you create a new repository or fork at the previous repository location, the redirects to the transferred repository are permanently deleted. Avoid creating something new under an old name, because links and clones that still point there will start reaching a different project.
Update what points to it
Search CI configs, Dockerfiles, documentation, package manifests and infrastructure code for the old repo URL. A dependency on an archived repo is a supply chain issue in its own right, so check that nothing still builds from it.
Safeguard's asset discovery can help you spot repositories and assets you did not know still existed, and its compliance and evidence automation can hold the record of what was retired.
Who does what
Give the work an owner per repository, not a shared ticket. The team that ran the service knows which secrets are live and which webhooks still matter. Security reviews the list and signs off on the removals. Platform owns the final archive step and the record. A short table in the migration ticket, with one row per repository and a date in each column, makes gaps obvious.
A note on timing
Do not remove everything on the day of cutover. Keep the old repo's deploy path available for a rollback window, then remove secrets and keys in one batch when the window closes. Put the date in the ticket so it does not slide.
Quick check
Is archiving enough?
Not by itself. Remove secrets, keys and webhooks first, because they stay attached to the repo.
Should I delete the old repo?
Follow your retention needs. Keeping it archived and read-only preserves the original review history.
Sources
Last reviewed: 19 October 2026.
