Modernise legacy software into an intelligent working system

Illustrative scenario: the distributor, application and planned changes below are fictional. No customer outcome or measured improvement is reported.

Start with the change the business needs

An ordering application may still do valuable work while making a new supplier, integration or reporting requirement difficult to deliver. Modernisation starts by connecting that difficulty to a useful business change. The age of the software alone does not decide what should happen.

Consider a fictional distributor whose staff prepare orders in an existing application. Supplier catalogues use different descriptions for similar products, so staff repeatedly interpret records and match them to the internal catalogue. An older import component makes changing that work difficult.

The proposed delivery modernises that boundary and adds an intelligent catalogue workflow. AI interprets agreed supplier records and proposes normalised fields and product matches. Routine items that meet agreed rules can update the catalogue automatically; uncertain mappings reach the catalogue owner. Existing pricing and order decisions keep their agreed scope.

Find out what the existing application actually does

Collect the source, dependency versions, build instructions and deployment configuration that the team is authorised to use. Map how the import reaches product records, who consumes them and which supplier interfaces or licence conditions constrain a change. Record missing evidence rather than fill it with assumptions.

Run the existing build in a suitable test environment. Follow representative imports with the person who knows the catalogue: a valid file, a malformed record, a duplicate product and an interrupted run. Capture outputs, warnings and downstream effects on order entry. Agree which observed behaviour should remain and which existing defect should change.

AI can help explain unfamiliar code, suggest call paths and organise documentation. Check those suggestions against the repository, runtime evidence and the people who operate the application. If the baseline cannot be reproduced, making it reproducible may be the useful first delivery.

Choose the smallest change that addresses the obstacle

A security update addresses a specific exposure and needs its own urgency assessment. A dependency upgrade changes a library or framework and its compatibility assumptions. Replatforming changes where or how the application runs. Redesigning a business process changes the work itself. A project may need one of these before it needs the others.

For the distributor, examine whether a supported library upgrade or an adapter can provide a stable boundary for the new capability. Retain useful ordering behaviour while changing the selected component. The AI task needs its own evaluated inputs and matching rules; a dependency upgrade alone does not deliver it.

Microsoft’s Strangler Fig guidance describes gradual replacement through boundaries that can route work between existing and new functionality. The approach depends on those boundaries and carries temporary integration costs. It is an option to assess, rather than a required architecture for every application. Related reading: Microsoft — Strangler Fig pattern

Let the system handle routine catalogue work

For the fictional workflow, agree which supplier records the system will accept and which internal product information it may use. AI interprets descriptions, normalises candidate fields and proposes product matches. Evaluate representative inputs, including similar names, missing identifiers and conflicting units. Supported formats and acceptable matching behaviour are part of the chosen scope.

The application checks required fields, product identity, allowed changes and duplicate handling. When the agreed checks pass, it can write an authorised routine update and record the result without a person approving every item. An ambiguous match, an unexpected change or a failed write goes to an exception queue with the source and proposed mapping. An AI confidence score alone does not authorise an update.

For this proposed slice, the application’s product record remains authoritative. Agree writable descriptive fields, such as the normalised description and supplier reference, before implementation. Prices, order commitments and unapproved field changes are outside this routine action. Evaluate semantic matches with catalogue examples as well as format checks.

Give the catalogue owner one view of completed updates, exceptions and action history, plus a way to correct a mapping or pause automation. The intended benefit is faster catalogue availability with less repetitive preparation, leaving people to address important product decisions. Measure handling effort, response time and correction rates against the starting process before reporting gains.

Figure 1 as text

AI interprets agreed supplier records, normalises candidate fields and matches products against authorised catalogue context. Evaluated matching rules, field validation and permissions determine which routine descriptive updates may be written to the application’s authoritative product record without per-item approval. Model confidence alone is insufficient. Uncertain or conflicting matches, unexpected changes and failed writes go to the catalogue owner with source and history. People can correct exceptions and pause the flow. Pricing and order commitments are outside these routine writes. Existing ordering remains a downstream dependency to test. We apply AI where it makes a useful difference, with defined context, architecture and checks. A separate Devmojos method lane shows useful AI and defined context, architecture and scoped actions, then tests, review and controlled evolution.

