In the first week of a monorepo migration, check seven things in order: who has access, branch rules, ownership files, secrets and cloud trust, scan scope, publishing paths, and the state of the old repositories. Each item below links to a deeper guide. The order matters because early gaps let later ones go unnoticed.
Before day one
- Freeze the scope. Agree which repos move and which stay separate. Do not add repos mid-week.
- Scan history for secrets in each source repo and rotate what is live. See do secrets in old repo history follow you into the monorepo.
- Baseline the old scans: lockfiles, components, open findings.
Day one
- Access. Start from the smallest sensible role per team. Merged repos tend to merge permissions, as explained in who gets write access when repositories merge.
- Branch rules. Turn on required reviews, code owner review and status checks before the first merge. See rebuild branch protection for a new monorepo.
- Ownership. One root CODEOWNERS with prefixed paths, and an owner for the file itself. See CODEOWNERS paths after moving a repo.
Days two and three
- Secrets and cloud trust. Recreate secrets at the narrowest scope. Update trust rules. See Actions secrets when you consolidate and OIDC trust policies after consolidation.
- Workflow permissions. Set token permissions per job. See GITHUB_TOKEN permissions in a shared monorepo workflow.
- Scan scope. Compare before and after. See check scan coverage before and after a monorepo migration.
Days four and five
- Publishing. Reconfigure registry trust per package. See npm trusted publishing in a monorepo.
- Dependency sources. Check internal names and the lockfile diff. See unscoped internal package names.
- Old repos. Remove secrets, keys and webhooks, then archive. See decommission old repositories.
One page table
| Area | Done when |
|---|---|
| Access | Each team has the narrowest working role, reviewed by a lead |
| Branch rules | Direct push to main is blocked for everyone, bypass list documented |
| Ownership | A test pull request requests the right owner for each directory |
| Secrets | Every production secret is environment scoped and rotated |
| Scan scope | Lockfile and project counts match the baseline |
| Publishing | A test release works through the new path only |
| Old repos | No live secrets, keys or webhooks remain |
What to record
Keep dated screenshots or exports of the settings, the baseline counts, and the list of exceptions with owners. That record is useful for a customer questionnaire or an audit, and Safeguard's compliance and evidence automation can help you keep it organised.
Who should be in the room
Keep the group small: one person from platform or build, one from security, one engineering lead per major team, and someone who owns the registry or cloud accounts. Each checklist item gets a named person. A fifteen minute daily check during the week is usually enough to keep the list moving and to catch an item that is stuck.
If you find a gap
Decide in advance what blocks the cutover. A reasonable rule: no production secret that is repository scoped, no direct pushes to the default branch, and no service without a scan. Other gaps become dated exceptions with owners.
Quick check
Which item is most often missed?
Old repositories. Their secrets, deploy keys and webhooks stay live after the code moves.
Should security approve the cutover?
Give security a short sign-off list built from the table above, with evidence attached to each line.
Last reviewed: 19 October 2026.
