September 26, 2026, (Inside AI) — Enterprises are discovering that AI-driven code modernization projects can collapse multi-year timelines into months, but the organizational scaffolding around those projects remains stubbornly human. Anthropic's forward deployed engineers, drawing on customer deployments, have published a six-step framework for preparing for these projects. The core insight: once AI agents accelerate code writing, the bottleneck shifts from producing changes to mobilizing the organization around them.
The guidance arrives as banks, insurers, and government agencies face mounting pressure to replace aging systems. Many run on unsupported runtimes with shrinking pools of engineers who understand them. A single unpatched vulnerability can trigger a breach or outage severe enough to threaten the business itself. Yet budgets remain hard to estimate, and inertia persists.
Anthropic's framework, detailed in a blog post, breaks preparation into six steps: define the target, define the certificate, set the promotion policy, put prerequisites in place, build the agentic workflow, and run the modernization. The company also released cost data from some of its large-scale modernizations, offering a rough baseline for enterprises weighing the investment.
Why consensus beats code
The first step, defining the target, often triggers internal debate. Engineers closest to production typically want the stack swapped with behavior held constant to contain risk. Others who have lived with the codebase want to pay down technical debt and fold in new requirements. Both positions are reasonable, but leaving the question unresolved resurfaces later as arguments over whether a given change is correct.
Anthropic recommends mapping the codebase and creating a behavioral specification. The company's code modernization plugin includes assess, map, and extract-rules commands that mine business rules with source citations. However, Claude's discovery alone may not capture how a legacy system fully behaves. Interviews with business users and developers, plus internal documentation, fill those gaps. Context gathering takes time upfront, but the quality of that context shapes every downstream decision.
Risk reduction, not cost reduction, drives most modernization projects. A system carrying unpatched vulnerabilities can mean a cyber breach or an outage severe enough to put the business itself at risk. An unsupported runtime or a shrinking pool of engineers who understand the system exacerbates the risk. When stakeholders disagree over how much risk a change can carry, the risk of not modernizing is the counterweight.
The certificate is the contract
The second step defines the certificate: the set of conditions or tests that every modernization change must meet. Each condition should be checkable without a human in the loop, so the agentic workflow can iterate until it meets the certificate or flag the change for human review. The certificate might include original test suite passage, Claude-authored tests, coverage thresholds, performance benchmarks, independent adversarial reviews by Claude in fresh context windows, and static analysis scans.
What the certificate checks against depends on the modernization type. For an uplift, parity is against the original codebase, and the original test suite can be the core. For a transform, the original test suite rarely runs on the new stack, so replay of production traffic, differential testing, and a prod-parallel deployment do most of the work. For a reimagine, the certificate anchors in the behavioral spec, the hardest case because a spec is less objective than an existing system to diff against.
Older systems often have thin test coverage, flaky tests, and little telemetry. Part of defining the certificate is identifying these gaps. If supporting a strong certificate will be difficult, one of the most useful things to do is use Claude to build the missing evidence, whether standing up a prod-parallel setup, building a replay harness, or writing more tests.
The third step sets the promotion policy: a tiered review path, written down and agreed in advance, that sets the depth of human review for a change. Agents will produce changes far faster than any human team can review them diff-by-diff. The policy should tier changes by blast radius and agent confidence, fix recurring flags at the source, design the output format with reviewers, and allocate subject matter expert time effectively.
In a regulated environment, taking a lighter human review path for any change can cause real discomfort. Individual approvers hesitate to sign off because they carry the risk of a bad change, while leadership carries the larger risk of an aging system. Anthropic recommends having the directive for the promotion policy come from the top of the organization and agreeing on it beforehand so responsibility for a bug that reaches production is shared, not pinned on whoever approved the change.
Prerequisites span teams outside the modernization: platform or infrastructure for the host, QA or release engineering for test capacity, security and compliance for approvals. Each team often has its own backlog or approval process, so conversations should open early. Requirements include a dedicated remote host, test capacity, production telemetry, a dependency map grounded in build and compile logs, a code-freeze policy if modernizing in place, a model access path approved for source code, least-privilege access for the agentic workflow, and traceability linking every change to an agent transcript and certificate evidence.
Building the agentic workflow starts with the code modernization plugin. Everything the workflow may need goes on the file system or over MCP, where Claude can reach it: the target, certificate, promotion policy, codebase, documentation, and required data sources. Subject matter experts review Claude's work, including codebase-specific skills or extracted rules, before anything downstream relies on it. Refinement happens by applying the workflow to small parts of the codebase, with SMEs reviewing the changes, the agents' process, and the evidence the certificate was met. Issues should prompt workflow modifications, not per-change fixes.
The final step runs the modernization end to end on a small part of the codebase, including reviewing and landing changes through the promotion policy. Fix anything that doesn't work while it's still cheap, repeat until confident, then scale. For an uplift, modernizing in place on the live codebase while development continues is an option when the system cannot be down. The approach splits the codebase into logical partitions from the leaves inward, freezes and modernizes one partition at a time, and gates CI/CD so new commits cannot undo a modernized partition.
Cost drivers include how much of the codebase must be read versus changed, how involved the certificate is, how much new test writing and repair the certificate demands, and how much reconciliation work comes from other teams merging around the run. Measuring token usage on a small pilot and extrapolating provides a cost floor. Measurements also show where to optimize the workflow. Anthropic suggests using models like Sonnet for mechanical, high-volume work the certificate fully checks, and keeping more intelligent models for hard transformations and adversarial reviews. Escalating to a more expensive model when a cheaper one fails to meet the certificate can work, but retry rates deserve careful analysis during piloting.
The modernized codebase is one output. The others are the workflow that produced it, a written certificate for what counts as correct, a promotion policy the change-management process has already accepted, and an evidence trail for every change that landed. Codifying the playbook as a reusable asset means the pattern is already in place for the next upgrade or rewrite. Anthropic's forward deployed engineers work through these steps with customers on their most critical systems, and the company invites enterprises preparing a modernization to contact its team.
