Mainframe ↔ .NET architect
1Bridge between z/OS, AS/400 and the Microsoft .NET Core / Azure ecosystem
Loading...
Loading...
Migration of COBOL applications running on mainframe or AS/400 to .NET Core 8, under the ATLAS methodology. Proven functional parity, signed discrepancy registry.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Understand the COBOL estate: programs, copybooks, JCL. Rebuild a usable functional analysis. Define scope, constraints, success criteria.
Set the ground truth: recorded transactions, VSAM files, printed reports. Map subsystems, DB2/IMS databases, CICS integrations.
Design the target .NET Core 8 architecture: modular monolith or microservices, SQL Server or Azure SQL, Azure or on-premise hosting. Prepare characterization tests.
Translate COBOL → C# pattern by pattern: COPY → C# classes, PERFORM → methods, PIC S9(n)V9(n) → decimal. Incremental migration, signed parity audit per batch.
Progressive go-live (strangler fig), mainframe ↔ .NET coexistence for 6 to 24 months, batched transactional cutover, ops handover to client team.
.NET Core as a COBOL migration target makes sense in three typical situations. When your IT relies on the Microsoft ecosystem — Azure, Dynamics 365, Power Platform, SQL Server dominant. When your in-house teams know C# better than Java, or when your usual integrators are Microsoft-oriented. When you aim to consolidate workloads on Azure with Microsoft managed services (Azure SQL Database, Azure App Service, Azure Functions, Azure Container Apps).
COBOL estates that are candidates for a .NET migration are found in regional banks and mutualist funds tied to Microsoft, central and local administrations standardized on the Microsoft ecosystem, insurers equipped with Dynamics 365, and industrial and retail players using SQL Server as a reference. For these organizations, migrating to Java would force an unwanted ecosystem change — .NET is the natural continuity.
Technically, .NET Core 8 is now on par with Java 21 on performance, maturity, and tooling availability. The decisive advantage of .NET over Java in a COBOL migration: the native decimal type in C# perfectly maps to PIC S9(n)V9(n) and COMP-3 in COBOL, without requiring a third-party library like BigDecimal in Java. This proximity simplifies arithmetic mapping, which often represents 40 percent of calculations in a financial COBOL estate. See COBOL to Java for the detailed comparison.
.NET Core 8, C#, SQL Server ou PostgreSQL, Azure
Microsoft ecosystem dominant, Azure as target platform, SQL Server already in production. The default choice for Microsoft-first IT departments.
Technological sovereignty sought, desire to avoid Azure SQL Database, agnostic containerized deployment (Azure, AWS, on-premise). Suited to the European public sector.
Java ecosystem already dominant in the IT, strong in-house Java skills. See [COBOL to Java](/parcours/cobol-to-java).
Serverless architecture, moderate volumes, priority on velocity of evolution. See [COBOL to TypeScript](/parcours/cobol-to-typescript).
A COBOL to .NET Core migration is typically planned over **twelve to thirty months** depending on volume and criticality. The typical cell combines a **legacy .NET architect** capable of translating mainframe concepts to the Microsoft ecosystem, a senior **C# tech lead**, three to six **.NET developers** ideally with a Java or Pascal background to understand strict typing, one to two **QA engineers** specialized in characterization tests, a **SQL Server or PostgreSQL DBA** for the VSAM/DB2 data migration, and a delivery director. For twenty to one hundred thousand lines of COBOL, plan **six to twelve months** with a cell of five to eight people.
Underestimating the migration of VSAM and DB2 databases to SQL Server or PostgreSQL. Bidirectional cursors, optimistic locks, and VSAM positioned access have no direct equivalent in relational SQL.
Exhaustive mapping of data accesses from Intake. VSAM positioned access becomes indexed queries with explicit ORDER BY, cursors are replaced by iterations with pagination, optimistic locks are ported to the .NET RowVersion/Concurrency Token pattern. Parity tests on edge cases (single record, missing record, composite index).
Translating PIC S9(n)V9(n) COBOL with the double or float type in C#. Financial rounding errors are guaranteed.
Systematic mapping of PIC S9(n)V9(n) and COMP-3 to the native decimal type in C# — exact precision up to 28 significant digits, deterministic behavior. No third-party library. Unit tests on overflow, underflow, and division with explicit rounding mode.
Reproducing the monolithic COBOL architecture in C# without seizing the opportunity to break into services. The result is a .NET application that inherits the COBOL architectural debt.
Bounded context business decomposition during the target architecture phase. Related COBOL programs are grouped into coherent .NET services, common COPY structures become shared internal NuGet libraries. This structural refactoring is separated from functional parity — a distinct phase after cutover.
Forgetting CICS pseudo-conversational transactions. In COBOL-CICS, every user interaction is a short transaction with state persistent between screens. The naive .NET pattern does not reproduce this semantic.
Migration to ASP.NET Core with distributed Session State (Redis or SQL Server depending on criticality). CICS commareas become serialized DTOs. Conversational flows are rewritten as stateless workflows with state preserved between requests. Load tests to validate performance under volume equivalent to the legacy.
Declaring the migration complete before validating complete business workflows in production with real datasets and real users.
Principle E7 — browser and workflow validation mandatory before delivery. See the ATLAS methodology for the complete 10 steps. Parallel runs COBOL/.NET for four to eight weeks before official cutover, with daily reconciliation of discrepancies.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Bridge between z/OS, AS/400 and the Microsoft .NET Core / Azure ecosystem
.NET Core 8, C#, Entity Framework, COBOL→.NET migration patterns
Ideally with COBOL background for pattern-by-pattern translation
DB2/IMS/VSAM schema migration to SQL Server or Azure SQL
Azure, containers, Azure DevOps CI/CD, Application Insights observability
Test bench, legacy/target comparison, ATLAS audit validation
Multi-year program to modernize a COBOL estate on IBM z/OS mainframe with Microsoft Azure as target. Nearshore co-delivery under ATLAS methodology, signed discrepancy registry by program directors.
Ten POCs covering banking, insurance, sovereign tax, CRM, billing. COBOL to .NET patterns validated on representative scopes, ratio of ten lines of COBOL per one line of .NET, arithmetic parity ensured via decimal mapping.
Yes if your IT is Microsoft-first and/or your teams know C#. The native decimal type in C# eases the mapping of PIC S9(n)V9(n) and COMP-3 compared to Java BigDecimal. For classic banking or insurance COBOL, .NET and Java are today equivalent in performance and maturity. The choice is made on the existing ecosystem and in-house skills. See COBOL to Java for the comparison.
Yes. .NET Core 8 is cross-platform and runs on Linux, macOS, Windows, in Docker containers, on Kubernetes (AKS, EKS, GKE, on-premise), and on all clouds. You can therefore migrate COBOL to .NET without locking into Azure if your company's sovereignty or cloud policy requires it. SQL Server is also available on Linux, or replaceable by PostgreSQL with minor adaptations.
JCLs are rewritten as .NET batch with several options depending on context. For simple batches: .NET Console apps orchestrated by a scheduler (Azure Scheduler, Kubernetes CronJobs, Quartz.NET). For complex batches with steps, restart, checkpoint: Spring-like framework such as Quartz or Hangfire. For massively parallel processing: Azure Batch or Durable Functions. JCL parameters become command-line arguments or YAML/JSON configuration.
Partially. Azure Mainframe Migration (and equivalent tools like Micro Focus, Asysco) can convert COBOL to .NET or Java code, but the output is rarely maintainable as-is: verbose generated code, COBOL patterns preserved instead of being idiomatized in .NET, heavy dependencies on a proprietary runtime. These tools accelerate the initial conversion but do not replace the characterization phase or the parity audit. Our ATLAS methodology integrates these tools as accelerators when relevant, without considering them as a turnkey solution.
For a program of fifty thousand lines of COBOL mainframe in nearshore co-delivery, plan eight hundred thousand to one million two hundred thousand euros parity tests and documentation included. For five hundred thousand lines, multi-year budget three to eight million euros. Cost depends on the engagement model — see the delivery models for contractual formats (fixed price, development center, BOT).
Coexistence is structured by gateways. Azure API Management or Azure Service Bus serve as a bridge between the two systems. Critical transactions continue on COBOL until they are migrated, new transactions are implemented directly in .NET, routes are switched flow by flow. The recommended coexistence duration is six to eighteen months maximum — beyond that, dual maintenance becomes expensive. See Legacy to Cloud expertise for detailed patterns.
Three concrete ways to start — from a free diagnosis to a full cell. Our COBOL → .NET Core 8 approach is documented, priced, and applicable from the first meeting.