How to Migrate off the Legacy HP-UX Hardware Platform

Background

Many organizations still rely on HP-UX to run core billing, inventory, logistics, and financial systems.

These environments are usually stable, but they are also a risk:

Hardware and OS support are shrinking
Skilled HP-UX and C/ISAM developers are retiring
Batch jobs, scripts, and green-screen interfaces are hard to change and hard to integrate with cloud platforms

The goal is not just to lift and shift HP-UX to another server. The goal is to move the data and logic into modern Java or .NET platforms, while preserving proven business rules.

Typical HP-UX Legacy Landscape

A typical HP-UX environment has a mix of:

C or 4GL applications
ISAM and proprietary data files
Flat files and export feeds
Shell scripts and cron jobs wrapping nightly processing
Some relational data in Oracle, Informix, or other RDBMS

You can picture it roughly like this:

[Business Users]

Terminals / X-Clients

[HP-UX Servers]

[C / 4GL Applications]

+—————————-+

| ISAM Files (.dat, .idx) |

| Flat Files / Feeds |

| Legacy RDBMS Tables |

+—————————-+

Shell Scripts / Cron Jobs

Our work is to pull this environment apart safely, move the data into a modern relational model, and rebuild the application layers in Java or .NET without losing behaviour.

HP-UX Data Landscape - ISAM and Beyond

Many HP-UX systems store their core data in ISAM files and related proprietary formats, sometimes alongside Oracle or another database. Common patterns include:

Large ISAM master files for customers, accounts, policies, items
Transaction files appended every day or every batch cycle
Index files that enforce access paths rather than explicit foreign keys
Control files for batch sequencing, process flags, and checkpoints

The main challenge is that business meaning is encoded in:

Record layouts embedded in C or 4GL code
Implicit relationships (keys and flags) instead of explicit foreign keys
Encoded date, time, and numeric formats specific to the platform

We treat this entire data landscape as a single design to be preserved and rebuilt, not as a collection of isolated files.

High-Level Migration Approach

The HP-UX migration to Java or .NET follows a structured, repeatable pipeline:

[HP-UX Source System]

Design Discovery

(code + data layouts)

CORE Repository

(neutral model)

Forward Engineering

Java / .NET + RDBMS

Testing & Cutover

Key principles:

Preserve the original design so users recognize the application after migration
Automate as much as possible to reduce cost and risk
Separate data access, business logic, and presentation layers so the new system is easier to maintain and extend

Data Migration from ISAM and Legacy Files

Data migration is often the most sensitive part of leaving HP-UX. We treat it as its own project stream, tightly coordinated with application migration.

Discovery and Profiling

We start by reverse-engineering the data model:

Extract record definitions from C/4GL code and copybooks
Map ISAM keys and indices to candidate primary and foreign keys
Profile data for ranges, null patterns, and special values
Identify codes, flags, and status fields that drive behaviour

[ISAM Files / Flat Files]

Layout Extraction

(copybooks, C structs)

Data Profiling

(ranges, anomalies)

2. Logical and Physical Target Model

Once the existing model is understood, we design a normalized relational model that can serve Java or .NET services:

Decide primary keys and foreign keys
Resolve repeating groups and embedded arrays into child tables where possible
Standardize date, time, and numeric formats
Document lookups, reference tables, and code sets

Current HP-UX Data

+—————-+

| ISAM Layouts |

| Flat Files |

| Legacy DB |

+—————-+

[Logical Data Model]

[Physical SQL Schema]

(SQL Server, Oracle, PostgreSQL)

Automated Extraction and Transformation

We then build automated pipelines to pull data out of HP-UX and land it in the new database:

[ISAM / Flat Files]

Extract Programs

