Application & Data Migration Blog Posts | GAPVelocity AI

PowerBuilder 2025 R2: Should You Upgrade or Plan a Modernization?

Written by Darryl Worsham | Oct 9, 2026, 5:00:00 PM

 

Appeon shipped PowerBuilder 2025 R2 on June 3, 2026. If you own the budget for a PowerBuilder application, that is good news. It also puts a decision on your desk that many companies have been deferring for years.

You should know where I stand before you read further. I run a business that modernizes PowerBuilder applications to .NET, so discount my opinion accordingly. To earn the rest of your attention, I’ll start with the cases where I’d tell you to upgrade, keep your money, and get on with your year.

My view is simple. Upgrading is an operating decision. Modernizing is a capital decision. Companies get into trouble when they treat one as if it were the other: they approve the upgrade because it’s cheap and call the platform question settled, or they fund a modernization to solve a problem an upgrade would have fixed.

You have three options: stay and upgrade, modernize selected components, or fully modernize the application. Each one is the right answer for somebody.

What 2025 R2 changes on your budget line

R2 is a solid release from a vendor that is clearly investing. Appeon says more than 18,000 organizations run PowerBuilder, and this release reads like it was written for them. Here’s what’s in it, translated out of the release notes.

What changed in R2

Why a budget owner should care

Compiled executables now carry standard Windows exploit protections (DEP, ASLR, CFG, SafeSEH). The runtime can limit DLL loading to trusted paths and verify signatures.

These are the items a customer security review or an internal audit looks for in desktop software. An upgrade answers them without a project.

.NET 10 support across the runtime, .NET assembly calls, ADO.NET drivers and PowerServer projects.

.NET 10 is Microsoft's current long-term support release. Your application stays on a supported foundation.

Support for SQL Server 2025, PostgreSQL 18 and Oracle 26ai, plus IPv6.

Your database and infrastructure teams can keep upgrading without the application holding them back.

Up to 50% lower memory use in the IDE, faster builds, Git fetch and rebase built in, dark mode.

Good for the people doing the work. Small on the P&L.

Sources: Appeon's general availability announcement and What's New in 2025 R2.

The price is modest. Appeon says existing customers are entitled to a free upgrade. List pricing is $895 per developer per year for Professional and $1,595 for CloudPro, and the announcement places R2 in the CloudPro tier, so confirm which one you hold.

The license is the small number. The real cost of any upgrade is regression testing every screen and report the business depends on. Ask your team for that estimate in days before you approve anything.

What R2 does not change

An upgrade keeps you current on PowerBuilder. It leaves four things exactly where they were.

The hiring pool. A new release doesn’t add PowerBuilder developers to the job market. Look at how many qualified applicants your last PowerBuilder opening drew, and how long it stayed open.

The architecture. The language is still PowerScript and the client still runs on Windows. Browser and cloud delivery exist through PowerServer, with production licenses listed from $3,500 to $25,000 per year depending on user sessions.

The vendor dependency. One company supplies the language, the IDE and the runtime, and every bundle is a non-perpetual subscription. Staying carries a permanent annual cost. That is a fair trade for many companies, as long as it’s a deliberate one.

The support clock. An upgrade is a recurring event. Under Appeon's end-of-life policy, a standard release gets at least 24 months of standard support and a long-term support (LTS) release gets at least 60. Then you upgrade and regression test again.

Here’s where each version stands today, from Appeon's product availability matrix.

Version

Mainstream maintenance ends

End of life

2025 R2

Not yet published

Not yet published

2025

June 3, 2027

June 3, 2028

2022 R3 (LTS)

No sooner than January 8, 2029

No sooner than January 8, 2031

2022 and 2022 R2

Ended May 7, 2026

May 7, 2027

2019 R3

Ended January 22, 2026

January 22, 2028

2021, 2019 R2, 2019, 2017 R3 and earlier

Ended

Ended

If you’re on 2019 R3 or any 2022 release before R3, mainstream maintenance ended this year. Whatever else you decide, that needs a line in next year's budget.

Option 1: Stay and upgrade

Upgrade and stop there if most of these describe you:

  • The application is stable and change requests are few.
  • The people who know it will be with you for as long as you plan to run it.
  • Your users work on Windows desktops and nobody is asking for anything else.
  • The application has a retirement date, for example an ERP rollout that replaces it within a few years.
  • The business isn’t asking for something the platform makes expensive.

