Deprecating/archiving repos in a mid-size org

Problem Description
We maintain an org in the GitHub Enterprise Cloud with ~400 developers and a growing number of repositories. The longer the company exists, we inevitably have repos that we don’t actively use anymore. Those might be hackathon projects, other experiments, or products/repos that got discontinued.

Which options do we have clean up repos in a safe manner? For use safe means, that w don’t want to completely delete them, because we might need them again in the future. Also for compliance reasons we sometimes need to keep source code around for some time.

Current Solution: Archiving
What we have done so far is to archive repos). Through archiving, the repos are turned into a read-only mode  and on the repo page it is indicated visually (with a yellow bar at the top) that those repos are archived, which means deprecated/unused in our interpretation.

There is one drawback to archiving though:

By default, when searching for anything within all repos in our org, these archived repos will still show up too. While that behavior can be modified with the flag archived:false in the search, this is not a good experience for our developers because they will simply forget this.

Proposal: Dedicated "archive org"
Here one idea for an approach that would hide the repos from the default search, while still keeping the repos around for archive purposes.

  • create a new org (e.g. my-org-name-archive) below our Enterprise account.
  • move archived repos into my-org-name-archive (so e.g. from my-org-name/sample-repo to my-org-name-archive/sample-repo)

The advantage of that approach is that the users in my-org-name can just search and will see only unarchived (i.e. active) source code. At the same time all archived code is still available and fully searchable in my-org-name-archive if ever require for anything.

Have others here run into this problem?
What do you think about the proposal above?
Also what other solutions have you found to this?

Looking forward to an interesting discussion :slight_smile:


I think lots of organizations will eventually face this problem, so it’s important to have a good solution.  You mentioned the searching pain point… managing permissions for archived repos is maintenance burden that’s another pain.

Your proposed action plan sounds like a good path forward with the features GitHub currently offers.  It depends on if users are really still using these old repos.  If not, it might be best to backup the code somewhere else so you don’t need to maintain and pay for two separate GitHub accounts.

I think GitHub should offer another option that’s between archiving the repo and deleting it - let’s call this the iceberg.

When a repo is put in the iceberg it’s not searchable and not searchable, it doesn’t show up in the standard repo listing for the organization, and there are no permissions for the repo.  There is an iceberg view that only the admins can access.  Admins can unfreeze the repo and move it out of the iceberg at any time.  It’s basically just deleting the repo, but less permanent.


Thanks for your input @mrpowers !

Love the iceberg :slight_smile:

It isn’t a pun on this project that GitHub is actually doing, is it? :)

 If you are a GitHub Enterprise customer, then a separate org like the my-org-name-archive does not cost you extra. Which is why this was my first idea.

Instead of the iceberg that you are proposing, GitHub could also change the search feature and search for archived:false by default. That would also solve the problem for me and make archiving more useful. To not force this behavior for all users, they could also make the search feature configurable for an organization.

I heard that new search features are coming in Q1/2020, so fingers crossed that some helpful features about managing a growing number of archived repos will be in there :slight_smile:

Thanks again for your reply!

I’ve used both approaches for the Atom editor with being the archive org.   Personally, I prefer the archive repo approach because, despite the single drawback mentioned, people often forget that the archive organization is there and wonder if old projects or repos have been deleted … or they don’t archive something that should probably be archived because they can’t find the archive repo right away and table it for later.

1 Like

Thank you for sharing this real-life example @lee-doh.

I definitely want to motivate people in our org/company to continue to archive repos, so whatever approach I end up with, it should support that.

I have also heard that GitHub will release new search features in Q1/2020, that will allow to search across multiple orgs within the same Enterprise account. Depending on how exactly that will be implemented, that might make the “archive org” approach more attractive.

Separate topic

Mini feedback on

The org description says “Projects that are no longer maintained by GitHub.”

Maybe it would be more correct to say “Atom projects that are no longer maintained by GitHub.” as this org is specific to Atom, and not for GitHub overall?

(sorry if this is not the best place to send you this feedback but I didn’t know how to get it to you otherwise)

This is a problem even for our tiny company with only a handful of developers. We also tried setting up an archive account, and transfer archived repos to it, but it’s really a hassle.

IMHO, Github should improve the UX by hiding archived repos everywhere by default until someone explicitly searches for them.


Almost 6 months later and we still have the same situation.  We’re at 140+ repos growing at 40+ every 100 days, with 33 archived at the moment.  I don’t want the hassle of maintaining the archives but we can’t simply delete them for compliance reasons.  It sounds like a secondary org is really the only option.  

So to confirm, the steps are:

  1. Create the <my-org>-archived account below our enterprise account.
  2. Checkout each repo.
  3. Import each repo into the new account.
  4. Archive the repo in the new account.
  5. Delete the repo from the current account.

Is that about it?



Hi Maria, 40+ repos every 100 days is really something… though it does ask the question, is it needed? Is there not a better process for creating new projects, grouping existing ones with the same or similar functionality? I know there may be a genuine need for such large scale creation, but perhaps it’s also an idea to look into the process as a whole and see if there is any changes that can be made earlier on, that prevent such as increase in repositories, and therefore a decrease in the need for such archiving power.

Perhaps, and this is just a poke in the dark, for some repositories different branches would be better suited?