Your business application still takes orders, issues invoices or runs an internal operation. But its original developer has moved on, updates feel risky, and a supplier has proposed a modernisation. Before comparing prices, you need to know what the work includes and how you will decide whether it succeeded.
Modernisation should make an existing application easier to maintain and change while preserving the business rules you still need. This guide is for the SME owner comparing a proposal. It follows five stages: audit, reference tests, controlled changes, acceptance and support. One question connects them: did the business behaviour pass the agreed checks, or did someone change the checks to make the report green?
Answer in 60 seconds
- Start with an audit that compares keeping, improving or replacing the application. Its age alone does not decide.
- Record the important business journeys before planned changes. Protect those reference tests from the agent implementing the changes.
- Contain exposed secrets immediately. Order the remaining work by risk and dependencies, rather than a universal runtime-first sequence.
- Accept the result against the agreed tests, data checks, recovery evidence and handover documents. Record exceptions explicitly.
- Compare proposals on these deliverables and responsibilities. An unspecified line in a quote leaves the scope unknown.
Before signing, ask the proposal to name the audit output, reference journeys, planned changes and recovery, acceptance evidence, and support owner. Those five items give you something concrete to compare before you discuss the total price.
In this article
- Audit the application before choosing the work
- Record the behaviour you need to preserve
- Change the application in controlled steps
- Accept the result against the evidence
- Define support before the handover
1. Audit the application before choosing the work
The audit should establish what runs, what depends on it, which failures matter and who holds the access. Ask for the runtime/library inventory, known vulnerabilities, deployment procedure, backups and critical integrations. An application can pass its own tests while its connection to stock or invoicing fails.
Check support against the project’s published calendar, such as the Node.js release schedule. End of life means the project stops its normal maintenance; any commercial extended support needs separate verification. An unscanned dependency is an unknown, not proof that a particular flaw exists.
Rank findings by business impact, identify urgent containment and compare realistic options: improve the application, replace a module, adopt a standard product or rewrite. Weigh business fit, supportability, transition risk and the cost of preserving behaviour. A new data model is one consideration, not the sole justification for rewriting.
If the audit recommends little or no development, its findings, options and bounded scope should still be useful. For the broader choice, see our technical-debt decision guide.
2. Record the behaviour you need to preserve
When specifications or tests are missing, characterization testing records what the code currently does. It does not establish that the behaviour is correct. The business owner must identify what should stay, what is a known defect and what should change.
Choose journeys with business consequences: an invoice calculation, refund, export or permission to view a record. Record inputs, expected outputs and who resolves ambiguity. If the agreed change includes a new invoice format, specify which values must remain equivalent rather than demanding identical PDFs.
Use a separate test environment and representative synthetic or anonymised data. France’s data regulator, the CNIL, describes a conditional exception for real data in preproduction when those fixtures are insufficient: earlier tests must have run, with security equivalent to production. Agree the data handling before copying anything.
Give the test set a recorded version, run instructions and an owner. Track security defects through separate checks in an authorised environment. Agree critical-journey checks before planned changes. Urgent containment needs proportionate validation without waiting for the whole suite.
3. Change the application in controlled steps
An exposed credential needs immediate attention. GitHub’s guidance starts with revocation or rotation; repository-history cleanup is separate. A runtime upgrade must not delay containment.
Sequence planned work using the audit: dependencies may require a newer runtime; tangled logic may need isolating first. Establish monitoring and recovery early, and deliver reviewable batches.
For each batch, specify purpose, affected journeys, validation and recovery. Pin dependencies and document the build environment: a supported runtime alone does not make a reproducible build. For data changes, specify reconciliation, incomplete records and recovery. Rolling back code does not automatically reverse a data migration.
Security fixes need acceptance criteria too. Password-storage changes must account for existing hashes, inactive users and resets; OWASP’s guidance describes upgrade approaches. Selecting an algorithm is only part of the work.
Where AI tools fit
AWS Transform custom documents analysis, transformations and validation commands. GitHub Copilot modernization describes assessment, planning, upgrades and test validation for supported stacks. Their contribution can span several stages.
These capabilities do not establish your project’s duration or success. Ask what applies, what will be checked and who accepts the result. An undocumented task is not necessarily an impossible one.
How IZZY separates making from checking
IZZY’s working rule separates making from checking. An orchestrator assigns work; the implementing agent must not edit the tests checking its changes. A separate agent, with another provider’s model and read-only access, reviews the result. Higher-risk changes receive more reviewing opinions.
Another provider can still share an error. Check review findings against the agreed acceptance evidence: agreement between agents does not establish that the application meets it. Our agent-control framework explains the wider boundaries around what an agent may change and prove.
In the last AI-built codebase we took over, the first real defect surfaced in production. That single observation is why we ask which business behaviour a passing report actually covers; it establishes no failure rate.
In our public Linkrypt repository, five reference cases make named inputs and fixed expected outputs inspectable. That is the practical detail to request from a supplier: a reference you can identify and compare. Linkrypt is a product example, not a client modernisation case.
A green report with the wrong total
Consider a hypothetical calculation, not a project result. Three amounts of 10,000, 2,500 and 750 cents should total 13,250 cents. Suppose a replacement omits the last amount and returns 12,500. If its expected result is also changed to 12,500, the check becomes green while the calculation remains wrong. The original reference would still reject it.
Ask the supplier: “Did you correct the calculation, or change the expected result?” Request the original reference, the application version and an explanation of any differences. If the business rule must change, approve it explicitly and review its revised checks separately.
One protected example is not enough to cover an application. Ask the technical reviewer to include representative inputs and inspect the changed code. A checksum can reveal that the reference changed; it cannot prevent edits or establish that the original reference was correct.
4. Accept the result against the evidence
Rerun the agreed checks and compare the meaningful outputs. Investigate differences; have the business owner approve deliberate changes. Recheck the original security findings within the tested scope, then rehearse restoration and recovery on the new setup. Compare performance on important journeys against an agreed baseline.
| Deliverable at acceptance | What it establishes | What it does not establish yet |
|---|---|---|
| Repository, hosting/CI access and required deployment credentials held by the owner | The owner holds the listed access and credentials | That their team has rehearsed deployment |
| Versioned reference tests, tested application version, instructions and dated results | How the agreed behaviour was checked and the recorded outcome | Coverage of every possible failure |
| Audit findings marked closed, accepted or deferred | What was addressed and which risks remain | Who will close deferred items, unless named |
| Completed and pending data migrations | Which records were reconciled and which remain | That every pending migration will finish automatically |
| Support calendar and update cadence | Known support deadlines and planned reviews | Who performs the work, unless assigned |
Keep this table with the acceptance record. A deferred finding needs a responsible person, review date and explicit risk acceptance. Repository access is useful evidence, but demonstrate that the receiving team can use it. Our codebase handover guide covers that transfer in more detail.
5. Define support before the handover
Agree who receives alerts, applies security updates and handles incidents after acceptance. List what is included, response arrangements, exclusions, reporting and the end-of-period decision. A defect correction and a new feature should not become the same support ticket by default.
Scope the outstanding work explicitly. Any continuing maintenance arrangement needs its own agreed responsibilities and onboarding conditions.
What should a legacy modernisation quote include?
The quote should connect the five stages to named deliverables and responsibilities: audit findings and options, reference tests, planned changes and recovery, acceptance evidence, and support. Choose one journey you know, such as issuing an invoice, and ask each supplier to trace it through those deliverables. The following is wording to request, not a client example:
Before changes, record and approve the reference calculation. Protect its checking tests from the implementing agent. For acceptance, provide the application version, test version, results, explained differences and separate review. Name who accepts any change to the reference.
Use the answer to decide:
- Clarify: “modernisation, testing included” names activities but leaves the journeys, evidence or responsibility unspecified. Ask for those fields; do not infer they are excluded.
- Hold: a critical result differs without explanation, or a changed test hides the failure. Resolve the behaviour and review the check before accepting that part.
- Accept the agreed scope: acceptance criteria were met, or documented exceptions were explicitly accepted by the accountable owner, and the receiving team can use the deliverables. This accepts the stated scope, not every possible property of the application.
Use the hypothetical calculation to discuss evidence with the supplier. A green report after changing the expected result calls for clarification, not automatic acceptance.
Bring us the application and the proposal
Start with the proposal and one business journey you must preserve. Our Rescue Missions & AI-Code Hardening service audits inherited codebases and scopes incremental remediation. For the technical assessment, agree what repository access and hosting information are needed. We quote against an agreed scope; new work is scoped separately.
Frequently asked questions
When the audit shows that its business value and supportability justify the transition cost and risk compared with the alternatives. Where suitable, incremental replacement lets parts move while the existing system continues operating.
Yes. Review their expected results against business rules. Protect the checks from the implementing agent, and review authorised changes to the reference separately. Passing generated tests alone does not establish correctness.
Request an estimate tied to the audited scope, integrations, test work, data migration and acceptance. Identify unknowns and review points. A tool demonstration or another project’s duration is not a schedule for yours.
Involve them in mapping dependencies and explaining unusual behaviour. Have the business owner confirm which rules still matter, and record that knowledge so it survives another handover.
Sources and limits
Technical sources checked on 16 October 2026. Research on shared model errors and a controlled code-review study support caution about model agreement; the latter improved results with one pairing and worsened them with the reverse. These settings did not evaluate IZZY’s workflow. ImpossibleBench observed test editing and other shortcuts on deliberately contradictory coding tasks; it does not measure ordinary-project failure rates. Its repository flags a later implementation bug; no replication is claimed. Linkrypt was inspected at the linked commit, without a fresh full-suite run or security audit. The arithmetic illustration is hypothetical. CNIL’s guidance concerns France. Founder statements recorded on 13 October support the IZZY policy and takeover observation. No transformation tool was benchmarked; quote wording is illustrative.