A stronger foundation
Move runtimes, frameworks, dependencies, and platforms forward through bounded campaigns with a clear target and a verifiable result.
Keep the logic.Move forward.
We modernize legacy software without losing the business logic inside it. Understand the system, make a bounded change, and prove it works.
One change. In context.
Understand the dependencies before touching the code. The business logic stays at the center.
Isolate one change. Define its boundary while the surrounding system stays intact.
Verify the change against the agreed behavior. Integrate it only when the evidence is there.
Or select a module in the diagram.
The work, made visible.
Explore a system map, a scoped change, and its verification report. This worked example uses a fictional commerce system, so you can see exactly what delivery looks like.
acme-commerce / codebase-passport
Payment contractCP-017 · changing
Reads the contract
- CheckoutIn progress
- RefundsQueued
- SettlementDeployed · reassess
Indirect dependency
- LedgerNot directly affected
- Entry points
- 3 HTTP services · 1 nightly batch job
- Data stores
- PostgreSQL 11 — orders, payments, ledger
- Build
- Java 8 · Maven · reproducible in a pinned container
- Baseline
- 412 tests pass · 3 known failures recorded with owners
- Open questions
- Rounding on partial refunds · currency of pre-2019 settlement rows
Every fact links to its evidence: a source file, a test, or a runtime trace. Hypotheses are marked as hypotheses.
CP-017 · explicit-money-contract
- Objective
- Replace the numeric payment amount with an explicit money value: integer minor units plus currency.
- Must preserve
- Endpoints and payloads seen by clients
- Authorization decisions
- Ledger events and their order
- One external effect per refund request
- Authorized differences
- None. Any change in behavior needs a recorded decision from the payments owner.
- In scope
- Checkout · Refunds · Settlement
- Excluded
- Hosting changes · settlement schedule · ledger schema
- Acceptance
- Contract tests for each consumer, replay of recorded refund cases, and reconciliation of sample settlement batches.
- Rollout
- Old and new contracts run side by side. The old one is removed only after every consumer has passed.
- Owners
- Payments maintainer (client) · Wiplogic delivery lead
WU-102 · refunds-adaptation
| Check | Result | Detail |
|---|---|---|
| Contract tests | Passed | 128 of 128 |
| Refund replay | Passed | 2,340 recorded cases · 0 behavior differences |
| Idempotency | Passed | Repeated requests produce one external effect |
| Settlement reconciliation | Not run | Scheduled after every consumer has migrated |
| Known baseline failures | Unchanged | 3 known, tracked separately, not counted as regressions |
Accepted for integrationReviewed by the payments maintainer (client), independently of the change's author.
A skipped check is never reported as passed.
Move what matters.
You don't have to replace the whole system. We start from the outcome you need and choose the smallest useful change. Larger transformations happen in stages.
Room to evolve
Untangle business logic, reshape coupled modules, and add new capabilities while preserving the behavior your customers rely on.
AI, put to work
Introduce agents into a disciplined engineering workflow your team owns: connected context, isolated execution, and independent verification.
Every change needs proof.
We classify every request by risk and evidence, not just by language, and agree up front on what proves it worked.
Runtime & dependenciesLanguage runtimes, frameworks, SDKs, and build tooling.
Language runtimes, frameworks, SDKs, and build tooling.
Proven by compatibility, a supported target runtime, preserved behavior, and deployable artifacts.
Example A framework upgrade may change date parsing or error handling even when the build passes. We check representative inputs and outputs around the affected behavior.
Bring the current build, a target version, known failures, and an owner who can judge the critical workflows.
APIs & shared contractsShared libraries, endpoints, events, schemas, and internal clients.
Shared libraries, endpoints, events, schemas, and internal clients.
Proven by a complete map of consumers and preserved semantics.
Example Changing a payment value affects every reader, not only the endpoint that writes it. We trace consumers, document the intended semantics, and check each affected boundary.
Bring the contract, known clients, representative payloads, and the domain owner for disputed behavior.
PlatformHosting, authentication, storage, messaging, and observability.
Hosting, authentication, storage, messaging, and observability.
Proven by target operational behavior, failure modes, deployment, and recovery.
Example Moving a service to new hosting can change authentication, retries, or message delivery. A deployable artifact is checked alongside operational behavior and recovery.
Bring deployment access, operational constraints, recovery expectations, and the person responsible for release.
ArchitectureModule extraction, coupling reduction, and subsystem replacement.
Module extraction, coupling reduction, and subsystem replacement.
Proven by business boundaries, cross-component contracts, and transaction semantics.
Example Extracting billing from a shared module changes ownership and transaction boundaries. We agree on those boundaries before moving code and check the surrounding workflows afterward.
Bring the next business outcome, module owners, transaction rules, and examples of current behavior.
Language reimplementationPL/SQL, COBOL, or other legacy logic moved to an approved target.
PL/SQL, COBOL, or other legacy logic moved to an approved target.
Proven by preserved business rules and side-by-side behavioral comparison.
Example Rewriting a calculation in a new language can preserve the formula while changing rounding or overflow. Recorded cases and explicit business decisions guide the comparison.
Bring representative inputs, expected outputs, business-rule owners, and a permitted target language.
DataSchema transformation, database replacement, and ownership changes.
Schema transformation, database replacement, and ownership changes.
Proven by reconciliation, consistency, cutover, and recovery.
Example Replacing a database involves more than copying rows. We check meaning, relationships, totals, and the point at which reads and writes move to the new system.
Bring data ownership, reconciliation rules, cutover constraints, and the recovery conditions your team requires.
Continuous evolutionBug fixes, small features, focused refactoring, and security remediation.
Bug fixes, small features, focused refactoring, and security remediation.
Proven by explicit intended changes, regression checks, and bounded scope.
Example A small refund fix still needs a boundary: repeated requests, authorization, and ledger effects may be involved. We prove the intended change and check nearby regressions.
Bring a reproducible case, the desired behavior, affected users, and an accountable reviewer.
Sometimes the right answer is to retire a system rather than modernize it. We'll tell you when it is.
Small changes. Clear proof.
AI makes writing code cheap. Knowing what a change touches, and proving the system still behaves, is the real work.
Discover
Map modules, behavior, and dependencies. Separate what we know from what still needs proof.
Codebase PassportDefine
Agree on scope, the behavior to preserve, authorized differences, and how acceptance will be judged.
Transformation contractDeliver
Each work unit runs in its own sandbox and branch. Agents never deploy or write to protected branches, and impacts on other work are traced.
Reviewable changeVerify
Acceptance is checked independently of whoever made the change. Decisions, diffs, and releases are recorded end to end.
Verification report
Start small. Go further.
Each stands on its own. Begin with Discovery, then expand once the first delivery has proven itself.
Discovery
Executable readiness
Suits
Teams that need a credible starting point or a modernization decision.
You provide
Repository and build access, an application owner, existing documentation, and known incidents.
You receive
- A Codebase Passport
- A runnable baseline, with existing failures classified
- A register of risks and open questions
- A first transformation contract
Complete when
Another engineer can run the baseline, see the existing failures, and understand exactly what a successful first change means.
Fast Track
Bounded campaign
Suits
A recurring change across one or more applications: a runtime upgrade, an API migration, a platform move.
You provide
A sponsor and domain owner, repository and CI access, reviewers for acceptance, and representative test data.
You receive
- Transformation contracts with executable acceptance
- Isolated, reviewable changes through your CI
- A verification report for every change
- Measured cost and reliability before expanding
Complete when
The agreed changes reach production with verification evidence, and every declared exception is resolved or listed.
Managed Delivery
Delivery program
Suits
Organizations running modernization as an ongoing program across maintenance, features, and upgrades.
You provide
Portfolio priorities, a budget, an accountable owner for each application, and release ownership.
You receive
- Reserved engineering and verification capacity
- Reusable, versioned recipes and verifiers
- Governance and budget reporting
- Regular outcome reviews
Complete when
Reviewed each period: accepted outcomes, cost, and quality against the objectives agreed for that period.
Timelines are set after Discovery, once the real state of the system is known. Data handling, model use, retention, and intellectual property are agreed in writing before work begins.
AI moves fast. Accountability stays human.
Engineering owns the outcome.
We bring AI into a disciplined engineering process: understand the system, agree on the change, and verify the result. Your team keeps ownership of the code, the decisions, and the release.
From the first conversation, you know who is accountable for the result.
What comes next?
Tell us about your system and what needs to change. Prepare your message, then open it in your email app to review and send.
Find your starting point.
Prepare a project brief first. It's created in your browser, so you can share it with your team, or send it to us when you're ready.