Get off IBM Power renewal cycles without breaking the batch jobs your business runs on
Most AIX estates stay on the data centre floor for one reason: nobody knows every place where Big-Endian C structs, XL C compiler flags, KornShell scripts and SAN storage quirks are wired into the business logic. We audit the source tree, fix the endianness and shell traps, migrate your databases, and move your workloads to Linux on Google Cloud or IBM Power for Google Cloud (IP4G).
Why AIX migrations stall
An IBM Power hardware refresh or AIX software maintenance renewal lands on the CFO’s desk every three to five years. Each time, the quote per core goes up and the pool of engineers who know smit, mksysb, PowerVM VIO servers and HACMP gets smaller.
Teams try to treat AIX-to-Linux as a standard Unix lift-and-shift. Six weeks later they hit a wall. A C++ pricing engine produces garbage numbers because Power is Big-Endian and x86 is Little-Endian. Overnight ksh93 scripts fail because AIX ps, tar and df flags do not match GNU coreutils. Or an application vendor says their binary is only supported on AIX 7.2 and the source code was lost in a merger ten years ago.
We pick the right target for each LPAR up front instead of forcing every workload through the same funnel:
- Recompile and containerise to Linux on Google Cloud: When you have the source code (Java, C, C++, Perl, Python, Go), we port the build from IBM XL C/C++ or WebSphere to GCC/Clang or OpenJDK and run it on Cloud Run, GKE Autopilot, or Compute Engine.
- Replatform databases off AIX: We move DB2 and Oracle databases running on AIX LPARs to AlloyDB for PostgreSQL, Cloud SQL, or Oracle Database@Google Cloud, using continuous Change Data Capture (CDC) so cutover downtime is measured in minutes rather than a full weekend outage.
- Host AIX on IBM Power for Google Cloud (IP4G): For closed-source third-party packages or AIX LPARs that must leave your data centre before you have time to refactor them, we move the LPAR into IP4G. It runs on IBM Power9 or Power10 hardware connected directly to your Google Cloud VPC at sub-millisecond latency.
Four technical traps that break AIX-to-Linux projects
Big-Endian vs Little-Endian data corruption
AIX on IBM Power stores multi-byte integers most-significant-byte first (Big-Endian). Linux on x86 and Arm stores them least-significant-byte first (Little-Endian). If your C, C++ or COBOL programs read binary flat files, memory-mapped files, or raw TCP sockets without ntohl() / htonl() conversions, they will compile cleanly on Linux and corrupt every number at runtime. We scan the full AST for raw struct casts, union punning and binary file I/O before a single line is recompiled.
IBM XL C/C++ pragmas and 32/64-bit pointer assumptions
Code written for IBM XL C/C++ (xlc_r / xlC_r) relies on compiler-specific #pragma directives, AIX shared library exports (.a archives containing shared .o objects), and loose type rules that GCC and Clang reject. Older C code also mixes long and pointer widths that change between 32-bit AIX builds and 64-bit Linux targets. We modernise the build system to CMake or Bazel and add automated regression harnesses comparing AIX output against Linux output byte for byte.
KornShell (ksh93) quirks and AIX system utilities
Decades of operational glue live inside /usr/bin/ksh scripts that call lslpp, lsdev, lsattr, errpt, lsvg, or AIX-specific flags on awk and sed. In ksh93, the last stage of a pipeline runs in the current shell scope, whereas bash runs it in a subshell, meaning variables set inside a loop vanish silently in bash. We use AI-assisted static parsers to inventory every script, rewrite OS-dependent calls, and move batch schedules into Cloud Workflows or Cloud Run Jobs.
PowerHA (HACMP), GPFS and raw LVM logical volumes
High availability on AIX is usually wired through PowerHA SystemMirror scripts, shared SAN LUNs, or IBM Spectrum Scale (GPFS) mounts. Lifting those failover scripts to the cloud creates split-brain outages. We replace custom PowerHA scripts with native regional high availability in Cloud SQL, AlloyDB, GKE multi-zone clusters, or managed Filestore and NetApp Volumes.
Where your AIX stack lands on Google Cloud
| AIX workload today | Google Cloud target | How we move it |
|---|---|---|
| Java / WebSphere Application Server (WAS) | Cloud Run or GKE Autopilot | Extract EAR/WAR config, move off proprietary WAS APIs to Open Liberty, Tomcat or Spring Boot, and containerise with Cloud Deploy pipelines. |
| Custom C / C++ daemons & Pro*C binaries | GKE, Cloud Run or Compute Engine (Linux) | Port Makefiles from xlc_r to GCC/Clang, remediate Big-Endian binary I/O and shared memory calls, and validate with side-by-side traffic replay. |
| DB2 on AIX / Oracle on AIX | AlloyDB for PostgreSQL, Cloud SQL or Oracle Database@Google Cloud | Convert schemas and stored procedures with Database Migration Service (DMS) and Gemini conversion workspaces, or shift Oracle to Exadata inside Google Cloud. |
KornShell (ksh93) & Tivoli / Control-M batch | Cloud Run Jobs & Cloud Workflows | Remediate POSIX vs GNU command differences, containerise batch workers, and wire observability directly into Cloud Logging and Alerting. |
| IBM MQ on AIX | Google Cloud Pub/Sub or IBM MQ on GKE / Compute Engine | Keep wire compatibility for existing MQ clients where required, or replace point-to-point queues with managed Pub/Sub topics and dead-letter handling. |
| Closed-source ISV binaries & AIX-certified ERP | IBM Power for Google Cloud (IP4G) | Restore mksysb images or replicate LPARs onto Power9/Power10 hardware attached to your Google Cloud VPC with zero code changes. |
How an AIX migration runs
LPAR, binary and source tree inventory (Weeks 1 to 2)
We inspect every AIX LPAR (oslevel -s, lslpp -L, lsvg, crontab, open sockets and shared libraries) and compare running binaries against your Git, SVN or CVS repositories. Any binary running in production without matching source code is flagged on week one so it can be routed to IP4G or decompiled before anyone commits to a Linux cutover date.
AI-assisted endianness, compiler and shell remediation (Weeks 3 to 6)
We run static analysis and Gemini-powered code inspection across your C, C++, Pro*C, Java and ksh repositories inside an isolated Google Cloud project. Every endian-sensitive struct, xlc pragma, 32-bit pointer cast and AIX command flag is catalogued and patched on a feature branch. We capture real input payloads and binary files from AIX and assert that the Linux build produces identical outputs.
Database conversion and continuous replication
Moving multi-terabyte DB2 or Oracle databases over a weekend backup-and-restore window rarely fits enterprise SLAs. Because AIX is Big-Endian, even physical Oracle transportable tablespaces require RMAN CONVERT steps to switch byte order for Linux. We set up logical replication (Datastream, DMS or GoldenGate) so your Google Cloud database stays milliseconds behind AIX while your teams run parallel user acceptance testing.
Wave cutover before your IBM maintenance renewal
We sequence migration waves backwards from your hardware lease expiry or IBM software maintenance renewal date. Services sit behind Apigee or Cloud Load Balancing so traffic can shift LPAR by LPAR with an instant rollback path if a downstream consumer misbehaves.
Related modernisation services
- Mainframe Migration to Google Cloud: Move IBM z/OS and IBM i (AS/400) COBOL, PL/I, RPG, CICS and DB2 workloads using AI spec extraction and Google Cloud Dual Run.
- Enterprise Application Modernisation: Break up Java and .NET monoliths with the Strangler Fig pattern, Cloud Run and GKE.
- Apigee & API Management: Put an API facade in front of legacy Unix and mainframe backends so you can cut traffic over route by route.
- App Modernisation and Development: View our full application engineering practice.
Have an IBM Power refresh quote sitting on your desk?
Send us your LPAR list and OS levels. In a 20-minute call with an architect who has run large-scale Unix and application migrations at Google Cloud, we will tell you which workloads can recompile straight to Linux on Cloud Run or GKE, and which ones belong on IP4G.
Book a 20-minute AIX reviewQuestions we get asked
Can we run AIX directly in Google Cloud without rewriting everything to Linux first?
Yes. IBM Power for Google Cloud (IP4G) runs Power9 and Power10 hardware connected to your Google Cloud VPC over a low-latency partner interconnect. You can move AIX LPARs via mksysb or NIM backup into IP4G to exit a data centre contract on time, then port applications to Linux on Cloud Run, GKE or Compute Engine at your own pace.
What is the biggest technical risk when moving C or C++ applications from AIX to Linux?
Byte ordering. IBM Power runs AIX in Big-Endian mode, while x86 and Arm on Google Cloud run in Little-Endian mode. Any C or C++ code that reads binary files, casts raw network buffers to structs, or shares memory segments without byte-swapping macros will corrupt integers and floats silently on Linux. We use static analysis and AI code inspection to locate every endian-dependent struct before compiling.
What happens to our Oracle or DB2 databases running on AIX?
You have three options depending on licensing and code coupling: replatform to AlloyDB for PostgreSQL or Cloud SQL using Google Cloud Database Migration Service, move Oracle workloads to Oracle Database@Google Cloud on Exadata hardware inside Google data centres, or keep DB2 on AIX inside IP4G while application tiers move to Cloud Run or GKE.
How do you handle thousands of KornShell (ksh) and cron batch scripts?
AIX uses ksh93 as its default shell and relies on AIX-specific flags for commands like ps, awk, tar, lslpp and errpt. Copying those scripts straight onto Debian or RHEL breaks overnight batch jobs. We parse your script estate, map AIX system calls and LVM paths to Linux equivalents, or replace brittle cron chains with Cloud Workflows and Cloud Run Jobs.
Talk to an architect who has done this before.
Bring your current setup and the outcome you need. You will get a view on the approach, the risks and roughly what it costs.
Straight to a senior GCP architect. No SDR, no slide deck.
Not ready to talk? See how we migrated Hapana off AWS →
Or call +61 2 8359 9507 · Hello@aviato.consulting