01
Skills define the work.
Each skill defines the task, required context, output format, checks, and completion conditions.
Capabilities Agentic Engineering
Code Modernization
A legacy codebase is a record of how the business learned to operate. It contains rules, exceptions, controls, and decisions that documentation has forgotten. AI lets us read that record at full-system scale. What matters is recovered, what should change is agreed, and the rebuild follows evidence rather than assumptions.
Provectus turns the business knowledge in your legacy code into new possibilities. We rebuild with your team to simplify processes and enable capabilities your old system held back.
Getting started
The system already contains the evidence needed to begin.
Recovering the documentation is part of the assessment. It does not need to exist up front.
-
Code
Read access to the repositories, build files, deployment configuration and schemas.
-
Evidence
Logs, traces, metrics and representative inputs, where they exist.
-
People
The people who run the system and own its outcomes.
-
Decisions
Someone named who can sign the rules, the scope and the acceptance criteria.
The path
Each step earns the next.
The order matters. Each step turns uncertainty into a reviewable artifact, and that artifact is the evidence the next step decides from.
01 · Understand
Make the system readable.
Recover what exists, how it connects, what runs, which rules the business depends on, and what only the people know.
What happens
- The readiness check. Can it build and test outside production, what must stay out of scope, and how big, tangled and risky it is.
- The map. Who calls whom, which data goes where, where the entry points are. User journeys in business language.
- Rule cards. One per rule, with source lines, priority and confidence. A second agent re-reads the cited code before a card is verified.
- Runtime truth. What actually runs: production coverage, logs, active tables. Dead code becomes scope you can drop.
- The people. Exceptions and manual steps that never made it into code. What they cannot settle becomes the short list of open questions.
Artifact
System record
- The readiness report, with a verdict
- The size and risk profile
- An interactive map of the system
- Rule cards and their data objects
- What runs in production, and what does not
- The short list of open questions
Decision
None. Each artifact stands on its own. Stop after any and keep it.
02 · Decide
Separate business value from legacy accident.
Sort the business rules that still matter from obsolete behavior, technical debt, and constraints the old architecture imposed.
What happens
- The rule decisions. Keep, change or drop on every verified rule card, and the rules to add. Signed by the people who own the outcome.
- The brief. Where the system is today, where it goes, why now, and the acceptance criteria.
- The pilot. One representative slice taken all the way through. The plan is expected to change after it.
- The price. Fixed for the pilot. The rest is priced from what the pilot shows.
Artifact
Decision brief
- Signed rule decisions
- The brief, naming the pilot, with its signature block
- A fixed price for the pilot
Decision
Nothing is generated until the brief is signed. Silence is not approval.
03 · Redesign
Design what the business needs now.
Turn the signed brief into a target specification and architecture, with a modernization option for each area of the system.
What happens
- The specification. What the system must do, assembled from the rule cards the brief keeps, changes or adds.
- What to leave behind. Nothing the brief dropped reaches the design: workarounds that became requirements, features nobody uses.
- The target architecture. Designed, then challenged by an adversarial review: over-engineering, missed requirements, simpler alternatives.
- The modernization options. Each area of the system is marked to uplift, rework slice by slice, reimagine from the specification, or retire.
- The delta catalog. For a same-stack uplift: the breaking changes this code actually hits, and whether the tests run on the target.
Artifact
Target specification and architecture
- The specification
- The target architecture, mapped to the legacy system
- The modernization option for each area
- The delta catalog, when it applies
Decision
Two gates: the specification first, then the architecture and options.
04 · Rebuild
Build one slice at a time, tests first.
Agents implement against the approved specification and architecture. Engineers review the code and the evidence at each gate.
What happens
- Characterization tests first. Current behavior pinned as reviewable input and output pairs, before any new code is written.
- Code from the specification. Generated against it, or the delta catalog for an uplift. Reviewed through your engineering controls.
- Pilot, then the rest. One slice start to finish, its lessons in a playbook, then the remaining slices in dependency order.
- The legacy system stays sealed. New code lives beside it. The rebuild never edits it, and it keeps running until the switch-off.
Artifact
Code and tests
- New code, with its tests and documentation
- Rebuild notes per slice: mapping, deliberate deviations, what was left behind
- The playbook
Decision
Tests approved before any code. The playbook before the rest.
05 · Prove and transition
Prove each slice before its cutover.
Each slice is proved and cut over on its own. The legacy system is hardened once, and switched off when the last slice has landed.
What happens
- Equivalence. The characterization suite runs green, on both runtimes where both exist. The record says which proof applies.
- Parallel run. Production inputs through both systems, ramped up to all traffic. No divergence, once the signed changes are excluded.
- Cutover. With a rollback that has been rehearsed.
- Hardening. Once, across the legacy system: vulnerable dependencies, secrets and injection risks, with a reviewable patch.
- Switch-off. When the last slice has landed. The legacy system is decommissioned and the record is closed.
Artifact
Proof and transition record
- The proof for each slice: equivalence and parallel-run results
- References to the system record, brief, specification, code and tests
- The security findings and hardening patch
- The cutover, with its rehearsed rollback
- The switch-off
Decision
The signed acceptance criteria, met and recorded for each slice.
The business case
An open-ended legacy problem becomes a controlled program.
Scope, decisions, implementation, and transition become visible before the legacy system is switched off.
- 01
A modernization scope that can be estimated.
The system map and rule cards show what must move, what can retire, and where the real risk sits.
- 02
Business rules no longer depend on individual memory.
Recovered from the code and from the people who run the system, they become a specification available for review and maintenance.
- 03
Every required behavior connects to a test.
Every change is signed in the brief before it is built. Every behavior that must survive is traced from source code to test.
- 04
A pilot before wider investment.
One representative slice goes all the way through before the rest is priced or built. The legacy system keeps running until the last slice has landed.
- 05
Documentation stays with the system.
Every artifact of the path, from the system record to the proof and transition record, stays with the organization in readable formats.
The framework
Provectus Agentic Modernization Framework
The methodology is executable.
A codified system of skills, agents, knowledge, and approval gates carries modernization from assessment to production transition.
02
Agents carry bounded tasks.
Specialized agents assess repositories, trace dependencies, recover rules, generate changes, and verify results.
03
Gates keep decisions accountable.
Agents produce evidence and options. Business rules, scope, architecture, and production acceptance remain human decisions.
Living system knowledge
System understanding remains connected as the work progresses, from original evidence to production proof.
- Source code
- System maps
- Business rules
- Decisions
- Specifications
- Tests
- Validation results
Every step adds to the knowledge base. The next step starts from reviewed evidence, not reconstructed context.
The toolkit
Different tools answer different questions.
Together, they turn source code, runtime behavior, and operational knowledge into a controlled rebuild.
Layer 01
Read the system
Establish what exists, how it connects, and what actually runs.
Static code analysis
Examines structure, dependencies, quality, and risk without running the system.
- Language-aware parsing and AST analysis
- Call graphs, complexity, duplication, and change impact
- Security, secrets, dependencies, licenses, and compatibility
Architecture recovery
Reconstructs the system beyond individual source files.
- Services, modules, and entry points
- Schemas, stored procedures, and batch jobs
- APIs, integrations, data lineage, and system seams
Runtime analysis
Separates deployed code from behavior that still matters.
- Logs, traces, queries, and job history
- Endpoint, feature, and production usage
- Recorded inputs, outputs, and dead-code evidence
Layer 02
Recover intent
Turn embedded behavior into material for business and engineering decisions.
Business-rule recovery
Extracts behavior into reviewable rules linked to its source.
- Calculations, validations, eligibility, and approvals
- Exceptions, lifecycle rules, and regulatory controls
- Source references, confidence levels, and open questions
Specification recovery
Creates the contract for redesign, implementation, and acceptance.
- Business capabilities and domain model
- Interfaces, data contracts, and required behavior
- Acceptance criteria and modernization plan
Layer 03
Change with proof
Accelerate implementation while keeping behavior and transition measurable.
Automated code change
Accelerates bounded implementation after the specification is approved.
- Dependency, runtime, API, and framework migrations
- Codemods and repetitive refactoring
- Code, test, and documentation generation
Behavioral validation
Compares required behavior before production responsibility moves.
- Characterization, contract, and regression tests
- Differential testing and recorded-input replay
- Shadow traffic, parallel runs, and data reconciliation
Transition controls
Moves production traffic only after explicit acceptance criteria are met.
- Migration and cutover rehearsals
- Acceptance thresholds and proof records
- Rollback and legacy-system decommissioning
Common questions
The questions every modernization starts with.
What is code modernization?
Code modernization is the structured analysis, redesign, rebuilding, and validation of legacy software. It can include runtime upgrades, refactoring, architecture changes, incremental rebuilding, business-rule recovery, testing, and production transition.
How is code modernization different from a rewrite?
A rewrite replaces code. Modernization first determines what should remain, change, or disappear. Different areas may be uplifted, reworked, reimagined from the specification, or retired.
Can AI recover business logic reliably?
AI can identify calculations, validations, decision branches, data usage, and exceptions across large repositories. Reliable recovery requires source references, confidence ratings, independent checks, runtime evidence, and domain review.
What if the legacy system has no tests?
Existing behavior can be captured through characterization tests, recorded input and output pairs, production traces, contract tests, and data reconciliation. That evidence becomes part of the specification.
Start with an assessment.
Establish the system boundary, recover the first dependency map, and identify a representative pilot.