A monorepo migration is neither safe nor dangerous by default. The risk sits in what does not travel with the code: settings, secrets, access rules and scan configuration. Below are five common beliefs, with what the documentation actually says. Use them as prompts for your own plan, not as verdicts.
Myth 1: Our branch rules come with the history
Fact: Branch protection is a repository setting. GitHub's documentation describes rules attached to a repository that govern force pushes, deletions, reviews and status checks. Importing commits does not copy them. Rebuild them first, using the new monorepo checklist.
Myth 2: Moving the repo moves its secrets
Fact: It depends. A transfer keeps webhooks, secrets and deploy keys associated with the repository, according to GitHub. Merging history into another repository keeps none of them. See Actions secrets when you consolidate.
Myth 3: Each team's CODEOWNERS file will keep working
Fact: GitHub reads the file from the root, .github/ or docs/, and uses the first one it finds. A nested file does nothing. Paths must also be rewritten. See CODEOWNERS paths after moving a repo.
Myth 4: Teams only get access to what they own
Fact: Repository roles apply to the whole repository, and the secure-use guidance says anyone with write access can read the repository's secrets. Control approvals with code owner review and use a separate repository for anything that needs a smaller audience. See who gets write access.
Myth 5: A clean scan after the move means we are fine
Fact: A scan only reports on what it covers. A config that names the root directory only will produce a clean report while services go unscanned. Dependabot's reference, for example, says the directory setting is required to create version update pull requests. Compare before and after with check scan coverage before and after a monorepo migration.
What the myths have in common
Each assumes that protection lives in the code. In practice much of it lives in the platform around the code, in settings tied to one repository. A migration is a good time to write those settings down and rebuild them deliberately, instead of accepting whatever the new repo starts with.
Is a monorepo less safe than many repos?
Not inherently. Our decision guide on monorepo or separate repos covers real tradeoffs: one place to enforce rules and scan, against a wider blast radius for access. Teams that do well write down the controls they rely on and test them.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring keeps reporting after a change, and think about which of your controls would notice a missing setting.
Safeguard's policies, gates and guardrails and its SBOM and dependency scanning can enforce checks on every pull request in the new repo.
Quick check
What is the first thing to rebuild?
Branch protection on the default branch, before the first team pushes.
Does merging repos merge their access?
Usually in effect, yes. Review who has write access to the new repo.
Sources
- GitHub Docs: About protected branches
- GitHub Docs: Transferring a repository
- GitHub Docs: About code owners
- GitHub Docs: Secure use reference
- GitHub Docs: Dependabot options reference
Last reviewed: 19 October 2026.
