FusionOne converts legacy systems — VB6, VBA, COBOL, legacy Java, jQuery-era web apps — into modern, maintainable stacks. AI does the translation. Our engineers verify every line. You pay a fixed price per module, backed by a behavioral-parity guarantee.
Uplift is our production pipeline. Every module passes through the same four stages — and nothing reaches you without a human engineer's sign-off.
We inventory your codebase, score each module's complexity, flag the risks (swallowed errors, SQL injection, GoTo spaghetti) and quote a fixed price per module. No estimates, no day rates.
Frontier AI translates each module into idiomatic modern code — preserving business logic exactly, including the quirks your business depends on. Every ambiguity is flagged, never silently decided.
Automated checks confirm function coverage, catch legacy idioms leaking through, and require a documented test plan before any human sees it. Failures go back, not forward.
A senior engineer reviews the side-by-side translation, the migration notes and the test results — then signs off. You only pay for modules that pass.
We run generated test suites against your legacy system and the modern replacement side by side. Same inputs, same outputs — including the undocumented behaviors your operation quietly relies on. A module isn't done (and isn't invoiced) until the tests prove parity.
Most legacy systems aren't one codebase. They're a web front end, an application server, and an Oracle or SQL Server database — with business logic hiding in all three. We never rewrite that in one big bang. We uplift it as one planned program, delivered in slices, with your system running the whole way through.
Classic ASP, JSP, jQuery-era screens — plus the validation logic quietly living in them. Translated screen-by-screen to a modern web stack (React + TypeScript), behind a routing facade so old and new pages coexist.
VB6/COM+ components, EJBs, servlets on WebLogic, WebSphere or IIS. This is the heart of the per-module pipeline: each service translated to Spring Boot or .NET 8, verified against the legacy behavior, signed off by an engineer.
In 20-year-old systems, a third or more of the real business logic lives in PL/SQL packages, stored procedures and triggers. We inventory it like any other code — your assessment tells you exactly how much is down there, before anyone touches it.
Three strategies, chosen on evidence, not ideology: keep it (modern services talk to the existing schema — lowest risk), hollow it out (stored-procedure logic translated up into the app tier, procedure by procedure), or replatform it (Oracle → PostgreSQL once the app tier is modern, ending the license bill). Your assessment recommends one per system, with the trade-offs in writing.
We inventory every module across all three tiers and map the dependencies — which screens call which services, which services call which stored procedures. You get a sequenced migration plan with a locked fixed price per module.
A routing layer goes in front of the existing system before anything is rewritten. From then on, legacy and modern components run side by side — there is no flag-day cutover, ever.
We migrate one business capability at a time — its screens, its services, its procedures — while both systems share the same database as the source of truth. Every slice is independently shippable, and independently reversible.
Same inputs through old and new; we reconcile the outputs and the resulting database state, row by row. A slice cuts over only when the evidence proves parity. The database moves last — or stays, if that's the right answer.
Your assessment defines the modules and locks the price for each before work begins. All prices in AUD, ex GST.
A module is one cohesive unit of your codebase — typically a single source file or functional component: a VB6 payroll calculation module, a reporting servlet, a data-entry form, a stock dashboard. During assessment, our analyzer splits your system into its modules, scores each one's size, complexity and risk, and assigns it a tier below. The module list — with a locked price beside every item — is in your assessment report before any migration work begins. A typical line-of-business system runs 40–150 modules.
Two weeks. We analyze your system across every tier — screens, services and stored procedures — and deliver a module inventory, dependency map, risk map, and a locked fixed-price quote for the full migration — the document your board can approve. 50% credited against your migration if you proceed.
90-day defect warranty included on every module, measured against the agreed test suite. Extended warranty and ongoing support retainers available. Private-cloud or on-premises pipeline deployment available for regulated industries.
Translation runs on Anthropic's Claude via API under commercial terms — API inputs are not used to train models. For regulated environments we offer pipeline deployment inside your own cloud tenancy, so code never leaves your perimeter. Either way, every engagement is covered by NDA and Australian-jurisdiction contracts. See our privacy policy for how we handle enquiry data.
One cohesive unit of your codebase — typically a single source file or functional component (a calculation module, a report, a form, a screen). Our analyzer identifies them mechanically during assessment and scores each for size, complexity and risk, which sets its pricing tier. The assessment report lists every module with its tier and locked fixed price, so the scope is mechanical, not negotiable-by-surprise. See the definition under Pricing.
Yes — it's the most common shape we see. PL/SQL packages, procedures and triggers are inventoried and priced as modules like any other code. Depending on your goals we either keep the database and integrate with it, translate the procedure logic up into the modern app tier, or replatform to PostgreSQL after the app tier is done. See how we uplift full applications.
Yes — deliberately. The pipeline preserves legacy behavior exactly and flags every ambiguity as a written migration note (for example: "tax rounds down to the cent — preserved; confirm intent"). You decide what changes; nothing changes silently.
That's what the parity guarantee is for: modules are tested against the legacy system as a golden master and aren't invoiced until tests pass. Defects against the agreed test suite within 90 days are fixed at our cost.
Assessment: two weeks. Migration: typically 2–5 modules per week once the pipeline is calibrated to your codebase — an order of magnitude faster than a manual rewrite, because AI does the translation and our engineers spend their time verifying instead of typing.
Tell us about the system. We'll come back within one business day with next steps.