Convert PowerBuilder to Java
Move PowerBuilder client-server applications onto Java without losing the business rules sealed inside binary PBL libraries and DataWindow objects. Spec-first, validated, and governed end to end.
- 8ForgeScore dimensions
- 6Pipeline stages
- Every stageApproval gates
Six reasons to move off PowerBuilder
PowerBuilder still runs working line-of-business systems, but the risk of standing still compounds every year.
Logic is locked in binaries
Application logic ships inside compiled .pbl libraries that cannot be read, searched, or diffed in source control without the proprietary IDE. Nobody can review what they cannot open.
Same functionality, new platform
Migration does not mean rebuilding features. Forge reconstructs what your PowerBuilder objects actually do into a Living Spec, then generates Java that preserves that behavior.
Talent is disappearing
The pool of engineers fluent in PowerScript shrinks every year, driving up maintenance cost and concentrating key-person risk in a handful of people close to retirement.
Security and compliance
Actively maintained Java frameworks receive the patches and audit tooling that aging PowerBuilder runtimes and their client-server assumptions no longer get.
Escape the desktop deployment model
Client-server executables pushed to every workstation become web-deployable JVM services, removing an install-and-update burden from every release.
Velocity returns
Teams ship features far faster on the JVM ecosystem than on a frozen PowerBuilder platform where every change is a risk review.
What changes when you move to Java
The shift is more than syntax. The UI model, data access, and deployment assumptions all move, and each one needs an explicit mapping.
- 01
Language & paradigm
PowerScript event handlers attached to visual objects are restructured into idiomatic, well-factored Java classes and services rather than transliterated event for event.
- 02
Data access
DataWindow objects, which bind query, layout, and update logic in a single artifact, are decomposed into explicit JDBC or JPA data access plus a separate presentation layer.
- 03
Runtime & packaging
Client-server executables deployed to desktops give way to services deployable on the JVM, with the database connection moved behind an application tier.
- 04
Tooling & workflow
The proprietary PowerBuilder IDE and binary PBLs are replaced by standard IDEs, plain-text sources under Git, automated tests, and CI pipelines.
DataWindow retrieval and update
// PowerScript
dw_customer.SetTransObject(SQLCA)
ll_rows = dw_customer.Retrieve(ll_cust_id)
IF ll_rows > 0 THEN
dw_customer.SetItem(1, "balance", ldec_new_balance)
dw_customer.Update()
END IF@Service
public class CustomerService {
private final CustomerRepository repo;
@Transactional
public void updateBalance(long custId, BigDecimal balance) {
Customer c = repo.findById(custId)
.orElseThrow(() -> new CustomerNotFound(custId));
c.setBalance(balance);
repo.save(c);
}
}How the migration works
From import to verified output, every step is scored, specified, and tracked.
Import PowerBuilder
Your existing PowerBuilder codebase is ingested as-is, PowerScript sources and DataWindow definitions included. No prior documentation needed.
ForgeScore assessment
Scored across 8 engineering-health dimensions, including DataWindow coupling and decimal-precision risk, before you commit to anything.
Approved specification
Business rules, including DataWindow validation and undocumented PowerScript event logic, are reconstructed from source into a spec your team approves.
Work orders
The spec becomes Build, Migrate, and Decommission work orders, scoped and sequenced.
Verified & shipped
Each Migrate work order is checked against the original PowerBuilder behavior, including numeric precision, before it ships as Java.
Works in your editor
Work orders connect into Claude Code, Cursor, Windsurf, and other AI code editors over MCP, so the governed spec travels with you instead of staying in a document.
From finding to work order
Every PowerBuilder import is scored across 8 engineering-health dimensions, then broken into Build, Migrate, and Decommission work orders. Here is what that looks like for a DataWindow coupling finding.
ForgeScore findingMedium severity finding
Data Weight54
How data is modeled, moved, and owned. Moderate score: DataWindow objects bind query, layout, and update rules into a single artifact, so each concern needs separating first.
Migration work orderMigrate
Migrate: d_customer_list
Decompose the customer DataWindow into a typed Java model, explicit data access, and a separate presentation layer with equivalent validation. Includes verification against the original PowerBuilder behavior before this work order is marked complete.
Common challenges
Most PowerBuilder migrations fail for the same handful of reasons, and it is rarely the technology itself.
Logic sealed in binary PBLs
Business rules live inside compiled library files that cannot be read or searched without the proprietary IDE, so discovery has to happen before any planning.
DataWindow coupling
A single DataWindow binds SQL, layout, validation, and update behavior together, and each concern has to be separated before it can move.
Type & semantic mismatches
PowerScript's decimal handling and implicit conversions rarely map cleanly onto Java's type system without explicit precision decisions.
No test coverage
Legacy PowerBuilder systems usually ship with nothing to prove behavioral parity against.
Frequently asked questions
How long does migrating PowerBuilder to Java take?
It depends on estate size and coupling. A ForgeScore assessment in the first few minutes gives you a concrete, evidence-based range before you commit, based on complexity and dependency analysis rather than a guess.
Can Forge read our compiled PBL files?
Forge works from the sources it can reach and reconstructs business rules into a Living Spec. Where logic is only available as compiled libraries, exporting sources from the PowerBuilder IDE gives the assessment far more to work with.
Will the generated Java be maintainable?
Yes. Output is idiomatic Java structured against the approved specification rather than a line-by-line transliteration of PowerScript events, so your existing JVM engineers can read and extend it.
What happens to our DataWindows?
Each DataWindow is decomposed into its parts: the query becomes explicit data access, the layout becomes presentation, and the validation and update rules become specified behavior your team approves before generation.
How do you prove the migrated system behaves the same?
Every Work Order is validated against the Living Spec and, where legacy outputs are available, against them directly, so parity is demonstrated rather than assumed.
See your ForgeScore before you commit
Every PowerBuilder-to-Java project on Forge starts the same way: your codebase is imported, scored across eight engineering-health dimensions with ForgeScore, and reconstructed into a Living Spec before a single line of Java is generated. That is what keeps behavior intact and architecture on plan.
Ship enterprise software at AI speed.
Every modernization path is spec-first and governed from Day 0.