Migration and modernization
Understand before editing. Pin before changing. Prove before shipping.
Legacy code is where AI coding either earns trust or loses it. CodeLead's brownfield discipline is the one good engineers already use, mechanized: map the system, extract the rules and the tribal knowledge, pin current behavior where tests are thin, make the smallest change that honors the diagnosis, validate at the level the problem was observed, and land with the reasoning attached.
This is for you if
- A migration was attempted and stalled
- The engineer who understands the system retired, or is about to
- A security or compliance finding named the legacy stack
- An acquirer's diligence flagged technical debt
- An end-of-support date is on the calendar
- A cloud mandate is blocked by the one app that can't move
Why now
Standing still is the expensive option. So is the usual way of moving.
Almost nobody delays modernization because their system is fine: in one industry survey, only about one in twenty leaders said their current platform was adequate. They wait because the project itself is frightening, and the fear is rational. Studies put the failure rate of modernization programs between 70 and 79 percent, counting projects that blew their budget, missed their goals, or were abandoned outright.
Meanwhile the bill for waiting compounds. Legacy maintenance costs rise an estimated 10 to 25 percent a year as specialists retire and vendors sunset support, and most of the engineering budget goes to keeping the old system alive instead of escaping it.
Figures from third-party research, collected with sources in the research brief below.
- 70–79%of modernization projects miss goals, blow budgets, or are abandoned
- 60–80%of enterprise IT budgets go to legacy maintenance (Gartner, Forrester, Deloitte benchmarks)
- 10–25%annual growth in legacy maintenance cost as talent retires and support ends
- ~60%of breaches linked to outdated or unpatched systems (IBM Cost of a Data Breach, 2025)
Why projects stall, and what the Dossier does about each
| What kills projects | How it shows up | What CodeLead does first |
|---|---|---|
| Undocumented business logic | Decades of rules buried in code with no one left who understands them. Extraction failures surface as broken edge cases at cutover, or as the mid-project discovery that the rules can't be safely extracted at all. | The survey lifts the rules from code with file and line before anything moves, flags the ones enforced two ways, and books interviews with the authors while they are still reachable. |
| Scope set by the old system | Teams faithfully rebuild every legacy feature, including the share nobody uses, and the budget inflates to match. | The contracts catalogue and history intelligence show what is actually called, what changes together, and what has not been touched in a decade, so scope is a decision, not an inheritance. |
| Late testing | Testing bolted on at the end exposes data and behavior differences during cutover, often triggering rollback or abandonment. | Behavior is pinned with characterization tests before transformation, and every increment proves parity against the pins. Nothing is marked done that wasn't machine-checked. |
| The dual-run trap | Running old and new in parallel costs about 14 percent more per year during the transition. Cost rises for years before savings appear, and executive patience runs out first. | The wavefront moves modules in dependency order, in small verified increments, so each wave retires part of the old system rather than the whole program waiting on a big-bang cutover. |
| Talent shortage | Few people understand both the legacy stack and the target architecture, and the ones who understand the legacy side are retiring. | Tribal knowledge is captured into a knowledge base with a trust level and a citation, so it survives the people, and the tooling carries the mechanical work. |
| Tactical firefighting | Under pressure, teams abandon the plan and hardcode quick features on the new platform, building a new legacy system before the old one is retired. | Every change goes through the same gates and leaves an evidence record, on the old code and the new. The discipline does not relax when the deadline gets close. |
The successful minority in the research share a pattern: phased approaches over big-bang rewrites, scope set by business need rather than feature parity, honest accounting for the transition cost, and testing that starts before the change. That pattern is the Dossier's method.
Step one
The Legacy System Dossier
A read-only, fixed-fee assessment of one legacy system. Nothing is modified. CodeLead runs inside your environment or on a machine you control, and every action is logged.
In three to four weeks you know what the system is, what it depends on, which rules are hiding in it, what can be pinned and migrated safely, and in what order, with evidence for every claim. Success criteria are declared before we start. If we miss them, you do not pay the balance.
What makes it different from a slide deck
- Every figure traces to a named survey artifact: a scan, a log, a commit, or an attributed interview
- Each section is labeled Automated Partial or Manual, so you know what the tool measured and what a person judged
- Rules lifted from code are marked Inferred: they state what the code does, not why
- What the survey cannot see is marked as an assumption to confirm, never quietly filled in
- The same survey re-runs after each phase, so "after" evidence is in the same format as "before"
What you receive
- System inventory and architecture map
- Repositories, projects, modules, entry points, layering, and the call and dependency graph, with a one-page architecture narrative.
- Contracts and integrations catalogue
- Public API surface, database dependencies, external services, queues, file interfaces, scheduled jobs, and who breaks if each moves.
- Dependency and runtime lifecycle inventory
- Every package and runtime with version, support status, end-of-support dates, known advisories where resolvable, and breaking-change exposure on upgrade.
- History intelligence
- Hot files, co-change clusters (files that always change together), knowledge concentration by author, churn trends.
- Business-rule and tribal-knowledge inventory
- Rules embedded in code and comments (validation, pricing, workflow states, thresholds, magic numbers) with file and line, conflicts between comment and code, plus attributed testimony from your veterans.
- Testability and pinnability map
- Per area: what tests exist, what "green" actually verifies, how tangled the I/O is, and an honest judgment of how tightly its behavior can be pinned before any change.
- Migration-risk coding patterns
- Not a style review. Only patterns with a direct line to "you cannot safely transform this yet": shared mutable state, sync-over-async, hidden dependencies, swallowed exceptions, methods too long to characterize.
- Modernization wavefront and phased plan
- Which modules can move in isolation, which are coupled, a proposed sequence of waves, effort bands, and an exit criterion and proof step for every phase.
- Evidence appendix
- Every claim traced to its artifact, with an explicit automated-versus-manual label for each section and a stated confidence boundary.
- Browsable knowledge base
- A CodeLead project knowledge base seeded with all of the above, each entry labeled by how it was established: verified from code, inferred, or testimony. It stays with you.
How it works
-
Scoping call
Twenty minutes with whoever knows the system best. We agree on the one system, the questions you need answered, and the success criteria, in writing, before we start.
-
Read-only access, inside your environment
CodeLead runs on a machine you control, under NDA. It reads; it never writes. Every action is logged to a file you keep.
-
Survey, analysis, and interviews
Two to three weeks of tool-driven extraction, then conversations with the engineers who carry the tribal knowledge. Their testimony goes into the Dossier, attributed, and their "why" is attached to the rules the code only states.
-
Delivery and walkthrough
The written Dossier, an executive brief for the CTO and architects, the evidence appendix, and the knowledge base, walked through with your team. You keep everything.
Terms
- Fixed fee, quoted after the scoping call.
- Success criteria declared before work starts. If they are not met, you do not pay the balance.
- Read-only throughout; no changes to your repository, environment, or process.
- Each section of the Dossier states what was automated and what was done by hand.
- Founding-customer pricing for the first engagements, in exchange for a reference and case-study rights.
Stacks
.NET Framework, ASP.NET WebForms, VB.NET, and VB6-era systems first; Java and older Spring next. COBOL and mainframe cores are handled with a partner; the .NET estate around them is in scope.
After the Dossier
Modernization, one verified increment at a time
Pilot slice
One module from the Dossier's first wave. Behavior is pinned with characterization tests, the transformation is made in governed increments, and parity is proven against the pins. The deliverable is the migrated module, the parity evidence, and an exported evidence pack.
Program delivery
The wavefront, executed. Each wave has the same shape: clear the blocking patterns, pin, transform, prove parity, re-run the survey. Every change is a readable commit with its evidence record; nothing is marked done that wasn't machine-checked.
What stays behind
Modernization ends; governance stays. The knowledge base becomes the system's living encyclopedia, with every answer citing its proof, and the same gates keep the modernized code honest whoever, or whatever, changes it next.
Downloads
Read the sample Dossier and the research.
The full Meridian Dossier and its executive brief show exactly what you receive. The research brief collects the spend, cost-of-waiting, and failure figures cited on this page, with sources.
- Meridian Legacy Systems Portfolio Dossier The full engineering Dossier for the sample portfolio: three real .NET code bases surveyed read-only, with every figure traced to a survey artifact and each section labeled by provenance.
- Meridian Portfolio Executive Brief The short version for a CTO and lead architects, produced from the same artifacts: the decision, the three findings, the calendar, and the funding request.
- Application Modernization: Spend, the Cost of Waiting, and Why Projects Stall A research brief with sources: what companies spend on modernization, what standing still costs, the six ways projects die mid-flight, and what the payoff looks like for the ones that finish.
Common questions
We can't give an outside tool access to our code.
It runs on a machine you control, no code leaves the building, and the log is yours. The output is a report about your system, not your system.
We already use Copilot or Cursor.
Those generate code. The Dossier tells you what is true about the code you already have, with evidence, and which changes would be safe. Different job; you'll want both.
How much of this is automated?
In the sample portfolio, 58% by section weight: four sections fully automated, seven tool-measured and human-judged, two manual. Each section says which. Interviews and the validation strategy are human work the tool informs but does not perform.
Who does the work?
CodeLead does most of it; the founding engineers do the rest and tell you exactly which was which.
We'll do the migration later. No budget now.
The Dossier is valuable on its own. It is the document the acquirer, the auditor, or the new architect will ask for, and it makes any later migration cheaper to scope, with anyone.
Request a proposal
Tell us about the system.
What it does, roughly how old it is, what it's built on, and what's making the question urgent. We reply within one business day with either a scoping call or a one-page proposal.
Prefer to talk first? Book a 20-minute call or email hello@codelead.dev.