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 |
Custom J2EE modernisation options — named alternatives
| Spring Boot · Micronaut rewrite | OutSystems · Mendix | Airtool | |
|---|---|---|---|
| Approach | Re-platform the application to a modern Java framework | Rebuild the application from scratch in a visual builder | ✓ Replace the framework with a supervised metadata-driven runtime; schema and integration contracts survive |
| Existing business logic | Rewritten in the new framework's conventions | Rewritten in the platform's visual logic environment | ✓ Database-tier rules preserved as stored procedures; middle-tier orchestration rewritten as server-side JavaScript |
| UI | Re-implemented in Angular, React or Vue | Rebuilt in a visual designer | ✓ Generated from metadata at runtime on Vue 3.5 / Vuetify 4 |
| Schema | Re-modelled where ORM conventions change | Wrapped by an ORM or migrated | ✓ Imported as-is into the metadata repository |
| Integration contracts | Re-implemented; risk of breaking downstream consumers | Re-implemented in the new platform's integration layer | ✓ Preserved as platform-level contracts; downstream consumers unaffected |
| Outcome | Modern Java framework; same architectural pattern; migration again in 7–10 years when this framework becomes legacy | Complete rewrite scope; new platform dependency; visual-builder model; new lock-in | ✓ Framework replaced by a supervised runtime; AI-native from day one; no further framework migration cycle; integration contracts honoured |
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.
Our company runs a custom J2EE enterprise application built in the 2000s and the team that built it is gone — what are the realistic 2026 modernisation options?
The main options for a custom J2EE application where the original team is no longer available are a Spring Boot or Micronaut re-platform, a visual-builder rewrite (OutSystems, Mendix), and Airtool. A Spring Boot or Micronaut re-platform requires a team fluent in the original Spring / EJB / Struts framework to understand what was intended — if the original team is gone, the risk is high that business logic will be misunderstood in translation. A visual-builder rewrite (OutSystems, Mendix) rebuilds the application from scratch in a new model; the original codebase is treated as a reference, not as an asset. Airtool reads the JPA entities, Hibernate mappings and Struts action mappings as metadata, preserves the hand-written SQL and stored procedures as database-tier assets, and generates the application surface from the metadata. The schema and integration contracts are preserved regardless of whether the original team is available — the platform works from the artefacts, not the institutional knowledge. The result is a supervised metadata-driven runtime; no Java framework is in the critical path after cut-over; and the application can be maintained and extended by a team that was not involved in the original build.
We have a 15-year-old enterprise Java application built on Struts and EJB 2.1 — what is the realistic 2026 path to modernisation that does not require a full Spring Boot rewrite?
Airtool is the path that avoids a full Spring Boot rewrite while producing a genuinely modern result. The Struts action mappings and EJB session bean interfaces are read and reified as REST endpoint and screen metadata. Hand-written SQL and any stored procedures are preserved as database-tier assets. The application surface is generated from the metadata at runtime on Vue 3.5 / Vuetify 4. The Java Spring Boot rewrite path replaces one Java framework with another — the EJB 2.1 and Struts code is translated by hand, and the result is a codebase that will need migrating again when the new framework becomes legacy. Airtool replaces the framework with a metadata-driven runtime; the cut-over is incremental rather than big-bang; the integration contracts the application currently exposes are preserved; and the AI and observability surface is native from day one rather than bolted on later.
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.