Functional-equivalent C#
Straight translation, faster and lower cost. The right call when the priority is getting off the mainframe and out from under COBOL maintenance.
Your COBOL becomes maintainable C# on .NET, translated by DMS, our symbolic AI engine that deterministically translates code to a functional-equivalent target language. Same behaviour. Code your .NET team can read.
Trusted By
If you already run on Microsoft, C# is the shortest path from the mainframe to something your teams can maintain.
Azure or on-premises, SQL Server, Entra ID, Visual Studio. The system lands where your people already work.
We target .NET 10, the current Long Term Support release, with ASP.NET Core and Entity Framework Core.
Windows or Linux from one build. Containers on AKS, ECS or EKS, or your own datacentre.
C# developers are available at volume. The recruiting problem that started this conversation goes away.
Straight translation, faster and lower cost. The right call when the priority is getting off the mainframe and out from under COBOL maintenance.
Output shaped to how your teams build now: dependency injection, service boundaries, EF Core persistence. Gen AI helps configure DMS for this.
You can start direct and refactor later, since you own the code either way.
A translation that compiles isn’t the same as one you can live with. Here’s what each COBOL construct becomes.
| In your COBOL | In the generated C# |
|---|---|
| COBOL program | C# class holding program data, with methods derived from the PERFORM structure |
| 01 level record layout | Its own C# class alongside the program class |
| COPY library | tShared C# type, merged across programs, so the record is edited in one place |
| COMP-3 packed decimal | Native decimal, or ScaledLongs where arithmetic throughput matters |
| Level-88 condition name | Read-only property evaluated against the live parent field |
| GO TO and paragraph jumps | Structured control flow. No labels, no goto anywhere in the output |
| EVALUATE TRUE | if, else if, else chain with evaluation order preserved |
| VSAM, IMS, | Relational tables reached through Entity Framework Core |
| EXEC CICS READ, WRITE, REWRITE | EF Core access inside explicit transaction scopes |
| Pseudo-conversational CICS | ASP.NET Core controllers with server-side session state |
| JCL job step | .NET Worker Service step, with restart and conditional flow preserved |
If a translation tool has burned your team before, one of these is why.
Also handled by named rule:
PERFORM THRU and VARYING, COPY REPLACING, SEARCH ALL, RENAMES, SYNCHRONIZED alignment, sign trailing overpunch, and the dialect extensions in your particular COBOL.
Functional equivalence is a testing outcome. Claiming it without a parallel run is an assertion.
A business rule pass documents what each program does. Your team corrects it and signs off. It becomes the test oracle.
DMS applies your configuration. Same input, same output, every run.
Both systems process the same data. Outputs compared in full, field by field.
Any difference is a defect. We correct the rule, not the symptom, then rerun the whole suite.
DMS carries its own regression suite covering dialects, embedded SQL, numeric precision and file handling. Your engagement inherits it on day one.
Gen AI drafts functional test cases from your existing screens and feeds them into automated frameworks, reaching paths a hand-written suite misses.
DMS deploys on your own Windows or Linux servers. Source, generated C#, regression results and documentation never leave.
Translator, dialect rules, regression framework and documentation generator, all open to your security team.
The translated code and every deliverable, outright. No runtime royalties, no lock-in, no ongoing licence.
After training, your engineers can run further translation cycles without involving us.
DMS produced C# directly from the customer's COBOL source. Decimal precision held across an application where the arithmetic is the product.
Send your inventory under NDA. Complexity report, automation estimate and a realistic timeline. No fee, findings are yours either way.
We translate 10,000 lines to C# at no cost. Larger pilots case by case. Pilots run as a scheduled call, not a code upload, so nothing arrives incomplete.
Not a salesperson. The engineers who write the dialect rules. Expect 30 minutes, no slides, your hardest technical question.
We take a limited number of enterprise engagements each year. Holding a slot fixes your pricing and start date without committing you.
General questions
Yes. The same COBOL, run through the same configuration, produces the same C# every time. Translation follows formal rewrite rules over parsed program structure, so there’s no run-to-run variance. Gen AI sits outside that core: it drafts business rule documentation and generates functional tests from legacy screens. It never writes the C# you ship.
.NET 10, the current Long Term Support release, supported by Microsoft through November 2028. That means ASP.NET Core, Entity Framework Core and C# 14. We can target .NET Framework where your environment requires it. Target selection is a configuration setting, so changing it after the assessment doesn’t restart the project.
No. Compiling COBOL to the CLR changes where your code executes, not what language it’s written in. You still need COBOL developers, you still carry compiler licensing, and you still can’t recruit against the codebase. If you’re already on .NET the project is usually simpler, because the data and integration layers have often been sorted out.
Modernize Software uses three complementary mechanisms to ensure functional equivalence between the original COBOL application and the modernized application:
1. Extensive Translator Validation Testing
We maintain thousands of translator validation tests to verify that the modernization process produces accurate and reliable results across a broad range of COBOL language constructs, programming patterns, and application behaviors.
2. Comprehensive Acceptance Testing
The modernized application undergoes functional, regression, performance, and other forms of acceptance testing. Wherever practical, these tests can be automated to efficiently validate the modernized application against expected results. Acceptance testing is a collaborative effort involving the customer, Modernize Software, and, where appropriate, a third-party testing specialist.
3. Parallel Run and Results Comparison
Where appropriate, the modernized application is run in parallel with the original COBOL application using the same inputs and production workloads. Results are compared between the two environments, with discrepancies investigated and resolved. The goal is to continue parallel validation until the results reach the required level of equivalence, including zero unexplained differences for applicable workloads.
Together, these mechanisms provide multiple layers of assurance that the modernized application preserves the functionality and business rules of the original COBOL system.
It doesn’t have to. DMS deploys inside your infrastructure on standard Windows or Linux servers, and our engineers work remotely against your installation. Source, generated C#, regression results and documentation stay inside your environment, and your security team can audit the whole toolchain.
You do, outright, along with the documentation, regression assets and deployment artifacts. No runtime royalties, no platform lock-in, no ongoing licence tied to the generated C#.
They’re the most valuable people on the project. During migration they’re the only source of business knowledge that isn’t written down. After cutover most move onto maintaining the C#, where what they’re learning is syntax and framework patterns rather than a rewritten business. Code training is part of handover.
Yes, and most customers do. We re-run changed programs through the same configuration rather than hand-merging your modifications. We agree a resynchronising cadence and a cut-off shortly before parallel run.
Yes, and on large estates we recommend it. A bounded subsystem migrates first and runs alongside the remaining COBOL through APIs. Customer-facing modules are a common starting point, as is high-cost batch work driving MIPS spend.
As one workstream with the code, because a schema decision changes the code that reads it. We’ve migrated from VSAM, IMS, DB2, Adabas, DataCom and Model 204, onto SQL Server, Azure SQL, PostgreSQL and Oracle. Unload, normalise and load scripts ship as part of the deliverable.
Rough line counts and your target stack are enough to begin. · Austin, Texas · sales@semanticdesigns.com
.png)
info@semanticdesigns.com
