Every language we have an engine for—and exactly how far the coverage goes on each.
Each legacy language has its own history and its own peculiarities. This page lists every language we have an engine for — the legacy sources we migrate, the databases under them, the targets we write into, and two engines that are not about migration at all — with what we have already built for each one and where the coverage stops. We would rather you find the limits here than halfway through a project.
We are language engineering experts, and we have never found a language we could not handle. Real-life experience with actual production projects still matters, though: our knowledge means we have already met the most common problems and we recognize the typical program patterns before they surprise anyone.
How to read this page
Every language below carries one of the first two labels, and some entries qualify a particular dialect or version with the third. They describe the evidence behind the coverage, not our enthusiasm for the language.
IBM i (AS/400, iSeries)
An IBM i application is never one language. The business logic is RPG, the file and screen definitions are DDS, the orchestration is CL, and the data access is DB2 SQL. A migration that covers only the first one does not cover the system.
RPG
We have worked on many projects involving IBM RPG IV, including codebases still under active development, in both free-format and traditional fixed-format code. Our RPG Language Engine is battle-tested on more than 30 million lines of production RPG. See our RPG modernization service.
DDS
Data Description Specifications define the physical and logical files, the display screens and the printer output an RPG application depends on. They are parsed by the same engine and the same data model as RPG, which is what lets us follow a field from the screen to the file it lands in.
CL
CL (Control Language) scripts manage the IBM i platform and launch the RPG programs. We have helped companies deal with the language both in the context of a migration from RPG and simply to change CL programs that nobody left on the team understands.
DB2 SQL
DB2 SQL is used on IBM platforms, embedded in RPG or COBOL programs. Working on projects using those languages has let us help companies move off DB2 and onto other databases, such as Oracle DB or PostgreSQL.
Mainframe, data and desktop estates
Outside IBM i the same rule applies: we tell you which dialect we have measured, and which one we would have to look at first.
COBOL
This venerable language has many variants. Our COBOL Language Engine models COBOL 85 at the core—the standard the IBM and mainframe dialects build on—and is validated against the NIST COBOL-85 suite, with selected extensions on top. Which dialect your estate is really written in is one of the first things a Blueprint settles.
SAS
SAS is more than a language: it is a whole system that handles the entire data journey, from storage to analysis. We have worked on many, many legacy projects using SAS, and the parser behind that work is a maintained product of ours rather than a one-off.
EGL
A higher-level universal language designed for application development. EGL is typically translated to COBOL or Java before it runs, which means a migration has to decide whether to follow the generated code or the EGL source—and those are two different projects.
VBA / VB6
We have worked with Visual Basic 6 and Visual Basic for Applications, including the custom platforms companies built on top of them—the spreadsheet that quietly became a production system is a case we have seen more than once.
Database and query languages
Databases carry as much business logic as the programs do, and a migration that moves the code but not the stored procedures has not moved much. These are engines in their own right, not a SQL mode bolted onto another parser.
Oracle PL/SQL
Package bodies, the SQL embedded in them, and the SQL*Plus script wrapped around both, read by one grammar. It also writes PL/SQL back out, which is what makes round-trip refactoring possible.
Microsoft T-SQL
Transact-SQL with a semantic layer on top of the parse: two implementations of one dialect, .NET and JVM, resolving every column against your own schema.
Teradata SQL
On Teradata the DDL is the physical design, and most tools skip it. This grammar reads the storage clauses that decide how a table actually behaves.
Firebird
A .NET Standard 2.0 class library, not a JVM library behind a .NET wrapper, targeting Firebird 4.0.
The target languages, which we also parse
These are not legacy sources. They are the languages we write into, and we maintain engines for them for the same reason: generated code has to be read, checked and regenerated, and that needs a parser at both ends of the pipeline.
Java
Modeled on the Java Language Specification, for pipelines where Java is not the only language. It reads the target as well as writing it.
Python
A Python engine built to write Python, not only to read it: four fifths of its test suite covers generation, because that is what a migration target is for.
Kotlin
Built on JetBrains’ own ANTLR grammar — Kotlin is one of very few languages whose vendor publishes one — for codebases that are half Java.
Engines we license outside migration
Two engines exist for work that is not a migration at all. They are listed here so the set is complete, not because they belong in a legacy estate.
Analytic SQL
A language-services engine for warehouse SQL, and explicitly not a migration parser: a TypeScript library that runs in Node and in the browser, built for editors.
Accellera PSS
A front end for the Portable Test and Stimulus Standard, Accellera’s language for describing verification intent once and generating tests for many execution contexts.
Where we move them to
The source language decides how hard the reading is. The target is your decision, and it is your architecture we write into—not a runtime of ours sitting between you and your own code.
Coverage limits, stated plainly
The list above is what we can defend. Here is what we deliberately do not claim, so that nobody plans around it.
This page is maintained as a reference. If a language matters to your decision and you cannot find it here, ask us and we will tell you plainly whether we have done it, whether we would have to build it, or whether you are better served by someone else.
A migration is priced on what we have measured, not on what we hope to find. Which is why this page names its own limits.
Where to go next
Legacy Modernization
The practice these languages belong to: what a legacy system costs you, how we work, and everything else in the practice.
Migration Blueprint
Where the dialect question actually gets answered. We parse the real codebase and map modules, dependencies, dead code and the risky corners before anyone commits.
Migration CodeCraft
The delivery: automated translation into your target language, tuned until the output is code your own developers would have written.
RPG & IBM i modernization
Four of the languages above live on IBM i. If that is your platform, this is the page written for it.
Ready to move beyond your legacy system?
Let’s work together to create a path forward. Tell us which of these languages you are running and what is pushing you to move, and we will tell you what we would do and what it would cost.
