Replace the framework, not the data tier.
The bespoke Spring, EJB, Struts and JSF applications that have outlived their architects — typically a mix of competent SQL, layered business logic and a custom framework that nobody quite remembers the assumptions behind — refactored so the data model survives, the integration contracts survive, and the framework is replaced by a supervised metadata-driven runtime.
The schema usually survives intact
Most bespoke J2EE applications carry a relational schema that has been designed and refined over years. The schema is imported as-is into the metadata repository; the platform recompiles it against the same target engine if appropriate.
SQL stays where it is
The hand-written SQL — and any stored procedures or triggers — moves with the schema. Business logic in the database tier is preserved. The platform reasons about it natively.
The framework is the problem
The Spring / EJB / Struts / JSF framework — and its accumulated configuration, custom annotations and forgotten conventions — is the part that no longer scales with the operator. It is the layer the platform replaces.
Integration contracts survive
The integration surface that the application exposes — REST endpoints, SOAP services, file drops, message queues, scheduled batch — is preserved as a contract. The platform's gRPC microservice mesh and integration layer carry it forward.
The five-layer methodology, applied to custom J2EE
The framework changes; almost everything else survives.
1 · Schema
The relational schema is imported into the metadata repository's table-object catalogue. Tables, indexes, sequences, constraints become rows the platform can recompile, against the same target engine or another.
2 · Database business logic
Existing stored procedures, functions and triggers stay. Business logic embedded in Java service classes is extracted and, where it belongs in the data tier (validations, derivations, transactional rules), moved into stored procedures and triggers. Where it belongs in the middle tier (orchestration, integration, AI), it is rewritten as server-side JavaScript on the platform.
3 · Domain model becomes metadata
JPA entities, Hibernate mappings, JSF managed beans and Struts action mappings are read and reified as metadata rows. The platform materialises the application surface — table objects, REST endpoints, screens, validations — from those rows.
4 · Batch and middle tier
Server-side JavaScript on the platform's GraalVM Polyglot runtime handles what was previously Java service code — integration, file handling, document generation, scheduled processing, AI orchestration. The platform's standard library (more than forty namespaces) replaces most of the third-party Java dependencies.
5 · UI
Generated from the metadata, on Vue 3.5 / Vuetify 4. The JSF / Struts / Spring MVC screens become responsive browser UI. Role-aware rendering, accessibility and mobile delivery are properties of the runtime, not features to be added.
What changes for the operator
Custom J2EE estates are usually competent at the database tier and showing their age at every layer above. The Spring or EJB framework was a good choice when the application was built; its custom extensions and forgotten conventions are now the dominant maintenance cost. Talent for the original stack is scarce; the framework itself is several major versions behind; and the integration surface is hard to extend without disturbing the rest of the application.
The migration preserves the data tier and the integration contracts entirely. What changes is the application tier: the Spring / EJB / Struts / JSF code is replaced by metadata that the platform interprets at runtime, and what remains of the middle tier is rewritten as server-side JavaScript on the platform's runtime. The team that delivers this is a database engineer, a Java-fluent analyst who can read the existing application, and a business analyst who knows what the business expects.
A typical custom J2EE migration vs an Airtool migration
| A typical migration | An Airtool migration | |
|---|---|---|
| Approach | Re-platform to a newer Java stack (Spring Boot, Micronaut) | ✓ Replace the framework with a metadata-driven runtime |
| Schema | Re-modelled where ORM conventions changed | ✓ Imported as-is into the metadata repository |
| Business logic | Re-written in the new framework's conventions | ✓ Database-tier rules preserved; middle-tier rules rewritten as server-side JavaScript |
| UI | Re-implemented in the new frontend framework | ✓ Generated from metadata at runtime |
| Integration contracts | Re-implemented; risk of breaking consumers | ✓ Preserved as platform-level contracts |
| Customer-side team | Java team experienced in the source and target stacks | ✓ Database engineer + Java-fluent analyst + our team |
| Outcome | A modern Java framework; the same architectural pattern; another migration in 7–10 years | ✓ A supervised runtime; AI- and integration-ready; no further framework migrations on the horizon |
Why custom J2EE estates benefit most from this approach
Bespoke J2EE applications are the modernisation case most often answered with "re-platform to a newer Java framework" — and the case where that answer leads to the same problem again in seven years. Each framework migration carries the same shape of risk: business logic translated, UI re-implemented, integration contracts redrawn. The estate that emerges is modern for a few years, and then it is legacy again.
Replacing the framework with a metadata-driven runtime breaks the cycle. The application stops being a Java codebase that has to be migrated and becomes a set of metadata rows the platform interprets. New requirements become metadata changes, not Java refactors. AI agents read the same metadata the runtime reads. The migration question, for the first time, has an answer that holds for more than one generation of frameworks.
What J2EE shops ask before they engage.
Why not just re-platform to Spring Boot or Micronaut?
A framework re-platform produces a modern Java codebase that becomes legacy again in seven to ten years — same shape of risk, same migration eventually. Replacing the framework with a metadata-driven runtime breaks the cycle : the application is no longer a Java codebase that has to be migrated, it becomes a set of metadata-repository rows the platform interprets. New requirements become metadata changes, not Java refactors.
What happens to JPA entities, Hibernate mappings and JSF managed beans?
They are read and reified as metadata rows. Entity definitions become table-object catalogue entries ; managed beans and Struts action mappings become REST endpoint and screen metadata. The platform materialises the application surface from those rows ; the ORM layer disappears because the runtime reads the same metadata repository the entities described.
Does the hand-written SQL and any database business logic survive?
Yes. Hand-written SQL, stored procedures and triggers stay with the schema and are preserved as a database-tier asset. Business logic in Java service classes is partitioned : rules that belong in the data tier (validations, derivations, transactional rules) move into stored procedures ; rules that belong in the middle tier (orchestration, integration, AI) are rewritten as server-side JavaScript on the platform.
What about the integration contracts we expose — REST endpoints, SOAP services, message queues?
Preserved as contracts. The platform's gRPC microservice mesh and integration layer carry the same REST and SOAP surfaces, the same file-drop and message-queue endpoints, the same scheduled batch jobs. Downstream consumers are unaffected ; the contract is honoured on the new runtime.
The original framework version is several majors behind — does the modernisation help with that?
The framework version disappears as a maintenance concern. The Spring / EJB / Struts / JSF code is replaced ; the platform's runtime is the supported, observed, currently-versioned tier from cut-over forward. Talent for the original framework is no longer a hiring constraint because the application is no longer expressed in that framework.
How does the platform handle the third-party Java dependencies the application currently uses?
Most of the common dependencies are no longer needed because the platform's standard library — more than forty namespaces covering database access, HTTP, cryptography, cloud APIs, AI / LLM, document generation, image processing, OCR and mail — replaces them. Where a third-party Java dependency is genuinely required (a specialised compute library, a vendor SDK), the platform's classloader isolation hosts it without polluting the runtime classpath.
Related modernisation stacks
The five-layer methodology is the same across source stacks. The port-mapping detail is what differs.
From Informix 4GL & Genero
Schema imports as-is, SPL stays in the database tier, 4GL forms and menus reify as repository metadata. Informix stays as the OLTP target — or lifts to PostgreSQL when the workload calls for it.
From Oracle Forms
PL/SQL stays in the database tier, Forms triggers reify as repository metadata, the Forms Server and Application Server licences go away. The Oracle database stays — or lifts to PostgreSQL.
From Delphi
VCL forms and DataModules become repository metadata, Pascal business logic moves to stored procedures and triggers, the thick-client install-and-maintain model disappears at cut-over.
From PowerBuilder
DataWindows preserved as metadata, PowerScript moves to the database tier and to server-side JavaScript on the platform runtime, EAServer and two-tier deployment removed.
From IBM i (AS/400)
DB2 for i schema imports through native DB2 connectivity, RPG and DDS reify as repository metadata, the 5250 green-screen surface becomes a browser. Stays on DB2 for i — or lifts to PostgreSQL.