Appeon sells you two contradictory things, and does it without much embarrassment. On one hand there's PowerBuilder 2025, a rebuilt IDE and a new compiler, promoted as the reason to keep writing PowerScript for another decade. On the other hand there's PowerServer, a toolchain whose entire pitch is that you can stop running your PowerBuilder app the old way and start running it as an installable cloud app on .NET, with most of the PowerBuilder-specific pieces converted out from under it. Same company. In a lot of cases, the same sales conversation. One product gives you a reason to stay; the other gives you a way to mostly leave. That's not really a contradiction — it's an honest reflection of where PowerBuilder shops actually sit in 2026. Nobody serious is telling you there's one correct answer, because there isn't one. What follows isn't a recommendation. It's the decision itself, broken into the pieces worth weighing, using the vendor's own published numbers alongside independent commentary that doesn't always flatter the vendor.
Three roads, not two
Most write-ups about PowerBuilder's future collapse into a binary: modernize or rewrite. That flattens a decision that actually has three distinct exits, each with a different risk profile, a different bill, and a different thing you're betting on. Road one is staying on PowerBuilder and actually upgrading to a current release, rather than running whatever version has been untouched since 2014. Road two is cloud-enabling the existing application in place, converting the deployment model without touching the DataWindow logic underneath it. Road three is a genuine rewrite, where PowerBuilder and PowerScript disappear from the stack entirely. They aren't mutually exclusive over a long enough timeline — plenty of shops take road one for a few years to buy breathing room, then road two, then eventually road three for the pieces that need it. But at any given planning meeting, you're choosing one.
- Road 1 — Upgrade in place: move to PowerBuilder 2025 or a recent release, keep PowerScript, keep the DataWindow, keep hiring for the skill you already have.
- Road 2 — Cloud-enable without rewriting: use Appeon PowerServer to convert the deployment model to an installable cloud app on .NET, largely automated, while preserving the PowerBuilder-authored business logic.
- Road 3 — Rewrite: replace PowerBuilder and PowerScript outright on a different stack, treating the existing app as a specification rather than a codebase to carry forward.
Road one: stay, but actually upgrade
This road gets dismissed too quickly by people who assume 'still on PowerBuilder' automatically means 'frozen in amber.' It doesn't have to. PowerBuilder 2025 is a real engineering release, not a rebrand: it replaces the old binary PBL library format with plain-text source files, adds native Git integration including fetch and rebase, moves the runtime to .NET 8, and ships a rewritten compiler. That last point is the one with an actual number attached to it rather than marketing language.
“The PowerBuilder 2025 represents a major leap forward, especially with the move from binary PBL files to real source files.”
Simon Jutzi, DevOps Architect, Informaticon
The source-file change matters more than it sounds like it should, if you've never tried to code-review a binary PBL diff. It means normal Git workflows, normal pull requests, and normal diffing tools start working on PowerBuilder code the way they already work on everything else on the team. That's a genuine quality-of-life fix, not a cosmetic one. This road is the right one when the actual pain your organization feels is developer experience and build friction, not the underlying architecture — when the team knows PowerScript, the DataWindow model still maps cleanly onto the business, and the complaint is 'this is unpleasant to work in,' not 'this can't do what the business needs anymore.'
Road two: cloud-enable without rewriting a line
PowerServer is Appeon's answer to a specific, narrower problem than 'PowerBuilder is old': the client/server deployment model itself — installing a Windows executable on every desk, managing VDI for remote users, patching endpoints one at a time — is the part that's actually expensive and brittle, more than the DataWindow logic living inside it. PowerServer converts an existing PowerBuilder application, DataWindow objects included, into an installable cloud app running on .NET Core, with a REST API middle tier, largely without hand-rewriting the business logic. It's a conversion, not a rewrite, and Appeon's own guidance is that a straightforward application can move in weeks.
The honest limit of this road is that it doesn't fix anything about the code itself, only where and how it runs. If the underlying application has business rules buried three layers deep inside DataWindow computed columns and nobody on the current team can explain what half of them do, PowerServer will faithfully carry that confusion into the cloud with you. It's the right road when the complaint is specifically about deployment and infrastructure — remote access, VDI cost, onboarding friction, platform reach — and the DataWindow-modeled logic itself is still trusted and understood. It's the wrong road when the actual goal is to finally document and rationalize logic nobody trusts anymore, because a faithful conversion will preserve exactly what you were hoping to leave behind.
Road three: rewrite it for real
There's a version of this decision where the honest answer is that PowerBuilder itself — not the deployment model, not the build tooling — is the constraint. That's usually true when the DataWindow's all-in-one model, which bundles data access, business logic, validation, and presentation into a single object, has become the actual obstacle to changes the business wants: a real API-first architecture, a mobile-native client, integration with systems that expect clean service boundaries rather than a DataWindow's SQL-plus-computed-columns approach. In that case, converting the deployment target doesn't solve anything; the thing you need to change is the thing PowerServer is specifically built to preserve.
“the most time-consuming and risky strategy”
Hakuna Matata Tech, describing a full manual rewrite in its PowerBuilder modernization comparison, contrasted there with automated code conversion
That's not an argument against rewriting — it's an argument for going in with clear eyes about what makes it hard. The specific failure mode independent migration guides keep flagging isn't the obvious one, a project that runs late. It's quieter than that: decades-old PowerBuilder applications tend to hide real business rules inside code and DataWindow expressions that were never separately documented, and because DataWindows fuse data access, logic, validation, and presentation into one object, a team can migrate the visible behavior faithfully while quietly dropping a validation rule or a computed column nobody wrote down anywhere else. Combine that with the fact that a lot of these systems were built before automated testing was standard practice, and you get regressions that surface not at go-live but weeks later, on exactly the numbers that matter most.
If you're seriously considering this road, the mitigations that keep showing up in independent guidance are unglamorous but specific: build automated test coverage against the existing application before you touch the rewrite, not after; run the old and new systems in parallel for a stretch rather than cutting over in one step; and budget real time for reverse-engineering DataWindow logic that was never written down anywhere except the DataWindow itself. None of that is unique to PowerBuilder, but PowerBuilder's specific habit of concentrating logic inside the DataWindow is exactly why the risk is sharper here than it is migrating off a codebase with a conventional service layer.
The questions that actually decide it
Strip away the vendor material and the decision usually comes down to a short list of honest questions, not a feature comparison:
- Is the pain you're feeling about deployment and infrastructure, or about what the application can actually do? The first points toward PowerServer; the second points toward a rewrite, because PowerServer won't touch it.
- Does anyone on the current team still trust the DataWindow logic, or has it become a black box the team routes around? Trusted logic is worth carrying forward; untrusted logic is a reason to rewrite deliberately rather than convert faithfully.
- Is your hiring problem about finding PowerBuilder developers, or about finding developers who want to work in PowerBuilder? Those have different fixes — the first is solved by staying and paying market rate, the second usually isn't.
- Do you have, or can you build, real automated test coverage before any conversion or rewrite begins? Without it, every path becomes riskier than its own advocates claim.
- Is the business actually asking for new capability the current architecture structurally can't provide, or is it asking for the same capability faster and cheaper? New capability leans rewrite; same capability leans upgrade or convert.
- What's your actual planning horizon? A three-year horizon can justify a rewrite's up-front cost; an eighteen-month horizon usually can't.
The incentive nobody puts in the brochure
Here's the part worth sitting with a little longer: Appeon makes money on road one and road two, and makes nothing on road three. That doesn't make its published guidance dishonest — the compiler genuinely is faster, PowerServer genuinely does convert real applications in real weeks, and the case studies cited above are real customers, not composites. But it does mean the framing you'll get from Appeon's own materials, understandably, treats a rewrite as the option of last resort rather than as a legitimate first choice for the subset of organizations where it's actually correct. Independent migration and modernization consultancies have the opposite tilt: firms that sell rewrite or conversion services have their own reason to describe the status quo as riskier than staying put usually is. Neither side is lying to you. Both are describing the option that pays their invoices in the most favorable light available. The way through that isn't to distrust either source — it's to notice which of the six questions above actually applies to your situation, and to weigh the vendor's numbers against what your own team already knows about its own code, because that's the one piece of information no vendor, on either side of this argument, actually has.
None of the three roads is free, and none of them is obviously correct in the abstract. What's true is that the decision is more legible than it looks from the outside, once you separate 'the deployment model is the problem' from 'the architecture is the problem' from 'nothing is actually broken, the tooling is just unpleasant.' Those are three different diagnoses, and — not coincidentally — there happen to be three different products for sale that match them.
Compare PowerBuilder modernization paths →