GitHub Bulk Import for Branch Protection Rulesets: Review, Evaluate and Migrate Safely

What changed​

GitHub's changelog says the new flow extends the earlier single-rule conversion to work at scale. That earlier flow, announced on August 11, 2026, worked rule by rule. You opened Settings → Branches, found a classic rule under Branch protection rules, and clicked Convert to ruleset.

The new flow works from the rulesets page. Here are the steps:

1. Open your repository's Settings → Rulesets.
2. Click Import branch protection rules.
3. In the Review import dialog, check the proposed rulesets before anything is created.
4. Click Create rulesets.
5. Choose whether to keep or delete the original branch protection rules.

The Review import dialog lets you:

• Preview the rulesets that will be created.
• See which branch protection rules an existing ruleset already covers.
• Review cases where one branch protection rule produces several rulesets to preserve its original behavior.
• Choose an enforcement status (the changelog names Active, Evaluate and Disabled) and pick which rulesets to create.

This is a bulk action, but it isn't blind. You can still deselect proposed rulesets and set an enforcement status before anything is created.

Why one rule can become several rulesets​

GitHub's conversion documentation explains the multiple-ruleset case. One branch protection rule can produce several rulesets when its protections can't be represented in a single ruleset. For a repository with a handful of rules, the dialog may therefore show more proposed rulesets than you have classic rules. The changelog's illustration reportedly shows four proposed rulesets from two rules. That is one example, not a general conversion ratio.

Choosing an enforcement status​

GitHub's documentation for the single-rule flow describes two of the statuses:

• Active: the ruleset is enforced as soon as it is created.
• Evaluate: the ruleset runs without enforcing its rules, so you can review how it would behave before it takes effect.

The same guidance suggests a split. If you've migrated similar rules before and are confident in the outcome, Active is reasonable. If this is your first migration, consider starting in Evaluate mode.

Evaluate mode feeds the Rule Insights page. GitHub's documentation for managing rulesets says that, for a ruleset in Evaluate mode, you can see actions that would have passed or failed had it been active. That gives you a way to compare the new rules against real activity before enforcing them.

The Disabled status is named in the bulk dialog. The announcement doesn't describe how it behaves in this migration flow. GitHub's ruleset management documentation does say a ruleset can be set to Disabled to temporarily turn it off without deleting it.

Keep or delete the originals​

Don't treat "keep" as a safe pause button. GitHub's documentation says a retained branch protection rule continues to protect matching branches. An Active ruleset is enforced alongside it, so changes must satisfy both. A third-party migration guide found in search says the same: when both exist, the most restrictive settings apply. That guide is a community source, not GitHub documentation.

A cautious sequence looks like this:

• Import the rules and keep the originals.
• Set the new rulesets to Evaluate and watch Rule Insights.
• Once behavior matches, activate the rulesets.
• Delete the classic rules last.

That sequence is my suggestion, built from GitHub's documented behavior. It isn't a procedure GitHub prescribes for the bulk flow.

Check the mapping, not just the preview​

Automated conversion preserves intent, but it isn't a guarantee of identical behavior. GitHub's docs say you can review warnings about changes in behavior before creating rulesets. They also single out "Require conversation resolution before merging". Classic protection treats it as a standalone setting. Rulesets include it as part of the pull request rule, and it applies only when that rule is enabled. Look for this in the preview.

One commenter on the August announcement suggested comparing the generated bypass list and required checks against the classic rule before broad enablement. That's an opinion, but it's sensible. Bypass permissions and status checks are where a small mismatch can quietly weaken or over-tighten a policy.

A separate advisory piece from a third-party site recommended converting a non-critical repository first. That is also advice rather than a requirement, and it fits a tool that touches your protection settings.

Why rulesets are worth the trouble​

GitHub lists these advantages over classic protections:

• Pattern matching across multiple branches.
• Layered rulesets for granular policy control.
• Management at the organization or enterprise level.
• Fine-grained bypass permissions for users, teams and apps.

There's a visibility benefit too. GitHub's docs note that people with read access can view active rulesets. That helps developers see what rules affect them. It also lets auditors review protections without administrator access.

There is a practical push as well. A public issue in the Elastic Kibana repository argued that classic protection stopped being viable at its scale. The reason was a status-check search that timed out in the classic UI. That is one project's experience, not evidence about every repository.

One caveat: the bulk import works per repository. It doesn't deploy organization-wide policy. Organization and enterprise management are ruleset capabilities you can adopt afterward.

Who can use it​

GitHub says the feature is available for all repositories where rulesets are available. That doesn't mean every plan. GitHub's documentation gives these boundaries:

• Rulesets are available in public repositories on GitHub Free and GitHub Free for organizations.
• They are available in public and private repositories on GitHub Pro, GitHub Team and GitHub Enterprise Cloud.
• Admins, or custom roles with the "edit repository rules" permission, can create, edit and delete rulesets.

The announcement gives no rollout schedule. It also doesn't mention an API or command-line equivalent, so I won't claim one exists for this import.

Bottom line​

This is a modest but useful administration feature. It removes the repetitive part of moving from classic protections to rulesets and keeps the review steps. Use the preview, start with Evaluate if you're unsure, and check the conversation-resolution and bypass mappings. Delete the old rules only after you've confirmed the new ones behave as intended.