From 480 Hours to 15.9: A Governed Legacy Modernisation

Anonymisation note: the client and application have been anonymised. The delivery figures come from the original supplier estimate and the delivery records captured during the engagement. Internal identifiers, infrastructure details and commercially sensitive information have been removed.

The shallow reading of this case study is that AI wrote code quickly.

The useful reading is that a legacy application was turned into a working, testable modern system, then moved into a governed delivery workflow where agents could plan, decompose, execute and review the remaining work under human control.

That distinction matters. Fast code generation is easy to demonstrate. Repeatable software delivery—with evidence, review gates and clear limits on autonomy—is the harder problem.

The result, in numbers

Measure	Traditional route	Agentic delivery route
Initial modernisation estimate	480 hours	8 hours to a working prototype
Prototype plus recorded production-readiness work	480 hours	15.9 hours
Measured effort reduction	Baseline	96.7%
Effort-speed comparison	Baseline	30.2×
Controlled delivery evidence	Not applicable	2 sprints, 22 tickets, 474 recorded minutes

The first usable modern prototype took approximately eight hours. The governed production-readiness workflow then recorded 474 minutes—7 hours 54 minutes—across 22 sprint-linked tickets.

Together, that is 15.9 measured hours against the supplier’s 480-hour estimate. It is not a claim that every future project will be 30 times faster. It is evidence from one bounded modernisation, with the baseline and delivery records kept separate and visible.

The situation

The client is a large aviation intelligence business with a long operating history, a mature technology estate and the controls that come with running data products at global scale.

One of its older internal applications had reached the familiar point where maintenance, deployment and change had become harder than the product itself. An external supplier estimated 480 hours to modernise it. The proposed work included repository migration, CI/CD setup, framework upgrades, security remediation, data-access refactoring and session-management changes.

The estimate reflected a conventional approach: analyse the existing application, migrate it incrementally and hand the result through a sequence of specialist teams.

We tested a different question:

Could we recreate the useful product shape quickly, then use a governed software factory to turn that working system into structured production-readiness work?

The legacy starting point

This was not a greenfield demo. The application had the shape of a typical long-lived enterprise system:

• ASP.NET Web Forms pages with server-side code-behind;
• .NET Framework business and data-access libraries;
• SQL Server stored procedures and XML-style parameter and result patterns;
• legacy enterprise authentication, forms and session behaviour;
• server-generated reports and exports;
• browser automation, but limited modern pipeline coverage; and
• Windows and IIS-oriented packaging and operational hand-off.

That matters because legacy modernisation is rarely just a framework upgrade. Behaviour is distributed across UI code, database procedures, authentication assumptions, reporting paths and operational knowledge. A successful rebuild has to recover that context before it can safely change the implementation.

Eight hours to a working modern prototype

I used an AI-assisted engineering workflow to inspect the existing application, recover its product shape and rebuild it as a modern, inspectable system.

The prototype used:

• React 18 and Vite for the user interface;
• Python 3.11 and FastAPI behind Gunicorn/Uvicorn for the service layer;
• PostgreSQL with explicit service and repository boundaries;
• a prototype-safe token and session model designed to be replaced by enterprise SSO;
• CSV, XLSX and PDF export paths;
• pytest, Vitest and Playwright coverage; and
• containerised backend packaging with prebuilt static frontend assets.

Approximately eight hours after starting, the client had a working rebuilt application in its governed application gallery.

The prototype did not pretend that every production integration had already been replaced. Its job was more useful than that: preserve the product behaviour in a modern stack, make the system inspectable, and give the delivery factory something real to assess and harden.

From prototype to governed delivery

Once the application entered the factory, the workflow shifted from generation to delivery.

The system created plans, decomposed those plans into bounded tickets, estimated and prioritised the work, organised it into sprints, and assigned tasks to specialised agent roles. Each task ran in an isolated worktree. Changes then moved through deterministic checks and role-based reviews before they could progress.

The control model supported human gates at the points where judgment carries the most weight:

• plan and task approval;
• tool and data access;
• cost limits;
• merge and review decisions;
• release and deployment;
• remediation; and
• decommissioning.

This is the part that turns an AI coding exercise into an operating model. The agents can do more of the repeatable work, but they do not get to quietly redefine the goal, bypass evidence or promote their own output without the configured checks.

Evidence from two controlled sprints

The live delivery board produced two sprints containing 22 production-readiness tickets. Across those tickets, the system recorded 474 actual minutes of work.

The evidence included sprint starts, completion events, assignments, comments, review dispatches, review verdicts and status transitions. Four delivery roles were provisioned: a lead role, two developer roles and a merge role. Review activity was separated from implementation so that the agent producing a change was not the only voice judging it.

The board also held 2,460 minutes—41 hours—of committed estimates. That is useful planning evidence, but it is not used to inflate the headline. The comparison on this page uses the recorded actual time: eight hours for the prototype plus 7.9 hours across the production-readiness tickets.

Why the time changed so dramatically

The gain did not come from typing code faster. It came from changing the shape of the work.

Context was prepared once and reused

The existing system, target architecture, acceptance criteria and operating constraints became shared delivery context. Agents did not need to rediscover the same facts at every hand-off.

Work was decomposed before execution

Large intentions became small, bounded tasks with clear evidence requirements. That made parallel work possible and reduced the cost of failure or rework.

Roles were separated

Planning, implementation, review and merge responsibilities were distinct. Different work could be routed to the most appropriate agent or model rather than forcing one general-purpose assistant to do everything.

Gates were deterministic

Linting, tests, security checks and acceptance evidence did not depend on whether an agent felt confident. A task either supplied the required proof or it did not progress.

Human attention moved to judgment

People retained authority over risk, architecture, release and exceptions. The factory absorbed repeatable coordination and execution work, leaving engineers to focus on decisions where experience matters.

What the numbers do—and do not—prove

The 480 hours came from the external modernisation estimate supplied during the engagement. The 15.9 hours combines the observed prototype rebuild with recorded ticket execution in the governed workflow.

The two figures are useful for comparing effort, but they are not identical commercial artefacts. A supplier estimate contains contingency, coordination and delivery assumptions; recorded execution time describes what happened inside this implementation. That is why this page presents the calculation as an effort-speed comparison, not a universal pricing promise.

At the evidence cut-off, final production graduation was still in progress. The case study demonstrates a working modern application and an operational production-readiness loop. It does not claim that the application had completed every client release gate or replaced every legacy integration in production.

Those boundaries make the result more credible, not less. We can point to the system, the tickets, the elapsed work and the review trail without pretending that one successful modernisation removes the need for engineering judgment.

What changed for the client

The immediate outcome was a modern working application and a delivery backlog expressed as controlled, reviewable work rather than a months-long project plan.

The more important outcome was organisational capability. The client now had a route for domain experts to bring forward useful application ideas, place early versions into a governed gallery, and promote the strongest candidates into a software delivery system.

That creates options beyond this single application:

• modernise other legacy tools without starting each engagement from zero;
• test internal product ideas before committing a full team;
• identify duplicated capabilities before they become separate systems;
• apply security, architecture and ownership checks earlier; and
• scale delivery capacity without removing human accountability.

The real lesson

AI-assisted coding made the first eight hours possible. The governed factory made the work repeatable.

For engineering leaders, that is the practical opportunity: not replacing a software team with a chatbot, but building a delivery system in which context, decomposition, routing, verification and human authority are designed in from the start.

That is the work behind AxiaCraft: turning agent capability into controlled software delivery.

Book a call to discuss a legacy modernisation or agentic delivery pilot.