Appeon's own current PowerBuilder documentation contains a phrase you don't expect to find in a vendor's official manual: "(obsolete)." Not once, as a footnote on a deprecated function, but stamped across an entire cluster of chapters — EJB clients, .NET Web components, Web services, Web DataWindow, a DataWindow control for ActiveX, even the .NET target that let PowerBuilder deploy nonvisual objects as .NET assemblies. Six distinct technologies, each one at some point pitched as the platform's way off the Windows desktop and into whatever the industry was betting on that decade, all still described in detail in the current PowerBuilder manuals, all labeled with the same one-word verdict. That's not a vendor being sloppy about cleanup. It's a vendor documenting its own graveyard in public, and the pattern buried in it explains more about where PowerBuilder is headed in 2026 than a roadmap slide would.
The graveyard, chapter and verse
Pull up Appeon's current PowerBuilder 2019 Application Techniques guide and Parts 6 and 7 read almost like an inventory of abandoned bridges: "Building an EJB client (obsolete)" gets its own chapter, followed by a "Web Applications" section where four of five entries carry the same tag — ".NET Web components (obsolete)," "Web services (obsolete)," "Web DataWindow (obsolete)," "DataWindow Web control for ActiveX (obsolete)" — plus a further chapter titled outright "Building a Web Services Client (Obsolete)." The Getting Started guide adds a sixth: the ".NET target," which let a PowerBuilder project "deploy nonvisual custom class components as .NET assemblies or Web services," is itself flagged obsolete on the very page that introduces PowerBuilder's target types.
None of these were vaporware. Each one shipped, each one got real documentation, and each one represented a genuine attempt to plug PowerBuilder into whatever the rest of the industry had decided was the future of enterprise software at the time it was built. Reading them in sequence is basically a timeline of late-1990s-through-2000s enterprise computing fashions, filtered through a single vendor's attempts to keep up with every one of them.
1991 to 1995: an independent company's brief run
PowerBuilder started at Powersoft, which shipped PowerBuilder 1.0 in July 1991 built around two ideas that were genuinely new at the time: PowerScript as an accessible object-oriented scripting language, and the DataWindow as a single object that could bind, display, and update a database result set without a developer hand-coding SQL and screen logic separately. It worked well enough that Powersoft went public on February 3, 1993, and by late 1994 was big enough that Sybase wanted it outright.
That acquisition put PowerBuilder inside a database company for the next fifteen years, which matters here: Sybase's own competitive pressure through the late 1990s and 2000s was largely about connecting PowerBuilder applications to whatever distributed-computing standard the enterprise software industry was rallying around next — CORBA and COM in the 1990s, Java's Enterprise JavaBeans and SOAP web services in the early 2000s, .NET once Microsoft made it unavoidable. The obsolete chapters in today's docs are the fossil record of that chase.
The bets, one by one
The EJB client let a PowerBuilder application call into a Java application server the way a Java client would, at a moment when EJB was the enterprise-Java establishment's answer to distributed business logic. Building a Web Services Client wired PowerBuilder into the SOAP/WSDL boom of the early-to-mid 2000s, when "web services" meant a specific, heavyweight XML contract standard, not the REST-and-JSON pattern PowerBuilder supports natively today. Web DataWindow and the DataWindow Web control for ActiveX both tried to get DataWindow's productivity story onto the browser before browsers had anything resembling a native equivalent, one by rendering DataWindow output in an HTML-adjacent format, the other by embedding an actual ActiveX control into Internet Explorer, which tells you exactly which browser era it was built for and why it didn't survive the one after it.
The .NET target was the biggest of these bets, and it has a paper trail. Sybase announced a beta of PowerBuilder 12 in August 2009 that added a second, .NET-targeting IDE alongside the existing Win32 "Classic" one, with a rewritten DataWindow supporting Windows Presentation Foundation and deployment to Windows Forms, WebForms, ASP.NET, and WPF. Sybase's own product manager for PowerBuilder described the pitch in terms of the DataWindow's core value proposition, carried over into the new target.
“With DataWindow, developers need to only write five lines of script to perform a task that might otherwise take 300 lines of C++ or C# code.”
Sue Dunnell, Sybase product manager for PowerBuilder, InfoWorld
Dunnell also told InfoWorld that the .NET migration plan had been underway in phases since around 2002, and that the target kept moving under Sybase the whole time: "Phase 4 was supposed to make building .Net applications a PowerBuilder experience, but Microsoft moved forward and really changed what .Net meant." An IDC analyst covering the announcement put the loyalty of PowerBuilder's own customer base in blunter terms than Sybase's own marketing did.
“It's taken them a while and they've got to keep moving with this as fast as possible. Their customers are amazingly loyal and patient.”
Al Hilwa, IDC program director for application development software, InfoWorld
"Amazingly loyal and patient" turned out to be exactly the right read. A seven-year .NET effort, expanded further in what Wikipedia's history calls "a major upgrade of PowerBuilder" adding full .NET Framework support in 2010, still ended up in the obsolete column. Today's docs don't even carry the WinForms/WPF visual-target capability that 2009 article described; only the narrower ".NET target" for nonvisual components survives long enough to be explicitly marked obsolete rather than simply deleted.
Every one of those bets shared the same structural flaw, and it's the same flaw regardless of which decade's acronym was involved: each one asked a PowerBuilder developer to stop writing PowerBuilder code for the parts of the application that needed to talk to the new target, and start writing Java, or raw SOAP/XML, or C#, by hand, inside or alongside their existing DataWindow-based application. That's not a small ask. It's the same skills gap the platform's installed base exists because of in the first place, just pointed at a different target language instead of solved.
It's worth noticing which technology from the same era did not get the obsolete label. "Building a COM or COM+ Client," the chapter right next to the EJB client chapter in the current docs, describes how to build a PowerBuilder client that accesses a COM or COM+ server component, and it carries no deprecation warning at all. COM and COM+ are native Windows technologies, part of the same desktop operating environment PowerBuilder was already targeting, not a bridge to a competing runtime or a different browser plugin era. The pattern holds up under that comparison, too: the bets that survived were extensions of the platform PowerBuilder was already built for, and the bets that didn't were attempts to leave it.
The years the cadence stopped
SAP acquired Sybase in 2010, and the deal's scale says a lot about where PowerBuilder sat afterward: SAP's enterprise value for the whole of Sybase was reported around $5.8 billion, a company-sized acquisition inside which a 1990s client/server IDE was, at best, a minor product line riding along with Sybase's database business.
You can see what that ownership structure did to the release cadence directly. PowerBuilder 12.6 went to beta in December 2013 and reached general availability on the SAP Marketplace in August 2014, adding .NET Framework 4.5, SQL Server 2012, Oracle 12, and Windows 8 support — a real release, not a token one. And then, per the PowerBuilder.eu community blog that tracked it at the time, that version is now simply gone: "this version of PowerBuilder is no longer available." No successor shipped from SAP after it, and PowerBuilder developers watched the gap open in real time. A user identifying himself as Chris Pollach, posting in an SAP Community thread titled "Is there a future after PowerBuilder 12.6?" on December 29, 2015, more than a year after 12.6 shipped and with no successor in sight, captured exactly how that silence read from the outside.
“Dirk Boessmann promised at last May's conference that a contract with Appeon was his top priority... A contract should be in place by the end of July - the end of summer at the latest. Here we are at the edge of 2016 and ZIP.”
Chris Pollach, SAP Community thread "Is there a future after PowerBuilder 12.6?"
Another poster on the same thread, a year earlier, had already reached a harder conclusion after checking SAP's own support-lifecycle listings directly: 12.1 support ending November 2014, 12.5 ending August 2015, 12.6 ending July 2017, with nothing announced beyond it. "There are no plans in SAP for PowerBuilder beyond 12.6," he wrote, adding that SAP "won't say so" outright even as the product went quiet internally. That's not retrospective commentary written after the fact to explain a gap; it's two developers, in the actual gap, watching a promised contract slip from "top priority" to "the edge of 2016 and ZIP." The contract Pollach was waiting for finally landed about six months later.
What Appeon did with the ownership
On July 5, 2016, in Hong Kong, SAP and Appeon signed the agreement that made Appeon, an independent company, responsible for developing, selling, and supporting PowerBuilder going forward. Appeon's CEO framed the deal, in the announcement itself, as inheriting something SAP had stopped actively investing in rather than building something new from scratch.
“PowerBuilder has a very loyal following, and I think that's because very few development stacks out there can deliver a high level of developer productivity while producing apps with such rich functionality and UX. All of us at Appeon are very passionate about PowerBuilder, and we are very excited to finally get our hands on this wonderful technology.”
Armeen Mazda, CEO of Appeon, PR Newswire announcement
What happened to the release cadence afterward is the clearest evidence of what that change actually meant in practice, and it's a matter of public record on Appeon's own release-history page: PowerBuilder 2017, 2017 R2, 2017 R3, 2019, 2019 R2, 2019 R3, 2021, 2022, 2022 R2, 2022 R3, 2025, and 2025 R2 — twelve dated releases across nine years, arriving on a rough annual-to-eighteen-month rhythm, replacing the exact silence Pollach and the other poster had been complaining about a few years earlier.
That's the backdrop the current cloud strategy sits against. PowerServer, Appeon's product for moving an existing PowerBuilder application into an installable cloud app on .NET, is explicit on its own product page about what it deliberately is not: "While PowerServer executes data access logic on the middle tier using C# and ADO.NET, it is not a code conversion solution." The PowerBuilder source stays PowerBuilder source. Developers keep working in the PowerBuilder IDE, in PowerScript, against the same DataWindow objects, and PowerServer handles the translation to the deployment target automatically.
“PowerServer automatically converts almost every single existing PowerBuilder feature, including the PFC framework. Typically, a cloud conversion requires just weeks of work.”
Appeon, PowerServer product page
Set that claim next to the EJB client, the ActiveX-embedded Web DataWindow, or the .NET target, and the structural difference is the whole story. Those earlier bets asked a PowerBuilder shop to author new code in a different language for the piece of the application reaching the new target. PowerServer's bet is that the shop doesn't have to author anything new at all — the DataWindow logic that already exists is what gets converted, automatically, rather than replaced by hand. It's worth being honest that Appeon hasn't kept every side branch alive even in the current era: its separate .NET-native tooling line, formerly SnapObjects and SnapDevelop, is itself described on Appeon's own community site as "no longer under active development," evidence that not every present-day bet survives either. But PowerServer's specific wager, converting the deployment target while leaving the source language untouched, is a structurally different kind of bet than the six technologies currently marked obsolete, and that difference is exactly why it's worth taking more seriously than the platform's history of side-quests would otherwise suggest.
The roadmap reads differently now, too
The language Appeon uses to describe how it plans releases has changed shape along with the strategy. Its public roadmap page describes an "agile 10-12 month release cycle" organized around four stated pillars rather than a single external technology to chase.
“New features and enhancements are delivered in agile 10-12 month release cycles.”
Appeon, Product Roadmap page
Compatibility, security, and interoperability are three of those four pillars, and none of them describe a bet on a specific runtime the way "build an EJB client" or "target .NET" did. They describe keeping an existing application working against whatever databases, operating systems, and open standards happen to be current, which is a materially smaller and more defensible promise than "here's your bridge to the next enterprise computing paradigm." It's a quieter roadmap than the one that produced six obsolete chapters, and on the evidence of the last nine years of release dates, quieter has also meant steadier.
Where this leaves you
- Appeon's own current documentation marks six PowerBuilder integration technologies obsolete — the .NET target, EJB clients, .NET Web components, Web services, Web DataWindow, and the ActiveX DataWindow Web control — a genuine public record of the platform's failed bets, not a hidden one.
- Every one of those bets required PowerBuilder developers to hand-write code in a different language for the piece of the application reaching the new target; that's the pattern connecting technologies as different as EJB clients and ActiveX controls.
- SAP's 2010 acquisition of Sybase, valued around $5.8 billion enterprise-wide, coincided with PowerBuilder's release cadence stalling almost completely; the last SAP-era release, 12.6, shipped in 2014 and is no longer even available.
- Appeon's ownership since 2016 shows up directly in the release-history page: twelve dated releases in nine years, a rhythm that never existed under SAP's final years.
- PowerServer is explicitly not a code-conversion tool by Appeon's own description — it keeps the PowerBuilder source and converts the deployment target, which is a structurally different bet than the six technologies currently marked obsolete.