Replace PowerBuilder, preserve the application logic that runs the business.
The PowerBuilder estates that still operate enterprise functions — with their DataWindows, PowerScript event handlers and decades of layered business rules — migrated to a metadata-driven runtime. The data model is imported; the rules return to the database tier where they belong; the application surface becomes metadata.
DataWindows have value — and are preserved as metadata
The DataWindow is the most useful structural concept in the PowerBuilder estate. Its query definition, presentation layout, validation rules and update logic are read and reified as repository metadata — preserving the design intent while making it framework-portable.
PowerScript moves to where it belongs
Embedded PowerScript — event handlers in windows, controls and DataWindows — is extracted. Business rules move to stored procedures and triggers in the database; UI behaviour becomes metadata or server-side JavaScript on the platform runtime.
No more EAServer or two-tier deployment
The three-tier EAServer model and the two-tier thick-client model both go away. The platform's supervised JVM-class runtime serves browser clients, eliminating both the application-server licensing and the per-workstation install-and-maintain overhead.
The schema survives
Whether the underlying database is Sybase, SQL Server, Oracle or another engine, the schema is imported into the metadata repository. The data model — typically the most valuable artefact in a PowerBuilder estate — survives entirely.
The five-layer methodology, applied to PowerBuilder
From the data model outward. Each layer is independently deliverable. Cut-over is incremental.
1 · Schema
The relational schema is imported into the metadata repository's table-object catalogue. Tables, indexes, sequences, constraints, full-text indexes become rows the platform can recompile, against the same target engine if appropriate.
2 · Database business logic
Existing stored procedures and triggers in the database stay. Business logic embedded in PowerScript — at the window, control, menu and DataWindow level — is extracted, normalised, and moved into the database tier where the platform expects business logic to live.
3 · DataWindows and windows become metadata
DataWindows are reified as a combination of query metadata (their data source), view metadata (their presentation layout), validation metadata (their column rules) and update metadata (their write-back logic). Windows and menus port similarly. The platform materialises the application surface from these rows.
4 · Batch and middle tier
Server-side JavaScript on the platform handles what PowerBuilder applications (or scheduled PB executables) once handled — integration, file handling, document generation, scheduled processing, external API calls.
5 · UI
Generated from the metadata, on Vue 3.5 / Vuetify 4. The PB windows and DataWindow grids become responsive browser UI. Role-aware rendering, accessibility and mobile delivery are properties of the runtime.
What changes for the operator
PowerBuilder estates are usually a hybrid: a data model the business trusts, a substantial amount of business logic already in stored procedures, and a layer of presentation-and-rules logic in PowerScript that has accumulated over many releases. The migration preserves the first two and refactors the third — moving rules into the database tier where they enforce themselves transactionally, and reducing the presentation layer to metadata the platform can interpret.
The team that delivers this is a database engineer who can read the existing schema and stored procedures, a PB-fluent analyst who can read DataWindow definitions and PowerScript, and a business analyst who knows what the business expects. The methodology is methodical extraction, not greenfield design.
A typical PowerBuilder migration vs an Airtool migration
| A typical migration | An Airtool migration | |
|---|---|---|
| Approach | Re-write in .NET, Java, or a web framework | ✓ Move logic to the data tier; generate the UI from metadata |
| Schema | Re-modelled to fit the target framework | ✓ Imported as-is into the metadata repository |
| PowerScript logic | Translated into the target language | ✓ Extracted into stored procedures, triggers and metadata rules |
| DataWindows | Re-built by hand as grids and forms in the target stack | ✓ Reified as query / view / validation / update metadata |
| Windows and menus | Re-implemented per the target framework's conventions | ✓ Imported as metadata; runtime materialises them |
| Customer-side team | Full-stack developers, PB domain experts as advisors | ✓ Database engineer + PB-fluent analyst + our team |
| Cut-over | Big-bang at the end of an extended project | ✓ Incremental, module by module, parallel run |
Why PowerBuilder estates are worth migrating now
PowerBuilder is a productive development platform that, for the customers still running it, encodes years of fit with the business. The pressure to migrate is rarely about the platform's capabilities and almost always about the operational reality around it — talent scarcity, deployment friction, integration limitations, and the difficulty of layering modern AI and analytics on top.
The platform-modernisation approach is to preserve the parts that work (the data model, the business logic in the database, the structural design of the DataWindows) and replace the parts that limit the operator (the thick-client deployment model, the lack of integration surface, the inability to deliver responsively to mobile). The result is a system that runs in a browser, integrates natively, and can host AI agents against the same data it has always trusted.
What PowerBuilder shops ask before they engage.
Does the modernisation force a database change?
Not for the engines the platform already targets. PowerBuilder estates running on SQL Server, Oracle, Informix or DB2 import their schema as-is into the metadata repository and continue on the same engine if the existing operational depth justifies it. Sybase ASE (now SAP ASE) is the exception — it is not in the platform's seven-engine OLTP matrix, and the supported migration path re-platforms it onto SQL Server (the natural lineage-compatible target) or PostgreSQL (the modern, open default). Either way the database business logic ports as part of the same engagement.
What happens to the PowerScript that accumulated over the life of the application?
PowerScript embedded in windows, controls, menus, user objects and DataWindows is extracted, classified by responsibility and split into two destinations. Business rules — validation, derivation, cross-record consistency, audit-logic — move to the database tier as stored procedures and triggers, where transactions enforce them and the platform's compiler reasons about them. UI-orchestration logic — what to show after which event, conditional enablement, navigation flow — becomes metadata on the platform's UI model or, where the behaviour is genuinely procedural, server-side JavaScript on the supervised runtime. The platform helps automate the classification where PowerScript follows recognisable patterns.
How do DataWindows actually port — they are the most valuable structural concept in the estate?
A DataWindow carries four concerns inside one artefact : a data source (the underlying query), a presentation layout (the column order, headers, widths, alignments), a validation surface (the per-column rules) and an update behaviour (the write-back logic and concurrency strategy). Each concern reifies into its own metadata family in the repository — query metadata, view metadata, validation metadata, update metadata. The runtime materialises the DataWindow's behaviour from those rows on Vue 3.5 / Vuetify 4 components, with the column rules, sort, filter and update semantics preserved. The structural design that made DataWindows the best part of PowerBuilder survives the migration intact.
What happens to windows, menus and the MDI pattern?
Windows and menus import into the metadata repository's UI model. The classic MDI parent-with-child-documents pattern translates into the platform's tabbed multi-pane layout — the same operator mental model (one workbench, several open records) without the per-workstation rendering constraints. SDI applications port as the platform's standard single-pane layout. PowerBuilder Foundation Classes (PFC) inheritance hierarchies — ancestor windows, control inheritance, override chains — flatten cleanly into the metadata model because the platform's UI composition is data, not class hierarchy.
What about EAServer, the three-tier topology and the two-tier thick-client model?
Both topologies are replaced by the platform's supervised runtime serving browser clients. EAServer (the Sybase / SAP three-tier application server) goes away with its licensing ; the two-tier client-server model — DLL deployments, ODBC profile management, per-workstation configuration, network share latency — goes away with its operational overhead. PowerBuilder ".NET Web Forms" and ".NET Windows Forms" deployment paths similarly retire — the runtime delivers the application surface in a browser, role-aware and responsive, on the same supervised JVM the rest of the platform runs on.
What about Appeon PowerServer, modern PowerBuilder 2022 or the PB.NET migration path?
Appeon's PowerServer adds web-deployment-from-PowerBuilder-source capability without changing the underlying application model — it is a packaging path, not a modernisation. PowerBuilder 2022 keeps PB current but inherits the platform's fundamental architectural shape (DataWindow + PowerScript + per-workstation deployment). The Airtool path is structurally different : it moves the application out of the PowerBuilder runtime altogether, into a metadata-driven model where DataWindows become repository rows and the supervised runtime takes over deployment, security, observability and AI integration. Customers who have adopted Appeon as an interim measure usually find the migration to Airtool simpler because the web-rendering question is already separated from the application-logic question.
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 custom J2EE
Bespoke Spring / EJB / Struts / JSF frameworks replaced by the metadata-driven runtime. Hand-written SQL, integration contracts and audit history are preserved.
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.