AI Can Translate the COBOL Now. Moving Db2, IMS and VSAM to PostgreSQL Is the Hard Part

On October 19, 2026, OpenAI reported that its newest model reaches 97.9% accuracy at high reasoning effort on its COBOL migration evaluation, which checks that migrated programs produce byte-for-byte identical outputs. Even OpenAI adds that production software “still requires expert review and testing against the system’s business rules and dependencies.” We agree, and we’d add one more thing: translating the code was never the whole job.

A mainframe can’t be switched off until its data lives somewhere else, matches to the penny, and stays in sync while the old and new systems run side by side. That data is in Db2 for z/OS tables, IMS databases and VSAM files, and each brings its own problems. This guide covers what makes a Db2 to PostgreSQL migration hard, how VSAM and IMS data gets into relational tables, what AWS tooling covers and what it doesn’t, and when to bring in help.

Why is the data harder than the code?

Because code mistakes fail loudly, and data mistakes don’t. A translated program that doesn’t compile gets fixed the same day. A packed-decimal field decoded with the wrong scale, or a record layout read with the wrong copybook, loads without any error and produces wrong balances months later.

The data side has four jobs, and each one needs its own testing:

1. Decode mainframe formats: EBCDIC text, packed and zoned decimal, binary fields.
2. Model the data: copybook layouts for VSAM, segment hierarchies for IMS, and Db2 schemas mapped to PostgreSQL types.
3. Synchronize source and target while both systems run.
4. Reconcile every row and every total before cutover.

How do EBCDIC and packed decimal get converted?

Mainframe data isn’t ASCII or UTF-8. Text is stored in EBCDIC, and there are several EBCDIC code pages (for example, 037 for US English and 1140, its euro-sign version). Using the wrong code page usually works for letters and digits and quietly breaks symbols, accented characters and anything outside the basic set.

Numbers are harder. COBOL commonly stores money and counts as:

• Packed decimal (COMP-3). Two digits per byte, with the sign in the last half-byte. A PIC S9(7)V99 COMP-3 field takes 5 bytes, and the decimal point isn’t stored at all: it comes from the V in the copybook.
• Zoned decimal (DISPLAY). One digit per byte, with the sign carried in the zone bits of the last byte.
• Binary (COMP, COMP-4, COMP-5). Big-endian integers whose size depends on the number of digits.

Converting these requires the copybook for every field, because the bytes alone don’t tell you where the decimal point is. Map them to PostgreSQL NUMERIC(p,s) with the copybook’s precision and scale, never to floating point. Sort order changes too: EBCDIC sorts lowercase letters before uppercase and letters before digits, the reverse of ASCII, so any report or key range that relies on the mainframe’s sort order needs a matching PostgreSQL collation or an explicit test.

How do you migrate VSAM to PostgreSQL?

VSAM files have no schema the database knows about. The layout lives in COBOL copybooks, often several per file, and the copybooks aren’t always current. A VSAM to PostgreSQL migration starts with finding the right copybook for each file and proving it against real records.

What to watch for:

• File types. KSDS (key-sequenced) files map naturally to tables with a primary key. ESDS (entry-sequenced) and RRDS (relative record) files need a surrogate key or an explicit sequence column to keep their order.
• REDEFINES. One record area can hold different layouts depending on a type code. That usually becomes several tables or a type column with nullable fields, and the rule for which layout applies must be found in the code.
• OCCURS and OCCURS DEPENDING ON. Repeating groups and variable-length arrays become child tables, keyed to the parent record.
• Alternate indexes. These become ordinary PostgreSQL indexes, but check that the programs reading them still exist.
• Dirty data. Low-values, spaces in numeric fields and invalid packed-decimal signs are common in old files. Decide up front whether to reject, repair or load them as NULL, and count each case.

We profile every file before writing the load: record counts, record types, invalid fields and key ranges. That profile becomes the baseline for reconciliation later.

Planning a mainframe data migration? Axio Intelligence provides mainframe modernization services, including the data work: copybook mapping, EBCDIC and packed-decimal conversion, IMS and VSAM modeling, sync during the parallel run, and row-level reconciliation. Book a scoping call.

How do you flatten an IMS hierarchy into tables?

IMS stores data as trees of segments: a root segment (a customer, say) with child segments under it (accounts, then transactions under each account). Relational tables don’t have parent pointers built in, so each segment type becomes a table, and each child row carries its parent’s key as a foreign key.

The tricky parts:

• Keys. Child segments often have no key of their own, only a position under the parent. Build a composite key from the parent key plus a sequence number, or generate a surrogate key and keep the original concatenated key for reconciliation.
• Logical relationships and secondary indexes. These link segments across databases. Each one needs an explicit foreign key or join table, and its meaning has to be confirmed in the application code.
• Order. IMS returns child segments in a defined order that programs may depend on. Store that order in a column.
• Access patterns. Programs that walk the tree with DL/I calls will query PostgreSQL very differently. Index for the joins the new code actually runs.

Some teams take an intermediate step and do an IMS to Db2 migration first, especially when the applications will stay on the mainframe for a while. If the target is PostgreSQL anyway, going directly saves one conversion, but it means the code that reads IMS has to change at the same time.

What does AWS cover for Db2 z/OS to PostgreSQL?

AWS has the most documented path for Db2 for z/OS to PostgreSQL, and it’s worth knowing where it stops.

