How to Use the Dependabot to Renovate Migration Plan Prompt Without Duplicate PRs
Migrate a repo from .github/dependabot.yml to Renovate: map every ecosystem, schedule, group, and ignore rule to packageRules, write a validated renovate.json, and plan the cutover so you never get duplicate PRs.

Dependabot is the default for many GitHub repos because it is already there. Teams usually move to Renovate when they want finer control: grouping related packages, holding brand-new releases for a few days, automerging low-risk updates, or running one consistent config across many repos. The migration itself is not hard, but it is fiddly. Every key in dependabot.yml has a Renovate equivalent with a different name, and a sloppy cutover leaves both bots opening the same bump. The Dependabot to Renovate Migration Plan with a Ready renovate.json prompt turns that into a field-by-field translation plus a runbook.
What makes this migration fiddly
Dependabot config is organized by ecosystem and directory. Renovate detects managers automatically and organizes behavior through packageRules. That means a Dependabot ignore block becomes a package rule with matchUpdateTypes and enabled: false. A Dependabot groups entry becomes a package rule with groupName and matchPackageNames. open-pull-requests-limit becomes prConcurrentLimit. And schedules move from interval: weekly to Renovate's natural-language schedule strings paired with a timezone.
There are also version changes inside Renovate to track. The old config:base preset is now config:recommended. stabilityDays became minimumReleaseAge. And in recent major versions, glob and regex patterns go directly inside matchPackageNames, replacing the deprecated matchPackagePatterns. The prompt asks which runtime and version you use so it writes current syntax.
What the prompt produces
- A field map table covering every key in your pasted
dependabot.yml, with the Renovate equivalent and anything that has no direct match. - A complete
renovate.jsonstarting with$schemaandextends: ["config:recommended"], then your timezone, schedule, concurrency limit, labels,minimumReleaseAge,lockFileMaintenance, and package rules for groups, pinned majors, and automerge. - A decision on GitHub Actions digests, including the trade-off of the
helpers:pinGitHubActionDigestspreset. - Security update handling. Dependabot security alerts are separate from Dependabot version updates, and Renovate's
vulnerabilityAlertsblock can bypass your weekly schedule so fixes do not wait. - A cutover runbook with validation, onboarding, dashboard checks, deleting the old config, closing stale PRs, and rollback.
- Open questions only where your inputs are ambiguous.
How to fill the inputs
Paste your entire dependabot.yml into DependabotYml. Do not paraphrase it; the field map is only as complete as the file. List real lockfiles and manifests in Ecosystems so the prompt knows whether to mention npm, pnpm, Docker, Terraform, or Actions.
MergePolicy is the most important input for safety. Say exactly what may automerge and under what checks. The prompt will never enable automerge for major updates unless you say so. Timezone lets it build a schedule window outside business hours. RenovateRuntime tells it whether you use the hosted Mend Renovate app or a self-hosted CLI, and which version. PinnedMajors lists packages that must never jump a major version automatically.
Walking through the example
In the sample run, a repo with npm, a Dockerfile, and GitHub Actions moves to Renovate. The output keeps the original weekly cadence but places it in a Monday evening to Tuesday morning window in the team's timezone. The AWS SDK group becomes a single package rule with a glob. The React major-version ignore becomes a disabled rule for both react and react-dom. Only devDependency minor and patch updates automerge, matching the stated policy.
The runbook is ordered on purpose. Validate the config with renovate-config-validator first. Merge the onboarding PR. Open the Dependency Dashboard issue and confirm all the expected dependencies appear. Then delete .github/dependabot.yml the same day, so the two bots never race. Closing old Dependabot PRs with a pointer to the dashboard keeps the history clear for reviewers.
Pitfalls
- Leaving
dependabot.ymlin place "just in case." You will get duplicate PRs within a week. - Copying an old blog post's
renovate.jsonthat still uses deprecated options. Validation will warn, and some options are migrated silently, which makes config harder to read later. - Turning on automerge without required status checks in branch protection. Renovate respects checks, but only the ones that exist.
- Forgetting security updates. Version updates and security fixes should not share the same weekly schedule.
When this prompt fits
Use it for a single repo migration, or run it once per repo in a small portfolio and then lift common rules into a shared preset. It does not replace reading the Renovate docs for edge cases like monorepo workspaces, but it gets you to a reviewable pull request quickly and keeps the reasoning visible.
Related PromptDig links
- Prompt: Dependabot to Renovate Migration Plan with a Ready renovate.json
- More developer workflow prompts: Browse more prompts
- Have a config migration prompt that works for you? Share a prompt