The Codegiant team did a deep dive into AWS Transform for mainframe and ran conversions through it, because the fastest way to understand a modernization product is to put real mainframe code through it. The code we used is AWS's own open-source CardDemo application, so nothing here rests on a codebase we chose. Here is what we found, written up so you can see how it actually works rather than how it is marketed.
This is an apples-to-apples comparison. AWS Transform for mainframe converted the COBOL to Java, and Codegiant converted the same COBOL to Java. That is the fair meeting point. Codegiant can convert to more than Java, with more target frameworks on the way, so Java is where the two meet rather than the limit of what we do.
Every point below comes back to one thing: AWS Transform for mainframe locks you into AWS's runtime. The code they hand you does not stand alone, the data is not readable without them, the batch does not run without them, and you pay them per CPU core per hour to keep it alive. Codegiant takes the opposite route: no vendor runtime, no proprietary engine, a real conversion you own outright.
If you are shortlisting mainframe modernization companies, or comparing mainframe application modernization approaches, the points below decide whether you rent a conversion or own one. Treat them as what they are: the requirements any vendor should be held to. What follows is a summary of what we found, the baseline we tested against, then a high-level comparison chart you can scan in two minutes, and the full deep dive with the evidence behind every line.
Summary
- Runtime. The Java AWS Transform for mainframe emits imports their runtime. Remove it and the code stops compiling. Codegiant's output is pure Java, your code from start to finish, so it always compiles.
- Data. AWS Transform stores your fields as mainframe bytes inside a vendor object, which is why a plain query against the table does not work. Codegiant produces real PostgreSQL tables with real columns and indexes, and ordinary Java types any developer reads on day one.
- Batch. AWS Transform rewrites your jobs into their own script language, so they only run on their runtime. Codegiant produces standard Java jobs, started by whatever scheduler you already use.
- Cost. AWS Transform charges per CPU core per hour, forever, on top of the servers, and documents the runtime only on AWS. Codegiant has no runtime to license or pay for.
- Equivalence. AWS Transform's compare tool diffs files and tables, and you set up and run it yourself. Codegiant runs the Java and the original COBOL on the same input and compares every output file, return code and file status byte for byte, automatically, with control totals that must match.
- Dead code. AWS Transform has no check for it. Codegiant checks the source against what actually runs in production: 30–40% of the code sitting in production never executes, so it is flagged rather than converted.
- Requirements met. Both products were graded against the same 46 requirements, from whether the code compiles without a vendor runtime to whether the data is readable with plain SQL. AWS Transform for mainframe meets 3 of 46. Codegiant meets 46 out of 46.
What we tested
Both conversions in this comparison ran on the same application: CardDemo, the credit-card management application AWS publishes on GitHub to showcase its own mainframe modernization tooling. It is open source under Apache 2.0, and it is the application AWS itself uses to demonstrate AWS Transform for mainframe.
That matters for one reason: the test subject is theirs, not ours. We did not pick a codebase that suits our converter, and the repository is public, so you can see exactly what both products were given. Both received the same source, the same copybooks, the same file definitions and the same JCL, with nothing pre-processed, corrected or staged for either product.
Each row below is a requirement for a modernization you can run yourself. A row counts only if the delivered system works without the vendor's runtime, without the vendor coming back, and without a per-core charge. Three rows earn AWS partial credit, where they ship a mechanism you set up and run yourself: Equivalence, Test data and Migration planning.
How Codegiant scores against AWS
AWS Transform for mainframe |
Codegiant |
|---|---|
3 of 46 |
46 of 46 ✅ |
AWS Transform for mainframe vs Codegiant: the comparison at a glance
Both convert COBOL to Java. One of them replaces your mainframe with a vendor's runtime. The other replaces it with Java. Click any point to jump to the full comparison.
AWS Transform for mainframe |
Codegiant |
|
|---|---|---|
1. The converted code |
0 of 7 |
7 of 7 |
The generated code imports their runtime. Remove it and it won't compile |
No proprietary runtime. It's standard Java and compiles anywhere |
|
Your data is stored in AWS's own custom classes, which only their runtime understands |
Your data uses ordinary Java types any developer can read |
|
Each COBOL paragraph becomes its own method, so the code still reads like COBOL |
Methods are named for what the business does, like postTransaction() |
|
Their fix is an AI rewrite applied afterwards, and anything it can't convert is left for you |
The Java is structured correctly from the start, and every piece is checked before it's kept |
|
The app still runs like a mainframe internally, using the mainframe's own EBCDIC character encoding in memory |
Normal Java in memory. The mainframe character encoding is handled only where files come in and go out |
|
Your COBOL is first rewritten into their engine's private language, and only their engine can turn it into Java |
Every step is our own code, with no proprietary binary or engine, so you can easily update or change it later |
|
Settings like number handling and encoding are properties on their runtime, set by hand |
The same COBOL behaves differently at two companies, so we read all of it from the client's own files and build it into plain Java |
|
2. Data |
0 of 3 |
3 of 3 |
Each record is stored as raw, unreadable bytes inside the database |
Records become real database tables with real columns and indexes |
|
You can't query a balance directly. It's buried in a blob only their runtime reads |
Any reporting tool or new service reads the data directly |
|
Updates are batched and written about a second later |
Every write reaches the database immediately |
|
3. DB2 |
0 of 4 |
4 of 4 |
Your SQL is pulled out into lookup files that only their runtime can execute |
Your SQL is translated into normal database code inside the generated classes |
|
Files and database tables are handled by two separate mechanisms inside their runtime |
Every file call and every database call returns the same kind of result |
|
VSAM data and DB2 data still live in separate worlds |
Both end up in PostgreSQL, so a file update and a table update can commit together |
|
No per-call check against the original |
Every SQL call has an identity checked against the Java |
|
4. Batch |
0 of 3 |
3 of 3 |
Batch jobs become scripts that only run on their runtime |
Standard Java jobs, with high-throughput job queueing already built into the transformed output, and started by whatever scheduler you already use |
|
Sort and file-management steps are pasted in as text for their runtime to interpret |
Those steps become ordinary batch steps, with the same results as the mainframe |
|
Restart depends on their runtime |
The checkpoint is saved in the same commit as the data, so a rerun never posts twice |
|
5. Running and cost |
0 of 5 |
5 of 5 |
Documented only on AWS servers |
Any of 7 clouds, on-premises, or Kubernetes |
|
$0.31 per CPU core per hour, forever, on top of the servers |
Pure Java output. No runtime to license or pay for |
|
AWS has already closed two of its own mainframe runtime products to new customers |
Nothing in your system depends on a vendor's roadmap |
|
You need several separate tools, downloaded and set up individually |
One platform, from analysis through to deployment |
|
Nothing checks that the converted jobs run as fast as the original |
Every job is timed against the mainframe's batch window and fails if it's slower |
|
6. How each one uses AI |
0 of 3 |
3 of 3 |
A rules engine that copies COBOL's structure, then optionally an AI rewrite over whole classes, with failures left for you |
Rules do everything with one right answer. AI only writes decisions, inside a locked skeleton |
|
The rules engine copies COBOL's structure, and the rest is left to the AI rewrite |
Everything: parser facts, technical analysis, data classes, access classes, schema, job plans, function slices, skeletons, names and variable maps, no AI involved |
|
No per-line check against the original, and no check that the rewrite invented nothing |
Compilation, real methods, allowed constructs, every field written, conditions the right way round, every number traced to source. Two repair rounds, then it is set aside |
|
7. Before conversion |
1 of 7 |
7 of 7 |
Their documentation and business rules are generated by AI |
A full technical document built from the code itself, every fact tied to a source line, no AI involved |
|
None |
Every COBOL statement is captured with its real operands |
|
None |
The AI narrates only facts already proven, and a separate judge catches anything it drifts into |
|
None |
Each function is traced backwards from what the program actually produces |
|
AWS Transform gives you graphs and domains |
Click any link and see the exact source line behind it, and the conversion decision it drove |
|
Domain splitting and wave planning |
Groups are formed where nothing inside a group is written from outside it |
|
None |
The source is checked against what actually runs in production. Dead code is flagged rather than converted |
|
8. After conversion |
2 of 6 |
6 of 6 |
Their compare tool diffs files and tables, and you set up and run it yourself |
The Java and the original COBOL run on the same input and are compared automatically, byte for byte |
|
Generated scripts you run on the mainframe to collect data |
Real production inputs and outputs captured and replayed, plus edge cases built from the copybooks |
|
No control-total check |
Record counts and balances must match what the COBOL already computes |
|
Their AI rewrite comes with no check that it invented nothing |
Anything in the Java without a basis in the COBOL is flagged |
|
None |
A checker catches the classic conversion mistakes |
|
A test environment inside your AWS account |
A parallel run on live traffic, old and new side by side, before anything switches over |
|
9. The platform |
0 of 8 |
8 of 8 |
Deploys to AWS only |
Deploys in one click to AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Cloudflare or Fly.io, or on-premises, or any Kubernetes infrastructure you run |
|
Your data lives in their proprietary store, tied to their runtime |
Your tables go to your own managed database, deployed with the app |
|
AWS Transform hands you templates and you build the rest yourself |
The whole toolchain is included, nothing to assemble |
|
Their offering stops once the code is delivered |
An AI operations assistant watches the system around the clock, repairs incidents and tunes cost |
|
None |
Kronos Automate, Codegiant's own LLM, connects to 3,000+ services so you can build automations and workflows on top of your modernized transformation. Each modernized app gets its own dedicated automation tenant, running an enterprise-grade engine that supports hundreds of millions of events per month |
|
None |
New apps, agents and workflows on the transformed code, with the app builder, workflow builder and automation engine included |
|
None |
Role- and attribute-based access, audit trails and policy enforcement |
|
None |
Kronos models purpose-built for mainframe modernization and automation, which can be self-hosted inside your perimeter for added safety |
1. The converted code
Runtime
AWS Transform: 97% of the Java imports their runtime. Remove it and the code does not even compile.
Codegiant: the output is pure Java, your code from start to finish. Nothing proprietary sits underneath it, so it always compiles.
Data fields
AWS Transform: an account balance becomes new Elementary(root, new ZonedType(10,2,...)), a vendor object wrapped around mainframe bytes. Even a single counter becomes a whole class.
Codegiant: the balance is a BigDecimal, a date is a date, a name is a String. Plain Java any developer reads on day one.
Program shape
AWS Transform: one method per COBOL paragraph, DataUtils.compare("00", status) checks, and Legacy: 0000-DALYTRAN-OPEN labels in the comments.
Codegiant: methods named for what the business does, like postTransaction() instead of _2000Post(). Real Java, not COBOL in disguise.
AWS Reforge
AWS Transform: AWS's own fix for the point above is an AI rewrite of the program classes after conversion. The data classes still sit on their runtime, files that do not compile are left for you, and AWS makes no claim that behaviour is preserved.
Codegiant: the Java is shaped right from the start, and every piece is checked before it is kept. Nothing to clean up afterwards.
The mainframe inside
AWS Transform: the app is configured as LegacySystem.ZOS with the EBCDIC code page in memory, so it is a mainframe emulated inside Java.
Codegiant: normal Java in memory. Mainframe encoding exists only where files come in and go out.
Changing it later
AWS Transform: COBOL is first rewritten into their engine's own language, and only their engine turns that into Java.
Codegiant: every step is plain code, with no vendor lock-in. A new pattern means changing a rule and running the conversion again, not waiting for a vendor release.
Outside the code
AWS Transform: settings like number handling and encoding are properties on their own runtime, set by hand in its configuration.
Codegiant: the same COBOL behaves differently at two companies, because compiler settings, run-time settings and the JCL change what it does. All of it is read from the client's own files and built into plain Java. Nothing to configure, nothing hidden in a runtime.
2. Data
VSAM
AWS Transform: Blusam stores each record as raw mainframe bytes inside PostgreSQL, and their CICS layer (JICS) is emulated on the same runtime too.
Codegiant: real PostgreSQL. Real tables, real columns, normal keys and indexes, with the original record order kept wherever programs depend on it.
Using the data
AWS Transform: SELECT balance FROM accounts does not work, because the balance is bytes inside a blob that only their runtime can read.
Codegiant: any SQL tool, report, dashboard or new service reads it directly. AWS Transform has no readable data.
Write safety
AWS Transform: their own docs say updates are batched and written about a second later.
Codegiant: every write reaches the database immediately, with commits in safe groups.
3. DB2
SQL handling
AWS Transform: the SQL text is lifted into lookup files (COBTUPDT_1=INSERT INTO ...) that their runtime runs by key.
Codegiant: SQL is translated to PostgreSQL inside generated data-access classes, exactly how well-migrated banks and Java-built banks both do it.
One model for files and tables
AWS Transform: files and DB2 are handled by two different runtime mechanisms.
Codegiant: every DB2 call and every file call returns the same kind of typed result.
One database, one commit
AWS Transform: VSAM data and DB2 data still live in separate worlds.
Codegiant: both end up in PostgreSQL, so a program's file update and table update can commit together, which the mainframe could never do.
Every SQL call tracked
AWS Transform: no per-call check against the original.
Codegiant: every SQL call has an identity checked against the Java. Nothing lost, nothing invented.
4. Batch
Jobs
AWS Transform: JCL becomes Groovy scripts that only run on their runtime.
Codegiant: JCL becomes jobs in a standard Java batch framework, with a job record and restart, started by whatever scheduler the client already uses. AWS Transform has no standard Java batch.
Utility steps
AWS Transform: SORT and IDCAMS cards are pasted in as text strings for their runtime to interpret.
Codegiant: utility steps become standard batch steps (database operations, file steps and sorting) with results identical to the mainframe.
Restart
AWS Transform: restart depends on their runtime.
Codegiant: the checkpoint is saved in the same commit as the data, so a rerun never posts twice. That is better than the mainframe itself.
5. Running and cost
Where it runs
AWS Transform: documented only on AWS servers.
Codegiant: any of 7 clouds, on-premises, or Kubernetes. Wherever Java and PostgreSQL run.
Runtime fee
AWS Transform: $0.31 per CPU core per hour, forever, on top of the servers.
Codegiant: Pure Java output. No runtime to license or pay for.
AWS can change the rules
AWS Transform: AWS has already stopped taking new customers for two of its own mainframe runtime offerings.
Codegiant: nothing in your system depends on any vendor's roadmap.
Tools needed
AWS Transform: a kit of separate downloads (terminal app, admin consoles, compare tool, data migrator).
Codegiant: one platform, from analysis to deployment.
Speed
AWS Transform: no speed gate.
Codegiant: every job is timed against the mainframe's batch window and fails if it is slower. Loops that only filter and total become a single database statement.
6. How Codegiant and AWS use AI differently
Where AI sits in the pipeline
AWS Transform: a rules engine that copies COBOL's structure, then optionally an AI rewrite over whole classes, with failures left for you.
Codegiant: rules do everything with one right answer, and AI only writes the decisions, inside a locked skeleton where every line is checked.
What the AI gets: one small slice, already wrapped in its skeleton, with only the fields and files it touches. It writes the decisions, and cannot invent a class, a file call or SQL.
What the rules decide before AI is involved
AWS Transform: the rules engine copies COBOL's structure, and the rest is left to the AI rewrite over whole classes. There is no locked skeleton and no per-line check that a rewritten line still matches the COBOL.
Codegiant: everything below is produced by rules, before any AI is involved:
- the parser facts for every statement
- the technical analysis
- the data classes
- the file and database access classes
- the database schema
- the job plans
- the business-function slices
- the skeletons, with every file call already placed
- the names
- the variable maps
What every line has to pass
AWS Transform: no per-line check against the original, and no check that the rewrite invented nothing.
Codegiant: every line is checked before it is kept:
- it compiles
- it only calls real methods
- it only uses allowed things
- every field the COBOL writes is written
- conditions are the right way round
- every number traces back to the source
At most two repair rounds, and anything that fails is set aside with the reason.
Same starting point, better result: AWS converts CBTRN02C with zero issues. Codegiant does too, and its output is real Java on real data.
7. Before conversion: understanding
Analysis without AI
AWS Transform: their documentation and business-rule extraction are generated by AI.
Codegiant: a full technical document built from parser facts, every fact tied to a line of source, no AI involved. AWS Transform has no analysis you can trust line by line.
Statement-level facts
AWS Transform: none.
Codegiant: every COBOL statement is captured with its real operands, including ALTER, GO TO targets and dynamic CALL possibilities as explicit facts.
Business logic grounded in facts
AWS Transform: none.
Codegiant: the AI narrates only facts already proven, and a separate judge catches anything it drifts into.
Business functions from outputs
AWS Transform: none.
Codegiant: each function is traced backwards from what the program actually produces.
Estate graph with line-level proof
AWS Transform: graphs and domains.
Codegiant: click any link and see the line that created it, and which conversion decision it drove. AWS Transform does not have every link tied to source and to a decision.
Migration plan as a calculation
AWS Transform: domain splitting and wave planning, so compare only on whether each group is proven closed.
Codegiant: groups are formed where nothing inside a group is written from outside it.
Dead code checks
AWS Transform: none.
Codegiant: the source handed over is checked against what actually runs in production. In the estates Codegiant has run through, 30–40% of the code sitting in production never executes. It is dead, and there is no reason to pay to convert it. The same check catches code that has drifted from the library it was handed, so it never converts the wrong version perfectly.
8. After conversion: proof
Equivalence
AWS Transform: their Compare Tool diffs files and tables, and you set up and run the comparisons yourself.
Codegiant: the Java and the original COBOL run on the same input, comparing every output file, return code and file status byte for byte, automatically.
Test data
AWS Transform: generated scripts you run on the mainframe to collect data.
Codegiant: real production inputs and outputs captured and replayed, plus edge-case test data built straight from the copybooks.
Business totals
AWS Transform: no control-total check.
Codegiant: record counts and balances must match what the COBOL already computes, for example the same number of transactions posted and the same total amount.
Hallucination
AWS Transform: Reforge's AI rewrite comes with no check that it invented nothing.
Codegiant: anything in the Java without a basis in the COBOL is flagged. AWS Transform does not check for it.
Known bug patterns
AWS Transform: none.
Codegiant: a Java checker catches the classic conversion mistakes, such as trimming fixed-width fields with .trim(), wrong decimal handling, or treating a short read as a clean end of file.
Cutover
AWS Transform: a test environment inside your AWS account.
Codegiant: a parallel run on live traffic, old and new side by side, before anything switches over.
9. The Codegiant platform: where everything goes after conversion
One-click deploy
AWS Transform: deploys to AWS only.
Codegiant: the converted app deploys in one click to the client's choice of AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Cloudflare or Fly.io.
Database
AWS Transform: Blusam on their runtime.
Codegiant: the PostgreSQL tables go to the client's managed database, deployed with the app.
DevSecOps
AWS Transform: infrastructure templates, and you assemble the rest.
Codegiant: its own toolchain with nothing to wire up: Git, CI/CD, Terraform, observability, error and performance monitoring, uptime checks, status pages, docs and code review.
After go-live
AWS Transform: their offering stops at the code and the templates.
Codegiant: AI SRE, 24/7. It watches the running system, repairs incidents, tunes cost and scaling, catches security drift and keeps runbooks current.
Connect
AWS Transform: none.
Codegiant: Kronos Automate, Codegiant's own LLM, connects to 3,000+ services so you can build automations and workflows on top of your modernized transformation. Each modernized app gets its own dedicated automation tenant, running an enterprise-grade engine that supports hundreds of millions of events per month.
Build
AWS Transform: none.
Codegiant: new apps, agents and workflows on top of the transformed code. The app builder, the workflow builder for agents and the automation engine are all included, with no add-ons and nothing to bolt on.
Governance
AWS Transform: none.
Codegiant: role- and attribute-based access, audit trails and policy enforcement across everything.
Purpose Built Models
AWS Transform: none.
Codegiant: Kronos models purpose-built for mainframe modernization and automation, which can be self-hosted inside your perimeter for added safety.
The bottom line
AWS Transform for mainframe does not replace your mainframe with Java. It replaces it with their runtime: their types, their blob storage, their Groovy batch, their EBCDIC-in-memory emulation, their per-core meter, and their roadmap. Codegiant generates plain Java on real PostgreSQL that runs anywhere, proves equivalence automatically, and does not bill you forever to keep running. That is the difference between a conversion you rent and a system you own.
Related Reading
- COBOL to Java migration
- COBOL modernization
- Mainframe to cloud migration
- Legacy system modernization
- Application modernization tools
Try Codegiant's Enterprise AI Platform Today
Codegiant is an enterprise AI platform that gives you full control of the code. What comes out of the conversion is yours: no vendor runtime, no proprietary binary, no engine underneath it. You can read it, change it, and run it wherever you want.
Nothing gets bolted on afterwards. The DevSecOps toolchain, CI/CD, Terraform, observability, uptime checks and AI SRE come with the conversion, and the finished application deploys in one click to AWS, Google Cloud, Azure, Oracle Cloud, DigitalOcean, Cloudflare or Fly.io, or on-premises, or any Kubernetes infrastructure you run.
Kronos Automate, our own LLM, connects the modernized system to 3,000+ services so you can build automations and workflows on top of it. Each modernized app gets its own dedicated automation tenant, running an enterprise-grade engine that supports hundreds of millions of events per month. That is what strict modernization requirements actually demand, and it is the part most platforms stop short of: every target your own policy allows, the whole toolchain in your hands, and no binary, no runtime and no lock-in carried into the next project.