Technical deep dive

Embedded SQL is a normal part of RPG codebases, not an edge case. Most production RPG programs access DB2 for i using embedded SQL directly in the source code. We handle this as a standard part of the migration.

The embedded SQL is parsed alongside the RPG code. In the translated Java, it becomes JDBC calls. The SQL itself is preserved and executed against the same DB2 database unless the project scope includes moving to a different database — which is a separate decision discussed below.

Cursor management, host variables, indicator variables, and SQLSTATE/SQLCODE handling are all translated. If your RPG uses particularly complex SQL patterns — dynamic SQL, multi-row fetch, stored procedures — we identify these during the Pilot analysis and discuss how they will be handled.

We can work with DDL alongside the RPG migration. This includes physical files, logical files, and SQL DDL definitions. If your physical file definitions are expressed as DDS rather than SQL DDL, we can handle the translation of those structures as well.

Whether the target database remains DB2 for i or moves to another platform — PostgreSQL, for example — is a project decision. Both options are feasible. The question is usually decided by what the rest of the infrastructure looks like and how far the business wants to go in the first phase of modernisation.

If the database stays on IBM i, the translated Java uses JDBC to connect to the same DB2 it always has — no data migration, no schema changes required. If the database moves, that involves schema translation, data migration, and adapter-layer changes in the Java code. We scope this explicitly and separately from the code migration.

Display files are part of the migration scope. We are clear about what is translation and what is redesign — because these are different things that should be scoped differently.

Option 1: Faithful reproduction. If you want a web interface that faithfully reproduces the layout and interaction model of your existing IBM i screens, we can generate a React-based frontend that mirrors the original. This is translation — it preserves what already exists in a new medium.

Option 2: Modernised web frontend. If you want to use the migration as an opportunity to redesign the user interface — improved workflows, modern UX patterns, mobile-friendly layouts — that is also possible. But this is UI design, not translation. It takes longer, requires more input from people who understand the business workflows, and should be costed accordingly.

We do not blur this distinction. You will know exactly which option is in scope before we start.

The JVM has run natively on IBM i since V4R2. This means the translated Java code can be deployed on the same hardware as your existing RPG system — no immediate infrastructure change required.

This is one of the practical reasons Java is a strong migration target. You can run Java and RPG side by side during the migration. A module is migrated to Java, deployed on IBM i, validated in production, and only then is the RPG version retired. The risk at each step is bounded.

Moving to Linux — or any other platform — is also feasible and some clients do it as a second step after the code migration is complete. If that is your goal, we discuss it during the Pilot so the translated code is structured to make the eventual Linux deployment straightforward.

The decision between IBM i and Linux does not have to be made before starting. The code migration can proceed while the infrastructure decision is still being evaluated.

The migrated Java system can continue to work with DB2 for i. There is no requirement to migrate the database as part of the code migration. Many clients choose to keep the data on IBM i for at least the first phase, which significantly reduces the scope and risk of the initial project.

If you later want to move to PostgreSQL, Oracle, or another external database, that is a separate project. It involves schema analysis, data migration, and testing against the new database. We can assist with this, but it is not bundled into the code migration.

The Java code we deliver is written with standard JDBC. Adapting it to a different database is a contained change — it does not require redoing the business logic translation.

Most RPG codebases that have been in production for 20 or 30 years have accumulated inconsistencies: programs that use different conventions, modules that were written by different developers at different times, workarounds that were added when the original design didn't fit the business requirement, and patterns that violate every principle a modern developer would recognise.

This is common, not exceptional. It does not make migration impossible. It does mean that more complex systems require more work per line of code — more careful analysis, more review, more collaboration with people on your side who understand why the code does what it does.

The Pilot assessment is partly an assessment of complexity. At the end of the Pilot, we give you an honest view of what the full migration would involve for your specific codebase — including where the difficult parts are and what they will cost in time and effort.

We do not tell you the migration is straightforward if it isn't. That serves neither of us.

Your source code contains your business logic — the logic that differentiates your business from your competitors. It is treated with corresponding care.

Your source code is used only to perform the migration. It is not shared with any third party, not used for any other purpose, and not retained after the engagement concludes. We are happy to sign an NDA before you share anything.

The toolchain runs on infrastructure we control. It is not processed through third-party AI services or stored in any system outside our control. If you have specific requirements about where your code can be processed — for example, because of regulatory obligations or internal security policies — raise them before sharing anything and we will confirm what is possible.

For European clients with data sovereignty requirements — GDPR obligations, sector-specific regulations, or internal policies that prohibit processing on non-EU infrastructure — we can run the entire migration toolchain on European-hosted infrastructure with no dependency on U.S.-based services or cloud providers.

This includes the transpiler, the analysis toolchain, and any intermediate storage of your source code during the migration.

If this is a requirement for your organisation, raise it at the start — before sharing any code — and we will confirm the specifics for your situation.

Everything we deliver belongs to you. The translated Java code, the test suite, and the runtime are yours. There is no licence, no subscription, and no ongoing dependency on us to operate what we delivered.

You can maintain it, modify it, extend it, or hand it to another team or vendor entirely. You are not locked in to us for future work. The code runs without any Strumenta component in the deployment.

We provide the runtime prepared for the translated code. "Runtime" here means the supporting library that handles the IBM i-specific behaviour your RPG code relied on — things like indicator management, certain data type conversions, and integration patterns. You receive this as open-source code that you can read, modify, and build on.

There are no hidden dependencies. The translated system is designed to be maintainable by any competent Java team.