Convert PowerBuilder to .NET
Move PowerBuilder client-server applications onto .NET 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 C# that preserves that behavior.
A natural fit for the data layer
PowerBuilder estates commonly sit on SQL Server. Moving to .NET keeps that data tier in place while replacing the client-server front end with a supported stack.
Talent is disappearing
The pool of engineers fluent in PowerScript shrinks every year, while .NET has one of the deepest hiring pools in enterprise software.
Escape the desktop deployment model
Client-server executables pushed to every workstation become web-deployable ASP.NET Core services, removing an install-and-update burden from every release.
Security and compliance
Actively maintained .NET releases receive the patches and audit tooling that aging PowerBuilder runtimes no longer get.
What changes when you move to .NET
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 C# 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 Entity Framework Core data access plus a separate presentation layer.
- 03
Runtime & packaging
Client-server executables deployed to desktops give way to ASP.NET Core services, with the database connection moved behind an application tier.
- 04
Tooling & workflow
The proprietary PowerBuilder IDE and binary PBLs are replaced by Visual Studio or Rider, 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 IFpublic class CustomerService
{
private readonly CrmContext _db;
public async Task UpdateBalanceAsync(long custId, decimal balance)
{
var c = await _db.Customers.FindAsync(custId)
?? throw new CustomerNotFoundException(custId);
c.Balance = balance;
await _db.SaveChangesAsync();
}
}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 C#.
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 together, though the SQL Server data tier itself stays in place.
Migration work orderMigrate
Migrate: d_customer_list
Decompose the customer DataWindow into a typed C# 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 need explicit mapping onto C# decimal and nullable types to preserve financial precision.
No test coverage
Legacy PowerBuilder systems usually ship with nothing to prove behavioral parity against.
Frequently asked questions
How long does migrating PowerBuilder to .NET 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 C# be maintainable?
Yes. Output is idiomatic C# structured against the approved specification rather than a line-by-line transliteration of PowerScript events, so your existing .NET 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-.NET 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 C# 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.