Legacy application modernisation
Move business-critical systems off Oracle Forms, PowerBuilder, Visual Basic, classic ASP and other ageing stacks, onto web and mobile platforms your team can maintain.
Keep the business logic. Lose the bottlenecks.
Behind most legacy applications sit years of rules the organisation depends on: how a loan is approved, how a licence is issued, how a salary is calculated. Those rules are the asset. The technology around them, from client-server screens to unsupported runtimes, is the liability.
We modernise legacy applications by recovering that logic, preserving the data and moving people onto modern web and mobile interfaces, one module at a time, so the organisation never has to stop working.
When it's time
01
The vendor has moved on
Oracle Forms 6i, Visual Basic 6, older PowerBuilder and Delphi releases, and the operating systems under them, are past end of support.
02
Users need the web and mobile
Client-server screens can't reach branches, field staff, partners or citizens on their phones.
03
Knowledge is leaving
The original developers have moved on, documentation is thin, and each fix takes longer than the last.
04
It blocks everything else
New channels, integrations and reports all wait on a system nobody wants to touch.
What we do
Code and rule recovery
Read the source, database triggers and stored procedures to document the business rules before anything changes.
Modern user interfaces
Replace client-server screens with responsive web and mobile front ends, designed with the people who use them every day.
Business logic as services
Move rules out of forms and triggers into services with clear APIs and automated tests.
Conversion where it fits
Use proven conversion tools for large, repetitive estates, with engineers reviewing and refactoring the output.
Data migration
Move years of records with mapping, cleansing, reconciliation and sign-off by the data owners.
Coexistence and cutover
Run old and new side by side, module by module, until the last user has moved and the old system can be switched off.
The strangler approach
Replace a system one piece at a time
Instead of a risky big-bang switch, new modules grow around the old system and take over one function at a time. A routing layer sends each request to whichever side now owns it, so users keep working throughout.
- The legacy application
- Its modules keep running until each one has a replacement.
- New services
- Built, tested and released one module at a time.
- The routing layer
- Sends every request to the right side, unseen by users.
How we modernise a legacy application
01
Understand
Inventory screens, reports, batch jobs and integrations, and document the business rules they carry.
02
Design the target
Choose the stack and architecture, design the user experience with users, and plan the order of modules.
03
Modernise in increments
Rebuild or convert one module at a time, test it against the old system's behaviour and release it to users.
04
Retire the old system
Migrate the remaining data, switch off old servers and licences, and hand over to your team.
What you get
- Documented business rules and data model
- Modern web and mobile front ends
- Services and APIs for the business logic
- Migrated, reconciled data
- Automated tests covering critical functions
- A plan to decommission old servers and licences
- Runbooks and a trained support team
Technologies
From
- Oracle Forms and Reports
- PowerBuilder
- Visual Basic 6
- Classic ASP
- ASP.NET Web Forms
- Delphi
- Visual FoxPro
- Java Swing and applets
- COBOL
To
- Java with Spring Boot or Quarkus
- Modern .NET
- Node.js
- React
- Angular
- Flutter
- PostgreSQL or Oracle Database
- REST APIs
Questions about legacy modernisation
Do you have to rewrite the whole application?
No. We decide module by module: some screens convert well, some are better rebuilt, and some can be retired because nobody uses them any more.
Our system is built on Oracle Forms. Can we keep the database?
Yes. Many Forms modernisations keep the Oracle database and its PL/SQL at first, and move the logic and data later only if there is a case for it.
Database modernisationHow do you make sure nothing is lost?
We capture current behaviour as automated tests and compare the outputs of old and new before each module goes live. Data owners sign off every migration.
Will users need retraining?
Some. We involve users from the start, keep familiar workflows where they work well, and provide training and guides with each release.
Tell us about the system you're stuck with
Which technology is it built on, who depends on it and what is pushing you to change it? We'll suggest a route and what the first module could look like.