If you run a PowerBuilder application, you already know the pressure: the developers who wrote it are retiring, hiring PowerBuilder talent is hard and getting harder, and the business logic that runs your operation is locked inside DataWindows that almost nobody can safely change. The platform is still maintained by Appeon, but “still supported” is not the same as “a good place to build the next ten years of your business.”
This post lays out the realistic ways to migrate a PowerBuilder system, what each one actually costs, and, honestly, where each fits and where it does not.
Why PowerBuilder is hard to leave
PowerBuilder migrations are unusually painful for two specific reasons, and any plan that ignores them will run over budget:
- The DataWindow. PowerBuilder’s DataWindow bundles the query, the data buffer, the validation, and the presentation into one object. Most of your real business logic lives here, not in tidy service classes. A migration is mostly a DataWindow migration.
- Thick-client assumptions. PowerBuilder apps assume a stateful desktop client talking directly to the database. Moving to the web means re-drawing that boundary (a browser client, an API, and a database), which is a genuine architectural change, not a cosmetic one.
The four realistic options
| Option | What it is | Timeline | Risk | Where it fits |
|---|---|---|---|---|
| Stay + maintain | Keep PowerBuilder, keep paying for scarce skills | n/a | Rising | Only as a short bridge |
| Replatform (Appeon Web/Cloud) | Compile the existing app to run in a browser | Short–medium | Low–medium | You want the web, but not to leave PowerBuilder or its debt |
| Full rewrite | Rebuild from requirements in a modern stack | Long | High | The app is small, or the requirements have genuinely changed |
| Automated conversion | Parse the PowerBuilder source and generate a modern equivalent | Medium | Low–medium | Large, business-critical apps you need to keep, on a modern stack |
Stay and maintain
Defensible only as a bridge. Every year you wait, the talent pool shrinks and the key-person risk grows. Use the time to plan the exit, not to avoid it.
Replatform with Appeon
Appeon’s tooling can take your PowerBuilder application to the browser with relatively little change. That solves the delivery problem (users get a web app), but the code is still PowerBuilder, so the maintainability and hiring problems remain. Good if your only goal is “get it in a browser.” Not modernization in the sense of owning clean, standard code.
Full rewrite
Rewriting from scratch gives you exactly the system you specify. It is also the highest-risk, longest option on the table. For a large PowerBuilder system, a rewrite means re-deriving years of undocumented business rules from the DataWindows by hand, which is where rewrites quietly blow their timelines. It makes sense when the app is genuinely small, or when the business process itself is changing so much that the old logic is not worth preserving.
Automated conversion
Automated conversion parses your actual PowerBuilder source (windows, DataWindows, embedded SQL, and PowerScript) into a structured model, then generates a modern equivalent from that model, in our case clean, standard TypeScript and React with a documented API. The point is not that a tool writes perfect code with no human involvement; it is that the business logic is carried across from your real code rather than reverse-engineered from memory. For a large, business-critical application you need to keep running, that is usually the lowest-risk path to a stack you can actually hire for.
In our PowerBuilder projects, 90%+ of the conversion is automated. One manufacturing client moved a system with 20 years in production to the web in half the usual migration time, with maintenance costs down 40%.
Where automated conversion is the wrong choice
To be straight about it: if your PowerBuilder app is a few screens, or you were going to redesign the whole workflow anyway, automated conversion is overkill; a rewrite or an off-the-shelf package will serve you better. Automated conversion earns its keep on the systems that are too large and too load-bearing to rewrite safely.
How to decide
Three questions settle most PowerBuilder migrations:
- How much undocumented business logic is in the DataWindows? The more there is, the more a rewrite risks losing it, and the more conversion pays off.
- Do you need to keep the system running the whole time? Big-bang rewrites and always-on operations are a bad combination.
- What do you want at the end: a browser, or code you own? Replatforming gets you the browser. Conversion (or rewrite) gets you standard code and a normal hiring pool.
If you want to see what your PowerBuilder application looks like as modern code before you commit to the full migration, the usual first step is a fixed-scope proof of concept on a representative slice of your real codebase; it shows the automation on your DataWindows rather than describing it. Get in touch and we’ll scope one.