Modernise the application. Keep the production database live.

The estate cannot stop, and it cannot stay

A legacy enterprise application is trapped between two facts. It cannot stay : the language pool is drying up, the vendor is winding the stack down, and every year of accreted logic is harder to change. And it cannot stop : it runs the business, and a modernisation that requires a pause, a data migration or a big-bang cut-over asks the business to bet itself on a switch being thrown correctly.

The way out is to remove the bet. Airtool connects to the existing production database and runs beside the legacy application, on the same live data — so the modernisation never becomes a single event the business has to survive.

Correlated risk becomes independent risk

Because both systems share one live database, a modernisation stops being a single bet that only pays off at cut-over. Each module is delivered, proven and put into production on its own — alongside the legacy application — and rolled back on its own if it is not right.

That is the central mechanical achievement of the method : it turns one large, correlated risk, where everything succeeds at cut-over or nothing does, into a sequence of small, independent, reversible ones. Value ships from the first module ; the business runs throughout.

Prove each module against the legacy one, on live data

Parallel operation on one database has a second benefit beyond low risk : it makes the modernisation verifiable. Because the modernised module and the legacy application read and write the same rows, every result the new module produces can be checked against the system it replaces — on real transactions, in production, before it takes over.

Modernisation stops being something you deploy and hope. Each module is proven against the behaviour it inherits, so the question at every step is not whether the code was translated correctly, but whether the new module matches what the business already does — answered on the data itself.

Why this order matters

Most modernisations get this exactly backwards. They start with the UI because the UI is what the customer can see. They build the screens first, then realise the business rules behind the screens have to come from somewhere. They translate the rules into application code, and translation is where institutional knowledge is lost.

Our order is the order in which value compounds. The schema is the least negotiable layer — we import it. The database logic is the most expensive to lose — we preserve it. Metadata is the highest-leverage layer — we author it once and the platform reuses it. The middle tier is the smallest deliberate surface area we can get away with. The UI is generated, so it costs nothing per screen.

Why the platform makes it possible

The methodology is not separable from the platform. Every layer depends on a specific Airtool capability that does not exist in generic application servers or visual-builder frameworks.

The schema importer depends on the metadata repository's multi-engine portability and its declarative table-object model. Database business-logic preservation depends on the schema compiler's SPL/trigger sequencing and per-object timestamp tracking. Metadata depends on the runtime's Redis-coordinated cluster cache and the supervised execution model. The middle tier depends on GraalVM Polyglot's controlled execution policies and the platform's standard library. The generated UI depends on the metadata model itself.

We do not sell modernisation as a service that happens to use a platform. We sell modernisation as the natural consequence of the platform's architecture — applied by the engineers who wrote that architecture.

What your modernised application will look like.

Airtool Apps — our own enterprise application suite — runs on the same platform the modernised version of your legacy stack will run on. Same metadata-generated UI, same supervised runtime, same OLTP and OLAP portability, same AI and MCP perimeter, same observability surface. Apps is the picture of what a finished modernisation looks like in production.

The implication for budgeting and planning is concrete : every platform-core capability — multi-tenancy, audit trail, row and column security, AI inside the perimeter, real-time observability — is inherited automatically by every form, every report, every module. Modernisation isn't translating your legacy stack into custom application code with these features rebuilt; it is lifting your schema and database business logic onto a runtime that already provides them.

Adoption stops being irreversible

The last question an enterprise asks about any platform is the fair one : what happens if we want to leave, or if the vendor does? The method answers it before it is asked. Because the application is metadata and the business logic lives in the database in open, standard languages, the assets that matter — the data, the schema, the logic, the documentation — are already yours, in forms you can read without us.

Continuity beyond that is a matter of contract, not hope : source escrow released on defined trigger events, and a source licence with a stable fork for internal use. Lock-in, addressed this way, stops being a fear and becomes a contract term — and the decision to adopt stops being irreversible, which is precisely what makes a prudent buyer willing to make it.