Legacy Code Refactoring Plan
Point this prompt at your legacy code and get a battle plan: what to refactor first, what's safe to touch, what needs tests before you breathe on it — sequenced so every step leaves the system working. Modernization without the big-bang rewrite.
A safe, incremental plan to modernize legacy code without the big-bang rewrite disaster.
You are a software architect specializing in legacy modernization. I will describe a legacy module: what it does, the tech stack, and what hurts. Produce a refactoring plan: 1) RISK MAP — what breaks if we touch what, 2) SEAM IDENTIFICATION — where to cut boundaries for incremental change (strangler fig pattern), 3) PHASED PLAN — 4-6 phases, each independently shippable and testable, ordered by risk/reward, 4) For phase 1 only: concrete steps with before/after code sketches, 5) What NOT to refactor and why. Optimize for safety over elegance. Here is the module:
See what this prompt creates
What this prompt does
Everyone inherits code they're afraid to touch. This prompt acts as the architect who isn't afraid: it analyzes your legacy module, maps the risks (hidden coupling, missing tests, load-bearing hacks), and produces a sequenced refactoring plan where each step is small, safe, and leaves the system green. No “rewrite it all” fantasies — just the strangler-fig path to clean code.
How to get the best result
Give it the full module plus its tests (or the honest admission “there are no tests” — the plan changes accordingly). State your constraints: what you can/can't change, the framework version you're stuck on, the deadline pressure. The plan is only as realistic as the constraints you declare.
Common mistakes to avoid
The cardinal sin is refactoring without a safety net: if there are no tests, step one of any sane plan is characterization tests, not cleanup. And don't let the AI talk you into a full rewrite — this prompt is explicitly instructed to prefer incremental strangulation, because big-bang rewrites are where projects go to die.
Try these variations
Use it for migration planning (“Python 2 to 3,” “class components to hooks”) — same risk-mapping logic applies. After each refactor step, run the senior code reviewer prompt on the result to verify the new code is actually better. More in the coding prompts collection.
How to use this prompt
- Copy it — hit the copy button above to grab the raw prompt text.
- Fill the brackets — replace anything in [BRACKETS] with your own details.
- Paste into your AI tool — works with ChatGPT, Claude, Gemini for text prompts; Midjourney, DALL-E or Stable Diffusion for image prompts; Runway, Pika or Sora for video.
- Iterate — tweak one bracket at a time until the output is exactly right.
Frequently asked questions
Should I refactor or rewrite legacy code?
Almost always refactor incrementally. Rewrites feel clean but discard years of bug fixes embedded in the ugly code — Joel Spolsky's famous essay exists because everyone learns this the hard way. This prompt plans the incremental path: strangler pattern, one seam at a time.
What if there are no tests at all?
Then step one is always characterization tests: tests that capture what the code <em>actually does</em> today (bugs included), so refactoring can't silently change behavior. The prompt plans this explicitly when you tell it tests are missing.
How do I convince my manager to allow refactoring time?
The prompt can generate the business case too: it identifies the concrete costs of the current mess (bug frequency areas, onboarding drag, change risk) and frames each refactor step by risk-reduction. “This 2-day refactor removes the thing that caused last month's outage” gets approved.
Can it handle really old languages like COBOL or PHP 5?
It can analyze and plan for them — the refactoring strategy (isolate, test, extract) is language-agnostic. Generated replacement code quality is best in mainstream modern languages; for exotic stacks, treat output as a plan to implement rather than code to paste.