PowerBuilder ↔ target architect
Bridge between PowerScript/DataWindow and the target ecosystem (.NET, Java, TypeScript), pattern mapping, REST API design
Loading...
Loading...
Migration of PowerBuilder applications (PowerScript, DataWindow, PBL) to .NET Core, TypeScript, or Java, under the ATLAS methodology. Screen capture, characterization tests, pattern-by-pattern migration, parity audit, REST API exposure for cloud integration and agentic workflows.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Understand the PowerBuilder estate: projects, screens, DataWindows, PBL, DataStores, database integrations. Rebuild a functional analysis from the code. Define scope, constraints, success criteria, target architecture choice (.NET / Java / TypeScript, web SPA vs WinForms).
Exhaustive DataWindow mapping (source SQL, calculated columns, validation rules, onChange/onBlur events), PBL packages, PowerScript scripts, shared DataStore dependencies. Identification of database integrations (SQL Anywhere, Sybase ASE, Oracle) to migrate.
Design target architecture: .NET Core / Java Spring Boot / TypeScript Node.js, cloud PostgreSQL or SQL Server database, containerization, OpenAPI-documented REST API exposure, separate SPA frontend or WinForms. Cloud strategy and observability. Prepare characterization tests.
Translate pattern by pattern: DataWindow → AG Grid/Telerik/JavaFX TableView, PowerScript → C#/Java/TypeScript, DataStores → entities/repositories, PBL → target packages. Incremental subsystem migration, parallel runs, internal parity audit per batch.
Progressive go-live with PowerBuilder ↔ target coexistence during transition (duration set at scoping based on risk profile), batched cutover, REST API exposure to cloud workflows and third-party integrations, ops handover to client team with documentation and pair-programming.
Automatic legacy-code conversion tools produce code that compiles but stays unreadable and unmaintainable: original patterns are copied as-is, without idiomatization, with dependencies on a proprietary runtime. Pushed to production without full re-characterization, this code is neither reliable nor scalable. End-to-end automatic translation isn't a modernization method — it's a debt transfer.
Our approach is the opposite. ATLAS relies on multiple readings of the legacy code, from several angles: data flows, business rules, dependencies, edge cases. AI comes in as a comprehension accelerator — to decipher decades of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate: it informs the architect's work, who then designs the target architecture (cloud, database, services) and drives the migration pattern by pattern, under parity audit.
This understanding still requires humans who know legacy languages. That's our edge: where Europe and North America face a retirement wave among mainframe and legacy developers, Tunisia retains a pool of experienced developers (COBOL, Delphi, PowerBuilder, RPG…). Paired with modern architects and developers trained in the ATLAS method, they ensure continuity between the original business intent and the target system.
PowerBuilder (Sybase then Appeon) remains present in SMEs and mid-caps, regional banks, mutualist insurers, and sectoral ERPs developed between 1995 and 2010. Its historical strength: the DataWindow, a component that combined data model, presentation, and interactivity in a single object — extremely productive for transactional business applications. Its weakness today: inactive vendor, rare expertise, client-server architecture incompatible with mobile and web. Modernization is no longer a long-term option.
Three forces drive migration. First, the gradual disappearance of PowerBuilder developers: profiles trained in the 2000s are retiring or reconverting, with no new graduates. Second, the structural incompatibility with modern channels (mobile, responsive web, API integrations) forcing costly workarounds. Third, the single-vendor fragility of Appeon PowerBuilder: any future investment depends on a single supplier's health. The ATLAS methodology frames this modernization predictably.
Access International has not yet delivered a client PowerBuilder modernization program. The capability is nonetheless real: the ATLAS methodology (10 steps, 9 principles, internal classified discrepancy registry) applies to 4GL legacy modernizations with an excellent fit — our Delphi journey demonstrates the application on a very close language (Pascal, VCL, FireDAC share PowerBuilder's RAD spirit). We propose a 2-3 week PowerBuilder diagnostic on your real code before any program commitment, to measure effective productivity and reliably calibrate scoping.
.NET Core 8 or Java 21 or TypeScript, PostgreSQL or SQL Server, REST API, SPA or WinForms frontend depending on context
Most frequent choice in practice: C# is syntactically close to PowerScript, Microsoft ecosystem dominant in PowerBuilder target SMEs/mid-caps, Appeon PowerServer offers assisted transition. WinForms if desktop need preserved.
When the target IT is Java-dominated or multi-OS portability (Linux server) is required. PowerScript-Java syntactic distance larger than PowerScript-C#.
When the goal is true cloud-native web modernization (mobile-first, multi-channel, opening to cloud and AI workflows). See patterns in Delphi to TypeScript.
Temporary step to expose PowerBuilder in web and REST without complete rewrite. Useful to gain time before a full migration program, not as final target (PowerBuilder debt preserved).
A PowerBuilder migration is planned as a sequence of functional batches, with the cadence set at scoping based on the volume of DataWindows and the chosen target (.NET, TypeScript, Java). Typical cell: PowerBuilder-target architect, target language tech lead, target developers, a senior PowerBuilder developer for business knowledge (essential early in the program), a UX designer for web ergonomic redesign, a QA, a DBA. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured. DataWindow UI effort typically represents 30 to 50% of total effort — to be included in initial scoping, not discovered mid-program.
Underestimating the complexity of DataWindows. A DataWindow combines SQL, presentation, validation, derived calculations — naive migration often breaks consistency.
Exhaustive DataWindow mapping from Intake: source SQL, calculated columns, validation rules, onChange/onBlur events. Each DataWindow is ported to its modern equivalent (AG Grid + web Form, Telerik Grid in .NET, JavaFX TableView in Java) with per-component validation. Line-by-line parity tests on production datasets.
Migrating one PowerScript at a time without rethinking the architecture. The result is a Java/C#/TypeScript that inherits PowerBuilder debt.
Bounded context business decomposition during the target architecture phase. Related PowerScripts are grouped into coherent services, shared DataStores become entities/repositories. This structural refactoring is separated from functional parity — distinct phase after cutover.
Choosing WinForms .NET by default without re-evaluating the desktop need. For most PowerBuilder applications, the original desktop need (Windows integration, offline mode) is no longer structural.
Systematic re-evaluation of desktop vs web need in phase E4 Target architecture. If true modernization is desired, separate SPA frontend (React, Angular) with .NET/Java backend. WinForms only if proven desktop need and Microsoft ecosystem.
Migrating code-for-code without rethinking business-logic exposure. This misses the opportunity to transform the client-server application into services consumable by cloud workflows, AI agents, or third-party integrations.
REST-API-oriented target architecture from phase E4: business logic exposed as documented endpoints (OpenAPI), with standard authentication (OAuth2, JWT), versioning, observability. The UI consumes the API like any other client — cloud workflow, n8n, Power Automate, AI agent. This is what justifies the migration beyond mere technical debt.
Declaring the migration complete after code conversion, without validating real user workflows or functional parity on the client's datasets.
Principle E7 — browser and business workflow validation mandatory before delivery. Parallel runs PowerBuilder / target on key transactions, automated comparison of results, parity audit with an internal classified discrepancy registry following a CRITICAL / ADAPTATION / COSMETIC grid. No cutover without proven parity.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Bridge between PowerScript/DataWindow and the target ecosystem (.NET, Java, TypeScript), pattern mapping, REST API design
C# (.NET Core), Java (Spring Boot), or TypeScript (Node.js), PowerScript→target translation patterns, line-by-line traceability
Ideally with client-server background (Delphi, VB.NET, C#) to understand the PowerBuilder object model; target training if needed
Accumulated business knowledge, legacy code reading, resolving interpretation ambiguities early in the program (essential)
Web ergonomic redesign (React, Angular), responsive, accessibility — only if web target (not required for WinForms)
Migration of SQL Anywhere, Sybase ASE, Oracle databases to cloud PostgreSQL or SQL Server, data parity audit
Characterization test bench, legacy/target comparison, ATLAS audit validation
Three main options. .NET Core: natural choice if Microsoft ecosystem dominant, C# syntax close to PowerScript. TypeScript + React/Angular: modern web target, mobile opening, see Delphi to TypeScript for patterns. Java + Spring Boot: if Java IT dominant. PowerBuilder to .NET remains the most frequent in practice, notably via Appeon PowerServer which offers an assisted transition.
For a PowerBuilder application of fifty to one hundred fifty DataWindows in nearshore co-delivery, plan 800 k€ to 1.5 M€ over 12 to 18 months. Higher cost than Delphi on equivalent volumes because DataWindows are more complex to port (combine SQL + UI + validation). See the delivery models.
No, not yet. We state it explicitly rather than presenting a capability as a realization. The ATLAS methodology applies nonetheless to 4GL legacy modernizations with excellent fit — our Delphi journey demonstrates the application on a very close language. We propose a 2-3 week PowerBuilder diagnostic on your real code before any commitment, to measure effective productivity and reliably calibrate program scoping.
Each DataWindow is analyzed individually in Discovery phase to identify real complexity. Simple DataWindows (tabular display, basic validation) migrate to AG Grid or Telerik in a few hours per screen. Complex DataWindows (nested sub-DataWindows, dynamic computed columns, cascading onChange events) require deep analysis to identify equivalent patterns (nested components, reactive formulas on the frontend, API hooks). Average effort per DataWindow varies from 0.5 to 5 person-days depending on complexity — that is why exhaustive E2 phase mapping is non-negotiable.
A useful step, not a final solution. Appeon PowerServer allows exposing an existing PowerBuilder application in web (.NET or JavaScript) without complete rewrite, encapsulating DataWindows. Pros: fast modernization, PowerScript business code preservation, lower initial investment. Cons: single-vendor dependency, PowerBuilder debt preserved, Appeon license costs, evolution limits. Our position: Appeon PowerServer is useful as a temporary step to quickly expose web during a full migration program to .NET / Java / TypeScript — not as final target.
Four combined disciplines. (1) Exhaustive DataWindow mapping from E2 Discovery (source SQL, calculated columns, validation rules, events). (2) Upstream characterization tests on the PowerBuilder legacy: the suite characterizes behavior before any target code is touched. (3) Parallel runs PowerBuilder / target on client datasets with automated comparison — target > 99% equivalence on critical paths. (4) Signed discrepancy registry by program committee: each gap documented, weighted, arbitrated, and contractually signed. See the full ATLAS methodology.
Three concrete ways to start — from a short diagnostic to a full program. Access has not yet delivered a client PowerBuilder migration: we state it explicitly and propose a 2-3 week diagnostic on your code before any program commitment.