Migrate a pattern across a codebase
Move every use of an old API, library or pattern to its replacement: Claude Code lists each place first, then changes them in checked batches.
Task: Migrate a pattern across a codebase · Other tasks
Fill in the details
Optional. A directory or package. Leave empty to cover the whole project.
Optional. A before and after pair shows the intended mapping more precisely than a description. It goes first in the prompt, inside <example> tags.
Copy your prompt
This site doesn't run Claude or show model output. Results depend on your input and the model you use.
You've edited the prompt, so changes to the fields aren't applied.
Replace what you've entered for this task with the example? This can't be undone.
What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.
When to use this template
- A library, API or internal helper is being replaced, and its uses are spread across many files.
- The change is repetitive but not quite mechanical, so a plain search and replace would miss variants or break edge cases.
- You want a written inventory of what will change before any code changes, so you can size the work and spot awkward cases early.
When not to use it
- Only a handful of uses exist. Ask Claude to change them directly; the inventory step is overhead at that size.
- The replacement behaves differently in ways that need product decisions, such as different defaults or error handling. Settle those first, then migrate.
- The migration spans thousands of files. Use the inventory from step 1, then split the work across several sessions or run Claude Code non-interactively per file, testing the prompt on a few files first.
Why this structure
- The work is split into two steps with a stop in between. The inventory in step 1 is written to a planning file and shows the real size of the migration and its awkward cases before any code changes; you decide whether to go ahead.
- Writing the list to a file gives both of you a shared checklist that survives a long session or a fresh one, and makes progress visible as batches are ticked off.
- The optional before and after example goes first, inside
<example>tags, so it is kept apart from the instructions. It pins down the mapping more precisely than a description of the two APIs. - Batches by directory, each followed by its tests, keep any breakage small and easy to locate. "Do not move on while they fail" gives Claude a clear signal to stop and repair.
- The exceptions rule keeps behavior unchanged where the replacement does not fit, and turns those places into a list for you to decide on instead of silent rewrites.
- The final search for remaining uses closes the loop, so the migration ends with evidence that nothing was missed rather than an assumption.
Example input (fictional)
- Old pattern or API
the old logging helper in utils/log.js
- Replacement
the structured logger in lib/logger.ts
- Limit the migration to
the services/ directory
- One call converted by hand
log("user created", id) → logger.info({ userId: id }, "user created")
Follow-ups to send Claude
- Go ahead with step 2, but start with the smallest directory so I can review the first batch before the rest.
- For each exception in MIGRATION.md, suggest how the replacement could support it, or confirm it should stay on the old API.
- Now that nothing uses the old helper, remove it and check that the build and tests still pass.
Common mistakes
- Skipping the inventory and asking for everything at once. Large unreviewed diffs are hard to check and hard to roll back in part.
- Leaving out the scope in a large repository. Claude may spend most of the session cataloguing code you did not mean to touch.
- Mixing in "while you are there" cleanups. They make the migration diff harder to review and harder to revert.
Related templates
- Plan a code change before editing: Have Claude Code read the relevant code and propose a file-by-file plan for a multi-file change, without editing anything until you approve it.
- Build something new from an existing pattern: Point Claude Code at code that already works the way you want, so the new feature matches its structure, naming, tests and error handling.
- Code review prompt: Ask Claude to review a diff for supported issues, ordered by severity, with a location, impact and suggested fix for each finding.
Sources
- Claude Code docs: Prompt library (Anthropic documentation)
- Claude Code docs: Common workflows, refactor code (Anthropic documentation)
- Claude Code best practices: Fan out across files (Anthropic documentation)