What it costs: subscriptions, a regression cycle now, and another one every few years.

What it buys: a supported, more secure application and time. Time has real value when the application is headed for retirement anyway.

If this is you, upgrade, and don’t let anyone sell you a migration. That includes us.

One detail for cautious shops. Appeon has not published end dates for 2025 R2, and 2022 R3 is the designated LTS release with support through at least January 2029. Ask your team which release fits your appetite for risk.

Option 2: Modernize selected components

The middle path fits when the application is healthy and the pain is specific. Another system needs its data. Customers want a portal. One module changes every month while the rest hasn’t been touched in years.

Appeon gives you tools for this. PowerBuilder 2025 added automatic REST API creation from existing DataWindows, and PowerServer deploys an existing application as an installable cloud app. You can also move a single module to .NET and run it beside the PowerBuilder core.

What it costs: a contained project, plus the ongoing cost of running two technology stacks.

That second cost is the one to watch. You now fund two skill sets and the seam between them, and hybrid arrangements tend to outlive the plan that created them. Before you approve one, ask whether it shrinks the PowerBuilder footprint or only adds to what you maintain. Then put an end date on it, or accept in writing that it’s permanent.

Option 3: Modernize the entire application

Modernize the full app when the problem is the platform itself and no upgrade will fix it:

  • One or two people can safely change the application, and they have retirement dates.
  • Each change costs more and takes longer than it did a few years ago.
  • The business needs browser access for every user, integration with modern systems, or AI features built on the logic inside the application.
  • The application is your product, and buyers or acquirers ask about the stack during diligence.
  • You expect to run it for another seven to ten years.

Modernization earned its reputation with budget owners. The traditional model is a large team, an open-ended timeline and a bill that grows with the project. You were asked to approve a number nobody would stand behind.

That part has changed, and it’s why this option deserves a fresh look even if you rejected it five years ago. AI agents now do most of the conversion work, so a vendor can price the outcome instead of the hours. Our platform, VELO, converts PowerBuilder to C# and Blazor on Azure, and we quote a fixed price from an assessment before work begins. A mid-sized application of 100,000 to 500,000 lines typically converts in 8 to 16 weeks.

You should also know what that price covers. VELO delivers an alpha-ready application, meaning it compiles and runs. Testing, stabilization and release hardening remain. Your team can do that work, or we’ll take it to a production release candidate for a second fixed price. Put both numbers in your business case.

Whoever you talk to, hold them to four things. We expect to be held to them too.

  1. A fixed price, quoted before work starts.
  2. A written definition of what "done" means at delivery.
  3. Evidence that the business logic survived, in a form your team can check.
  4. A clear answer on what happens to your source code. Ours is processed in a dedicated Azure environment and permanently deleted when the project is complete.

Five questions to answer before you fund anything

You don’t need to read code to make this call. You need five answers, and your team can get them in a week.

  1. Which version are we on, and when does its support end? Check it against the table above.
  2. How many people can safely change this application, and how long will they be here? Count names. A number below three is a business continuity risk.
  3. What did our last three change requests cost, and how long did they take? Compare that with three years ago. The trend matters more than any single figure.
  4. What has the business asked for that we declined or deferred because of the platform? That list is the cost of staying, and it never shows up on an invoice.
  5. How many more years does this application need to run? Get a number from the business owner.

The answers usually point somewhere.

What you find

Where it points

Stable application, stable team, fewer than about five years of life left

Stay and upgrade

Healthy application with one or two specific gaps, such as integration or remote access

Modernize selected components

Shrinking team, rising cost per change, a growing list of deferred requests, or a long life ahead

Modernize the full application

How I would sequence it

You can do both. If your version is past mainstream maintenance, move to a supported release regardless of what comes next. A modernization takes months, and the system running your business should have vendor support while it happens.

Then put two numbers on one page. The first is five years of staying: subscriptions, upgrade and regression cycles, your change requests at their current trend, and the people you will need to hire or replace. The second is the fixed price of leaving, plus the finishing work.

Your team can produce the first number. A modernization vendor should be able to produce the second before you commit to anything.

Appeon is investing in PowerBuilder, and that makes staying a real option again. Make it a choice, with both numbers in front of you, and you will be able to defend it either way.

If you want the second number, start with an assessment of your PowerBuilder code. You get a scope report and a fixed-price quote to set beside your cost of staying.