A Solo Legacy Migration with Claude Code: 95%+ API Coverage and Human Plan Reviews Before Every Phase
One engineer ran a real product migration POC with Claude Code as the primary development platform: 4 legacy repositories consolidated to 2, MySQL moved to PostgreSQL, Spring Boot 2→3, Java 17→21, React 17→18, auth model replaced, test suites built. At delivery: 95%+ API, 91% frontend coverage, zero bugs/vulnerabilities/security hotspots at QA handoff; ~15 work days, close to $5,000 in API tokens via AWS Bedrock. All figures are author self-reported; not independently verified by this site. Task: Posted on Apr 16 • Edited on Oct 25 • Originally published at karthiksubramanian.dev Most engineers using Claude Code are getting a fraction of its value. Not because the tool isn't capable — but because they're using it out of the box, unconfigured, the way you'd use a new IDE without installing extensions or setting up your build system. The default experience is decent. The configured experience is transformative. I lead a team focused on leveraging AI to find acceleration opportunities across the software development lifecycle. I've been playing around with AI tooling for a while and could see its potential, so I proposed a proof of concept: take a real product migration — the kind of project that would normally require a team of engineers across multiple sprints — and attempt it solo, using Claude Code as my primary development platform. Not "AI-assisted development" An AI-first model where every phase of the SDLC runs through Claude Code's feature set. The migration itself was substantial: 4 legacy repositories consolidated into 2, a database migration from MySQL to PostgreSQL, framework upgrades across the full stack (Spring Boot 2 to 3, Java 17 to 21, React 17 to 18), an authentication model replacement, and complete test suites for everything. What made this work wasn't Claude Code itself. It was how I set it up. The skills that made me effective at leading engineering teams — providing clear context, delegating with specificity, reviewing rigorously, building repeatable processes — turned out to be exactly the skills that make Claude Code most effective. Engineers whose day-to-day revolves around writing code by hand sometimes struggle with this shift because the instinct is to do the work yourself, not to set up the system and direct it. I'd spent years not writing the code myself. I was already an orchestrator. The medium changed, the model didn't. This post walks through how I configured Claude Code for a real migration, organized as building blocks. Each layer depends on the one below it. Skip the foundation and the rest falls apart. Building Block 1: Planning — Laying the Foundation Before any code was written, I built the context and planning infrastructure. This is the layer most people skip, and it's the layer that matters most. CLAUDE.md — The Master Context Claude Code reads CLAUDE.md files on every session start. They're your project memory — the equivalent of onboarding documentation for a new team member. I built a multi-level hierarchy: Workspace-level (181 lines): overview of all 25+ repositories, tech stack summary, cross-service architecture, shared build commands Domain-level: 18-service catalog, glossary of domain terms, JWT authentication architecture, service communication patterns Per-repo: service-specific conventions, module structure, testing standards, local dev setup Each level inherits from its parent. When Claude Code opens a session in any repo, it automatically has the full context stack — from the broadest architectural view down to the specific service conventions. This is the single highest-leverage thing you can configure. A well-written CLAUDE.md prevents Claude from re-exploring your codebase every session, asking questions you've already answered, or making assumptions that contradict your architecture. It's free, it's immediate, and it compounds over time. The Memory System Claude Code has a persistent memory system — files that survive across sessions. I built 17 memory files organized by type: User: who I am, my role, what I'm working on Feedback: corrections that become permanent rules Project: active work context, ticket maps, architectural decisions Reference: pointers to external systems (Confluence pages, Jira boards, SonarQube dashboards) The feedback memories are the most powerful. Every time I corrected Claude — "don't amend commits, it breaks CI and MR reviews" or "always fix all test failures before committing, even seemingly pre-existing ones" or "copy application-local.yml to worktrees because it's gitignored" — that correction became a permanent rule. One-time mistakes became permanent automation. After a few weeks, the memory system had captured dozens of workflow-specific rules that would take a new team member months to internalize. The Context Funnel For the planning phase itself, I fed Claude Code everything it would need to design the migration: The four legacy repositories (full source access); tools: Claude Code. Human role: - Review: a human reviews the plan before each phase executes; Oversight: large changes are synced to Confluence/Jira via comments. - The rest is as stated in the original post.; limitations: - Editing large Confluence pages had to go through comments rather than full-page updates (the author's stated "Confluence truncation lesson"). - The method leans heavily on upfront context engineering; the author's own premise was "I was already an orchestrator, not a hand-writer of code" — how well this transfers to engineers who write code by hand is unknown. - "Zero bugs at QA handoff" is a point-in-time state, not a production-running conclusion. - This site verified only that the source link is reachable; the outcome was not independently re-tested..
Tools
Published on Agent Work Atlas:
Overview
One engineer ran a real product migration POC with Claude Code as the primary development platform: 4 legacy repositories consolidated to 2, MySQL moved to PostgreSQL, Spring Boot 2→3, Java 17→21, React 17→18, auth model replaced, test suites built. At delivery: 95%+ API, 91% frontend coverage, zero bugs/vulnerabilities/security hotspots at QA handoff; ~15 work days, close to $5,000 in API tokens via AWS Bedrock. All figures are author self-reported; not independently verified by this site.
Workflow
Posted on Apr 16 • Edited on Oct 25 • Originally published at karthiksubramanian.dev Most engineers using Claude Code are getting a fraction of its value. Not because the tool isn't capable — but because they're using it out of the box, unconfigured, the way you'd use a new IDE without installing extensions or setting up your build system. The default experience is decent. The configured experience is transformative. I lead a team focused on leveraging AI to find acceleration opportunities across the software development lifecycle. I've been playing around with AI tooling for a while and could see its potential, so I proposed a proof of concept: take a real product migration — the kind of project that would normally require a team of engineers across multiple sprints — and attempt it solo, using Claude Code as my primary development platform. Not "AI-assisted development" An AI-first model where every phase of the SDLC runs through Claude Code's feature set. The migration itself was substantial: 4 legacy repositories consolidated into 2, a database migration from MySQL to PostgreSQL, framework upgrades across the full stack (Spring Boot 2 to 3, Java 17 to 21, React 17 to 18), an authentication model replacement, and complete test suites for everything. What made this work wasn't Claude Code itself. It was how I set it up. The skills that made me effective at leading engineering teams — providing clear context, delegating with specificity, reviewing rigorously, building repeatable processes — turned out to be exactly the skills that make Claude Code most effective. Engineers whose day-to-day revolves around writing code by hand sometimes struggle with this shift because the instinct is to do the work yourself, not to set up the system and direct it. I'd spent years not writing the code myself. I was already an orchestrator. The medium changed, the model didn't. This post walks through how I configured Claude Code for a real migration, organized as building blocks. Each layer depends on the one below it. Skip the foundation and the rest falls apart. Building Block 1: Planning — Laying the Foundation Before any code was written, I built the context and planning infrastructure. This is the layer most people skip, and it's the layer that matters most. CLAUDE.md — The Master Context Claude Code reads CLAUDE.md files on every session start. They're your project memory — the equivalent of onboarding documentation for a new team member. I built a multi-level hierarchy: Workspace-level (181 lines): overview of all 25+ repositories, tech stack summary, cross-service architecture, shared build commands Domain-level: 18-service catalog, glossary of domain terms, JWT authentication architecture, service communication patterns Per-repo: service-specific conventions, module structure, testing standards, local dev setup Each level inherits from its parent. When Claude Code opens a session in any repo, it automatically has the full context stack — from the broadest architectural view down to the specific service conventions. This is the single highest-leverage thing you can configure. A well-written CLAUDE.md prevents Claude from re-exploring your codebase every session, asking questions you've already answered, or making assumptions that contradict your architecture. It's free, it's immediate, and it compounds over time. The Memory System Claude Code has a persistent memory system — files that survive across sessions. I built 17 memory files organized by type: User: who I am, my role, what I'm working on Feedback: corrections that become permanent rules Project: active work context, ticket maps, architectural decisions Reference: pointers to external systems (Confluence pages, Jira boards, SonarQube dashboards) The feedback memories are the most powerful. Every time I corrected Claude — "don't amend commits, it breaks CI and MR reviews" or "always fix all test failures before committing, even seemingly pre-existing ones" or "copy application-local.yml to worktrees because it's gitignored" — that correction became a permanent rule. One-time mistakes became permanent automation. After a few weeks, the memory system had captured dozens of workflow-specific rules that would take a new team member months to internalize. The Context Funnel For the planning phase itself, I fed Claude Code everything it would need to design the migration: The four legacy repositories (full source access)
Reported result
- At delivery: 95%+ API coverage, 91% frontend coverage; zero bugs, zero vulnerabilities, zero security hotspots at QA handoff. - The author says AI caught about 30–40% of issues (low-to-mid-severity ones humans miss under time pressure). - End of POC: about 50 tickets, 580 passing tests; roughly 15 work days; close to $5,000 in API tokens via AWS Bedrock. (All from a single self-reported case with no control group; not independently re-tested by this site.)
Human role
- Review: a human reviews the plan before each phase executes; Oversight: large changes are synced to Confluence/Jira via comments. - The rest is as stated in the original post.
Limitations
- Editing large Confluence pages had to go through comments rather than full-page updates (the author's stated "Confluence truncation lesson"). - The method leans heavily on upfront context engineering; the author's own premise was "I was already an orchestrator, not a hand-writer of code" — how well this transfers to engineers who write code by hand is unknown. - "Zero bugs at QA handoff" is a point-in-time state, not a production-running conclusion. - This site verified only that the source link is reachable; the outcome was not independently re-tested.
Try it
Act as an engineering orchestrator using Claude Code to migrate a legacy application. Inputs: [Source Repos], [Target Stack], [Database Schema]. Steps: 1. Generate multi-level CLAUDE.md files for workspace, domain, and repo context. 2. Configure persistent memory for feedback rules. 3. Use Atlassian MCP to create Jira tickets from design docs, but manually link dependencies. 4. Execute migrations in parallel git worktrees, reviewing plans before code generation. 5. Use SonarQube MCP for quality gates. Deliverables: Migrated code, updated docs, and test reports. Measure success by test coverage and bug count. Handle errors by reverting to manual updates if MCP truncates content. Require human approval for all architectural changes and before merging to main.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.