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 Dictionary 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 dictionary. 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 dictionary'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 dictionary |
| 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.