I have a folder on my laptop called "ruleset migration" that has been open for months. Inside it: a spreadsheet of every repo we own, a column for whether main is protected, a column for whether the protection matches our template, and a column called "notes" that is mostly the word "later". Every time I opened the folder I closed it again. Recreating each rule by hand, across dozens of repos, was the kind of afternoon nobody wanted to book.
GitHub's 2026-08-11 changelog quietly moved that afternoon off my calendar. You can now convert existing branch protection rules to repository rulesets directly from repository settings, without hand-recreating each rule. That is the whole announcement. It is also, if you own a policy story on GitHub, the small change that finally makes the bigger one tractable.
Why this is the migration nobody was doing
Branch protection has been the thing you set on main since forever. One repo, one branch pattern, a checklist of required checks and reviewers, and you were done. It works, and it is exactly why so many orgs still have it: touching a live policy on a repo where 50 people push every day is not a Friday task.
Rulesets are GitHub's forward-going answer to the same problem. GitHub describes them as its more flexible and scalable policy framework, and the reason CI/CD owners keep hearing about them is that they let you write one policy that targets many refs and many repos, instead of maintaining N copies of the same clicked-in rule. The migration was always the sticking point. The rules already work. Rewriting them by hand, per repo, in a UI that is not identical to the old one, is an easy thing to defer to next quarter. And then the next.
What actually changed on the 11th
The conversion is in repository settings and it runs on the rules you already have. No CSV export, no third-party tool, no Terraform re-import dance. You point at a branch protection rule, you get a ruleset back. The rest of the rulesets machinery, targets, layering, bypass actors, is the same as it has always been.
That is intentionally boring, and it is the interesting part. When a migration is boring, it happens. When it is a change management project with a rollback plan, it lives in the folder called "later".
How I would sequence it
Do not do the whole fleet on Monday. Pick one low-traffic repo, run the conversion, and diff the resulting ruleset against your template. You want to see the field mapping with your own eyes before you trust it on the repo that ships to prod. Two things to look at once you have the ruleset in front of you: the required status checks list, and whoever ends up in the bypass list. Those are the two knobs most likely to look "close enough" from a distance and behave differently in practice.
Then pick your busiest repo and do it during a normal working hour. Not out-of-hours. If something is off, you want the people who push to that repo online to notice. And once the pattern holds on two or three repos, this becomes the boring afternoon it should have been all along.
The rough edge worth naming
The changelog covers the in-repo conversion. If your branch protection lives in a Terraform module or a policy-as-code file that gets applied on a schedule, a click in the UI is not the end of the story. You will need to decide whether the new ruleset gets adopted back into your IaC as the source of truth, or whether your module still writes the old protection and quietly undoes the migration on its next run. Pick one before you migrate the second repo. Choosing after the fact is how you end up with drift you did not know you had.
Also worth naming: rulesets and branch protection can coexist on the same repo. If both are present, both apply. That is a feature during a phased migration and a foot-gun if you forget you left one behind.
What I am watching next
I want to see the migration path show up in the org-level surface, not just per repo. The whole point of rulesets is fleet-wide policy, and the shortest way to get a fleet onto them is a batch conversion, not a per-repo click. Give me a "migrate everything matching this template" button and I will happily close that spreadsheet for good. Until then, this is the change that lets me stop calling it "later" and start calling it "this week".