• Schema conversion. AWS DMS Schema Conversion converts Db2 for z/OS schemas to Amazon RDS for PostgreSQL or Aurora PostgreSQL. There’s no console experience for this path: every setting is configured through the AWS CLI or the DMS API. The settings include how numeric columns without explicit precision are mapped (NUMERIC by default, or BIGINT), how stored procedures that return dynamic result sets are converted, how partitioned tables are handled, and the string formats for DATE and TIME values.
• Data movement. AWS DMS can read Db2 for z/OS, but its documentation lists important limits: only full-load tasks are supported, change data capture (CDC) isn’t, and parallel load isn’t either. The source endpoint uses the IBM Data Server Driver for ODBC and requires a valid IBM ODBC Connect license.
• The gateway pattern. AWS published a Db2 z/OS to Aurora PostgreSQL pattern on September 30, 2026. It runs IBM Db2 Connect on an EC2 instance as a gateway to the mainframe over VPN or Direct Connect, uses DMS for the full load and scheduled full-load refreshes, and validates by comparing row counts and schema objects.

That’s a solid starting point for schema conversion and the initial load. It isn’t a near-zero-downtime migration on its own, because periodic full reloads aren’t change capture.

What does Db2 Connect licensing mean for the project?

Any tool that reads Db2 for z/OS from off the mainframe over DRDA needs IBM connectivity, and that’s licensed. The AWS documentation states the requirement plainly: a valid IBM ODBC Connect license for the DMS source endpoint, with the gateway pattern running IBM Db2 Connect on EC2.

Plan for it early:

• Check whether you already own Db2 Connect entitlements, and on which terms.
• Budget for it for the full length of the parallel run, not just the first load.
• Include it in the business case alongside the mainframe software costs you’re trying to retire. Our post on what sets your z/OS software bill explains why moving workload off the mainframe can lower the monthly bill even before the mainframe is gone.

How do you keep data in sync during the parallel run?

Parallel running is how you prove the new system before you trust it, and it needs the PostgreSQL side to stay current with the mainframe. There are three common approaches:

• Scheduled full reloads. Simple and the approach in the AWS pattern, but practical only for tables small enough to reload inside the window, and the target is always somewhat behind.
• Log-based change data capture. A replication product that reads the Db2 for z/OS log (IBM’s InfoSphere Data Replication is one example) streams inserts, updates and deletes to PostgreSQL. This is the usual choice for large, busy tables, and it has its own licensing and mainframe setup.
• Application-level sync. Batch jobs extract changed records using timestamps or change flags already in the data. This works when the data model supports it, and it’s often the only option for VSAM files.

Whichever you choose, decide which side is the system of record for each table during the parallel run, and test the cutover in rehearsals, including how you’d roll back.

How do you prove the data matches?

Row counts aren’t enough. A table can have the right number of rows and still be wrong in every amount column. Real reconciliation compares content:

• Row counts per table and per partition or key range.
• Totals of every money and quantity column, compared to the cent.
• Hashes of every row, computed the same way on both sides after normalizing formats, so each mismatch points to a specific record.
• Business checks: account balances, open orders, records by status. These are the numbers the business already trusts from mainframe reports.

Run reconciliation after every load and every sync cycle during the parallel run, not just at the end. The COBOL modernization plan we described earlier relies on the same principle: verify independently, then cut over one piece at a time.

Where should Db2 data land: RDS, Aurora or somewhere else?

AWS DMS Schema Conversion targets Amazon RDS for PostgreSQL and Aurora PostgreSQL. Other managed PostgreSQL services, or PostgreSQL on your own servers, work too, but you’ll handle schema conversion with other tools or by hand. The decision usually follows where the new applications will run. If you’re also leaving Oracle elsewhere, our guide to Oracle to Postgres migration costs covers the same decision for that side of the estate, and our database migration services cover both.

When should you hire mainframe modernization services?

Bring in outside help when:

• The data is in IMS or VSAM, not only Db2. Copybook archaeology and hierarchy flattening are specialist work.
• Money moves through the data. Packed-decimal and rounding mistakes are expensive, and reconciliation has to be designed in from the start.
• You need a long parallel run. CDC design, licensing and rollback planning take experience.
• Your mainframe team is small and busy. The people who know the copybooks are usually the ones keeping production running.

A good partner should leave you with the mappings, reconciliation reports and runbooks, not just migrated tables.

FAQ

Can AWS DMS migrate Db2 z/OS to PostgreSQL?

Yes, for the full load. AWS DMS supports Db2 for z/OS as a source for full-load tasks only. Change data capture and parallel load aren’t supported, and the source needs a valid IBM ODBC Connect license. DMS Schema Conversion handles the schema, configured through the CLI or API.

How do you migrate VSAM to PostgreSQL?

Find and verify the COBOL copybook for each file, decode EBCDIC text and packed or zoned decimals using it, turn REDEFINES and OCCURS structures into tables, and load into PostgreSQL with NUMERIC types. Then reconcile counts, totals and row hashes against the source.

What is packed decimal, and how does it map to PostgreSQL?

Packed decimal (COBOL COMP-3) stores two digits per byte, with the sign in the last half-byte. The decimal point isn’t stored; it comes from the copybook. Map it to PostgreSQL NUMERIC with the copybook’s precision and scale, never to floating point.

Should we migrate IMS to Db2 first?

Only if the applications will stay on the mainframe for a while. If PostgreSQL is the final target, going straight there avoids a second conversion, but the programs that read IMS have to change at the same time.

Can AI do the data migration too?

AI helps with copybook analysis, mapping drafts and test generation. But the proof that data matches has to come from reconciliation against the source, not from the model.

Talk it through

If you’re planning to move Db2, IMS or VSAM data off the mainframe and want a realistic read on the effort, we’re happy to look at it with you. Book a call and bring a list of your databases and files, even a rough one.