A DataWindow is not a grid.
It is simultaneously:
-> A data access layer ā parameterized SQL, joins across multiple tables
-> A business logic container ā computed columns, validation expressions, conditional formatting
-> A rendering engine ā print layouts, display formats, locale-specific output
-> A UI widget ā the visual surface users interact with
All of this exists inside a single binary object in a .pbl library file.
When teams rewrite from scratch, they recover the SQL. They do not recover the computed columns or the validation expressions adjusted seventeen times over fifteen years.
This is not a documentation problem. It is a structural problem. And it is why “rebuild from scratch” is almost always the wrong answer.
What’s the most complex DataWindow you’ve ever worked with?
You can find relevant information in the specific section: https://enable-dev.com/modernization
Follow us on LinkedIn.
Somewhere in your organization, there is a person who has been maintaining the PowerBuilder application for twenty years.
They don’t just know how the system works. They know why it works that way.
They know why that DataWindow updates three different fields when you change the dropdown. They know why the pricing calculation has a special condition for that one client signed in 2003. They know why field B’s validation depends on field A ā but only in certain cases.
None of that knowledge is written down. It lives in their head. Built over two decades.
When that person retires, the knowledge doesn’t just go with them. So does the organization’s ability to interpret the system when something goes wrong.
Key-person dependency in PowerBuilder applications is the most undermanaged operational risk in enterprise IT.
Has your organization started the formalization process?
You can find relevant information in the specific section: https://enable-dev.com/outstaffing
Follow us on LinkedIn.
Your PowerBuilder application’s business logic is an asset. The interface is a cost.
Most organizations treat them the other way around.
The correct framework is three words:
Preserve ā every DataWindow definition, computed column, validation rule. Treat it as a corporate asset.
Rehost ā .NET DataStore brings DataWindow semantics into .NET without rewriting them. The logic executes identically. The container changes.
Replace ā comprehensively. React or Angular for web. React Native or Flutter for mobile. Rebuilt from the ground up.
The logic is the asset. The presentation is the liability. Treat them accordingly.
What’s the most important business logic in your application you’d be terrified to lose?
You can find relevant information in the specific section: https://enable-dev.com/modernization/
Follow us on LinkedIn.
“We’ll rebuild it from scratch.”
That sentence has killed more modernization projects than any budget cut, technical failure, or impossible deadline ever did.
Not because the intention was wrong.
Because the assumption behind it was.
An enterprise PowerBuilder application is not old code waiting to be replaced. It is decades of organizational knowledge ā encoded in thousands of invisible adjustments that nobody fully remembers making.
The SQL is recoverable.
The computed columns are not.
The validation rules adjusted seventeen times over fifteen years are not. The display format a specific regulator expects to see is not.
None of that logic lives in a document.
It lives in the DataWindow.
And the DataWindow is not a grid ā it is simultaneously a data layer, a business logic container, a rendering engine, and a UI widget.
When a team rewrites from scratch, they reconstruct what they can see.
What they cannot see gets rebuilt from memory, assumption, and guesswork.
The new system processes 99.9% of transactions correctly.
That 99.9% never surfaces in a financial audit.
The 0.1% does ā six months after go-live.
The question is never “rewrite or not.”
The question is: do you know exactly what you’re about to throw away?
You can find relevant information in the specific section: https://enable-dev.com/modernization/
Follow us on LinkedIn.