The Devmojos method: context, architecture and visible checks

We build this capability with AI assistance through the Devmojos delivery process. The harness gives coding agents the selected task, relevant code and contracts, representative examples and explicit permissions. Agents propose changes, tests and documentation; engineers examine the actual results and decide release acceptance. This delivery method is separate from the AI interpreting catalogues in operation.

A generated test can repeat the same mistaken assumption as generated code. Compare both with independently chosen examples and expected results. Run the appropriate dependency, compatibility and security checks for the stack. OWASP Dependency-Check, for example, examines dependencies for known publicly disclosed vulnerabilities; that scope does not establish the security of the whole application.

Record how much useful work the assistance produces, including review and repair. An accepted change provides evidence for this application and scope. Claims about faster delivery or lower total cost need a comparable baseline and the relevant effort and operating costs. Related reading: OWASP — Dependency-Check

Clear tasks and reusable context aim to reduce rework and shorten the path to a useful delivery. Tests and independent review provide quality evidence; scoped permissions and appropriate security checks support control and security. Modular interfaces, documented decisions and workload tests help plan future development and scalability. Compare implementation, review, model and operating costs before claiming a more economical result. Ordinary software handles the steps that do not need AI.

Build one complete import slice

Prepare the intelligent import in a test environment with authorised representative data. Test field extraction and product matching separately from validation and record writes. Include a routine item that proceeds automatically and an uncertain match that must reach a person. Verify duplicate handling, rejected inputs and downstream order-entry behaviour.

Agree what happens when a run stops halfway through. Some systems can commit an import as a single transaction; others require resumable work or explicit reconciliation. The implementation must fit the actual application and data model. Decide which records are authoritative and how partially processed work is identified.

Connect each agreed example to its actual result, including wrong matches, unintended updates, exceptions and operator corrections. Check that a person can understand why an update happened and stop the flow. The business owner and engineering lead accept the chosen capability from this evidence.

Plan release and recovery around the real change

Rehearse the release steps and agree who can pause the import, who checks the results and how staff continue their work if the change is held. A limited rollout may be useful when the system can separate a representative part of the work. Choose signals that can expose a failure in the changed behaviour.

Google’s SRE guidance describes a canary as a partial, time-limited deployment evaluated before proceeding. Its usefulness depends on representative traffic and meaningful signals. A small sample or a quiet period can miss an important problem.

Distinguish restoring the previous code from recovering data already written. An old binary may be unable to read a changed schema. Restoring a backup may discard later valid work. Plan the required compatibility, restoration, replay or compensating action before changing production data; test the procedure where feasible. Related reading: Google SRE — Canarying releases

Figure 2 as text

Two related decisions need separate evidence. First, can the previous code operate with the current data and schema? Second, how will records already written be recovered or reconciled? Depending on the actual change, the plan may require compatibility work, restoration, replay or a compensating action. Restoring a backup can remove later valid work. The recovery procedure is chosen for the application and tested where feasible. A separate delivery lane shows task/code/interface context, AI-proposed changes and tests, then tests, review and an engineer’s release decision. It explains how the intelligent capability is built; it is not an automatic recovery operation.

Use the first delivery to decide what follows

Hand over the changed component, reproducible build, relevant tests and release/data-recovery procedures. Include the operating view, exception rules, model/input dependencies and authority to pause or resume processing. Usable documentation and direct control can reduce dependence on a supplier for everyday adjustments; model, software and platform dependencies still need an owner.

The next decision may be another component, an ordinary update or retaining the application as it stands. Pause a proposed migration when access, integration ownership or recovery evidence is missing. A working system with a modest change need may justify a much smaller intervention than a rewrite.

Bring one application and the change you need

For a first discussion, identify the application, the change it is blocking and the people who use and maintain it. Note the available source and build access, important integrations, known dependency constraints and acceptable continuity window. Keep credentials and sensitive production data out of an introductory email.

Devmojos connects staged modernisation to a useful intelligent capability in the application your business already relies on. A defined first delivery and reusable components aim to keep costs accessible while creating room to adapt products, processes and services. Assessment is used where needed; a clear scope can proceed directly. AI Engineering can support your own delivery team, and continuing operation is separately agreed.