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.

In the translated Python, embedded SQL becomes database calls using SQLAlchemy or psycopg2 — depending on the target database and project preferences. The SQL itself is preserved and adapted to the target database dialect. If you're staying on DB2 for i, we use ibm_db2 drivers; if you're moving to PostgreSQL, the SQL is adapted accordingly.

Cursor management, host 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.

Python can run on IBM i through PASE, the Unix-like compatibility environment built into the OS. However, this is not the same as Java running natively on the JVM. PASE adds overhead and complexity, and most organisations choosing Python as a migration target are doing so precisely because they intend to leave IBM i behind. A Python migration therefore typically involves a platform change as well as a code change.

For many organisations, this is not a constraint — it's the goal. The IBM i hardware and licensing costs are a significant burden, and moving off it is part of the business case for migration. The combination of code migration (RPG → Python) and platform migration (IBM i → Linux or cloud) is something we plan carefully from the start.

The platform move does not need to happen on day one. A common approach: the Pilot and initial iterations run on Linux test infrastructure while IBM i handles production. Once confidence is established, production traffic is gradually shifted. This keeps business risk low during the transition.

If your organisation wants to stay on IBM i and run cleanly without PASE overhead, Java is the stronger target — the JVM runs natively on IBM i since V4R2. We will tell you this honestly and point you to rpg2java.com. We have no interest in fitting clients into the wrong service.

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: Web-based equivalent. If you want a web interface that faithfully reproduces the layout and interaction model of your existing IBM i screens, we can expose the business logic via a FastAPI or Django backend and generate a straightforward web 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, integration with modern data visualisation — 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 migrated Python code can continue to work with DB2 for i remotely — connecting from Linux using ibm_db2 drivers. There is no requirement to migrate the data as part of the code migration. Some clients choose this approach for the first phase, which significantly reduces the scope and risk of the initial project.

Most Python migrations eventually move to PostgreSQL, which has become the standard relational database for Python applications and is supported by the entire Python data science and web framework ecosystem. Moving the database 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 Python code we deliver uses SQLAlchemy's abstraction layer where appropriate, which means adapting to a different database is a contained change — it does not require redoing the business logic translation.

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 moves, schema translation involves understanding the DB2-specific data types, constraints, and logical file relationships, and mapping them appropriately to the target. We scope database migration explicitly and separately from the code migration.

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.

We sign an NDA as part of the engagement, before you share anything. 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.

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 Python code, the test suite, and the supporting runtime library 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 a runtime library prepared for the translated code — a supporting package that handles IBM i-specific behaviour your RPG code relied on, such as indicator management, packed decimal arithmetic, and certain data type conversions. You receive this as open-source Python that you can read, modify, and build on.

There are no hidden dependencies. The translated system is designed to be maintainable by any competent Python team — and since Python is the most widely learned language in the world, hiring that team is considerably easier than hiring RPG developers.