(C#, Java, or ETL)

Staging Tables

Transformation Rules

(type conversion, mapping)

Target RDBMS Schema

Typical transformations:

Converting platform-specific integers and floating-point formats into standard types
Turning packed, zoned, or proprietary numeric formats into DECIMAL fields
Expanding codes into lookup tables
Resolving composite keys and surrogate keys
Enforcing referential integrity that never existed physically on HP-UX

4. Iterative Loads and Reconciliation

We do not wait until the end of the project to test data:

Initial dry-run loads into a non-production environment
Row counts and balance checks between HP-UX and target database
Selected record-level reconciliation for critical entities

The outcome is a fully defined, repeatable path for moving HP-UX data into a modern relational database that supports Java and .NET applications.

Application Migration to Java or .NET

Migrating the code that sits on top of HP-UX data is where automation pays off.

We follow a design-preservation approach:

[HP-UX Application Code]

(C / 4GL / scripts)

Static Analysis

(parsing, semantic model)

CORE Repository

(language-neutral model)

Code Generators

(Java / .NET + UI)

1. Inventory and Assessment

Catalog all executables, libraries, and scripts
Verify all executables have original source code where in-house built or have equivalent functionality on the modern platform selected (Windows, Linux).
Identify entry points, screens, reports, and batch jobs
Classify components by complexity and dependencies
Prioritize business-critical paths (month-end, billing, credit, etc.)

2. Parsing into a Neutral Model

Rather than trying to translate line by line directly into Java or C#, we parse code into a language-neutral repository:

Data structures, variables, and record layouts
Database access and ISAM calls
Screen definitions, prompts, and validation rules
Business rules, calculations, and branching logic

This repository is the single source of truth for forward engineering.

3. Forward Engineering to Java or .NET

From the repository we generate:

Java (for example Spring Boot + MyBatis or JPA) or
.NET (for example ASP.NET / .NET 8 + Dapper or EF)

We separate concerns into clear layers:

[Presentation Layer]

– Web UI (React, Angular, Razor, etc.)

[Service / API Layer]

– Java REST controllers

– .NET Web APIs

[Business Logic Layer]

– Generated core logic

– Hand-coded extensions

[Data Access Layer]

– SQL mappers or repositories

– Parameterized queries

[Relational Database]

– SQL Server / Oracle / PostgreSQL

Business rules that used to be spread throughout HP-UX applications are preserved in a structured way, making it easier to test, review, and extend them.

Batch Jobs, Shell Scripts, and Scheduling

From the repository we generate:

Java (for example Spring Boot + MyBatis or JPA) or
.NET (for example ASP.NET / .NET 8 + Dapper or EF)

We separate concerns into clear layers:

[Presentation Layer]

– Web UI (React, Angular, Razor, etc.)

[Service / API Layer]

– Java REST controllers

– .NET Web APIs

[Business Logic Layer]

– Generated core logic

– Hand-coded extensions

[Data Access Layer]

– SQL mappers or repositories

– Parameterized queries

[Relational Database]

– SQL Server / Oracle / PostgreSQL

Business rules that used to be spread throughout HP-UX applications are preserved in a structured way, making it easier to test, review, and extend them.

Testing, Parallel Runs, and Cutover

You cannot replace a long-lived HP-UX system without strong testing and a controlled cutover.

Our approach:

Unit and component testing
- Generated Java / .NET code is tested with sample data
- Edge cases from legacy logic are verified

Functional and regression testing
- Legacy HP-UX screens and reports are compared to new UI and outputs
- Business stakeholders validate key workflows

Data reconciliation
- Check totals, counts, and measures between HP-UX and the new system
- Validate data integrity constraints in the new database

Parallel runs and pilot migration
- Run HP-UX and the new solution in parallel for a defined period
- Resolve discrepancies before final cutover

Final migration and go-live
- Execute the agreed cutover plan
- Freeze changes on HP-UX for the designated window
- Perform final delta load and activate the new environment

[Legacy HP-UX] [New Java / .NET]

| |

Test Cycles <————–> |

| |

Parallel Runs ————–>|

| |

Final Cutover ————–>|

What You Gain After Leaving HP-UX

By migrating HP-UX applications, ISAM data, and scripts into a modern Java or .NET stack, you position your organization for the next decade:

Standard relational databases with full tooling, backup, and reporting
Web-based user interfaces instead of terminal sessions
Easier integration with cloud platforms and APIs
A maintainable code base in languages that your team can hire for
Reduced platform risk and hardware dependency

The key is to reach that point without losing the proven behaviour that your users and critical business processes rely on every day. That is why design preservation, automation, and structured data migration are at the center of the HP-UX migration approach described here.

What made PowerHouse attractive was how it streamlined development. Companies didn’t need large teams to get an application off the ground. PowerHouse had a set of tightly integrated tools that covered the entire development cycle—user input screens, backend processing, and reporting.

The common thread in all these examples is data—PowerHouse excels at helping organizations manage, organize, and report on large volumes of data efficiently.