What legacy code migration actually costs in the AI era
Vendor lock-in was never really about the vendor. It was about the cost of moving the code. That cost just collapsed.
Rewind to 2024, before AI changed how we build software.
Back then, when a client asked us to take over software another studio had built, we never flatly refused. But we were upfront: this is going to be painful, and it will cost more than you're hoping. That was the honest read, not caution for its own sake. Taking over someone else's codebase was genuinely, expensively hard, and we knew it going in. Understanding it, refactoring it, reconstructing the documentation from the code could eat weeks before we shipped anything new. We priced that reality in, and plenty of clients decided it wasn't worth it. That cost was also the exact thing keeping you stuck with a vendor you'd outgrown.
The trap that keeps you with the wrong vendor
Look at that same moment from the client's side. A studio built something business-critical for you, and the relationship has gone sideways. Maybe the project outgrew them. Maybe it was one freelancer who no longer has time for you. Maybe they raised prices because they knew you couldn't easily leave.
So you decide to move. You call other studios. And you discover it is not that easy. Almost everyone is reluctant to take over existing code, for one or more of these reasons:
- They lack the domain knowledge the original team built up over years.
- The code is bad because it was written that way.
- The code is bad because it was transpiled or obfuscated, deliberately harder for anyone else to work with.
- There is no documentation.
Every one of those reasons is real. Understanding, refactoring, and documenting an unfamiliar codebase could take weeks before you shipped a single new feature. So you're told the honest thing: this needs a rewrite, and it will cost a lot. You go back to your original vendor, quietly stuck.
“The real vendor-lock is not a contract. It's actually the cost of moving your code. Not anymore.”
What changed
Here is the shift. In AI-driven development, documentation is everything, and documentation no longer has to be something a human sat down and wrote.
AI can read code, including legacy code it has never seen, and turn it into human-readable explanation. That one capability unlocks the rest. We can now:
- Generate domain documentation from the logic buried in a legacy codebase.
- Refactor bad code, whether it was written badly or transpiled that way.
- Move code onto a different stack.
- Generate technical documentation for the code itself.
The practical result: the cost of taking over a codebase dropped to a fraction of what it was. What was previously unreasonable to refactor (due to the high costs) is now completely unlocked.
For me, the bigger unlock was that we stopped being limited by stack. A system written in something we'd never shipped in is no longer an automatic no, because we can rewrite it into a more stable and familiar stack that we can maintain for years to come.
Why you can believe that
"AI makes legacy takeover easy" is exactly the sentence every agency is about to start saying. So here is what we actually do, because a workflow is harder to fake than a claim.
We document the domain before we touch anything. A human on our side has to understand what the system does and why, so we can make the judgment calls when the AI can't. We run a dedicated Claude skill across the legacy codebase that documents each module and its logic. The output is effectively a domain guide: the principles of the system, reconstructed from the code that implements them.
We split the work, then loop it through specialised agents. Refactoring or re-platforming runs as a structured process:
- Analyse the codebase and break it into modules, the functional groups of code. In a CRM, "Contacts" is a module.
- Break each module into concrete tasks: rewrite the contacts controllers, the models, the frontend. This splitting is itself part of creating the documentation.
- A human checks that the tasks are meaningful and the overall architecture holds up.
Then each task runs through a loop, with a separate agent for each job:
- one implements the task,
- one writes backend tests,
- one writes end-to-end tests,
- one reviews the result,
- one runs a parity check: the AI visually compares the refactored screen against the original and calculates the deviation.
Any agent in the loop can hand a task back to the implementer to fix what it found. We tune the allowed deviation deliberately, around 5% for example, because chasing a pixel-perfect match on margins and padding is a good way to loop forever for no real gain.
A human closes the loop. At the end we review the migration, walk through everything the agents flagged, and often spin up a few more tasks based on what we find before going back around.
Notice the shape of it: AI does the volume, humans own the judgment at both ends. That is the whole reason it produces something maintainable instead of a pile of plausible-looking code.
A recent one, which I'll keep vague because it's under NDA: an unfamiliar codebase of around 10 modules and roughly 50 screens, moved onto a completely different stack. Five days. Done the old way, understanding it, re-platforming it, testing every screen by hand, that is several months of work. That gap is the entire point.
Where it still bites
The honest limitation, and it is a real one: this workflow handles bad code well. It does not automatically handle wrong code.
If the legacy system isn't just messy but logically incorrect, a calculation that has been quietly wrong for years, the AI has no way to know whether that's a bug or your intended, if unusual, business rule. Left alone, it will faithfully carry the mistake into the new system. So before we refactor, we hunt for those gaps first: the miscalculations, the logic that doesn't add up. We fold the fixes into the tasks, so what comes out is correct, not a cleaner copy of the same error.
The takeaway
If you're staying with a vendor you've outgrown because moving feels too expensive, that math is out of date.
What used to be an expensive blocker, and a very effective form of lock-in, is now a manageable, mostly one-time cost. An old stack, unmaintainable code, a team that stopped caring: none of it has to be permanent anymore.
If you've got a codebase like that, we'll do a free audit, tell you honestly what shape it's in, and give you a price for taking it over along with the next steps. No rewrite-from-scratch reflex. Just an honest read on what it takes to get you unstuck. Let us know!
