Modernization path

Port a COBOL estate to .NET Core 8 without service interruption.

Q: Should we choose .NET Core over Java for financial COBOL?

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.

Q: Can .NET Core be deployed elsewhere than Azure?

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.

Q: How are COBOL JCLs migrated to .NET?

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.

Q: Can tools like Microsoft Azure Mainframe Migration automate the migration?

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.

Q: How much does a COBOL to .NET Core migration cost?

Three variables set the cost: the number of COBOL lines genuinely in scope, the share of code with no modern equivalent (proprietary runtime calls, CICS transaction boundaries), and whether you keep a vendor runtime or go fully idiomatic .NET. The Intake phase measures all three before any figure is committed. Free initial scoping call, 30 minutes to 2 hours.

Q: How do you handle the COBOL / .NET coexistence during the transition?

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. Coexistence duration is set at scoping based on risk profile and batched cutover cadence — extended dual maintenance must be anticipated in the handover plan. See Legacy to Cloud expertise for detailed patterns.

Migration of COBOL applications running on mainframe or AS/400 to .NET Core 8, under the ATLAS methodology. Proven functional parity, internal classified discrepancy registry.

Key figures

240 B

lines of COBOL still in production worldwide

Reuters / IBM 2022

8:1

rewrite ratio from COBOL to modern .NET Core

By batches

incremental delivery, duration set at scoping

ATLAS methodology applied

From scoping to deployment, five structured phases.

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.

01Phase 1
Scoping
ATLAS steps
E1 Intake · E2 Discovery · E2b Functional spec
Understand the COBOL estate: programs, copybooks, JCL. Rebuild a usable functional analysis. Define scope, constraints, success criteria.
Phase deliverable
Estate inventory + functional spec + pricing
02Phase 2
Capture & dependencies
ATLAS steps
E2e Capture · E3 Dependency mapping
Set the ground truth: recorded transactions, VSAM files, printed reports. Map subsystems, DB2/IMS databases, CICS integrations.
Phase deliverable
Reference transaction bench + complete map
03Phase 3
Target architecture
ATLAS steps
E4 Target architecture · E4b Pre-migration tests
Design the target .NET Core 8 architecture: modular monolith or microservices, SQL Server or Azure SQL, Azure or on-premise hosting. Prepare characterization tests.
Phase deliverable
Signed target architecture + test suite
04Phase 4
Migration & parity
ATLAS steps
E5 Migration · E6 Parity validation
Translate COBOL → C# pattern by pattern: COPY → C# classes, PERFORM → methods, PIC S9(n)V9(n) → decimal. Incremental migration, internal parity audit per batch.
Phase deliverable
.NET code + parity audit per subsystem
05Phase 5
Deployment & handover
ATLAS steps
E7 Delivery
Progressive go-live (strangler fig), mainframe ↔ .NET coexistence with duration set at scoping based on risk profile, batched transactional cutover, ops handover to client team.
Phase deliverable
Application in production + autonomous client team

See the full ATLAS methodology →

At the core of the ATLAS method

AI to understand COBOL, not to translate it.

COBOL-to-C# converters replicate source program structure in static classes and GOTOs emulated by state machines. The result runs on .NET, but usually depends on a vendor runtime recreating COBOL behaviour: the mainframe dependency is swapped for a licence dependency. End-to-end automatic translation isn't a modernization method, it's a debt transfer.

Our approach is the opposite. ATLAS relies on multiple readings of the source code, from several angles. Here, what we read first: jCL-driven batch chains, indexed file access to port to SQL Server or PostgreSQL, and COMP-3 type conversions to decimal. AI comes in as a comprehension accelerator, to decipher years of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate. It informs the architect's work, who then designs the target architecture and drives the migration pattern by pattern, under parity audit.

This understanding still requires humans who know the source technologies. That's our edge: where Europe and North America face a retirement wave on these skills, Tunisia retains experienced COBOL developers, paired with .NET and Azure architects. Together they ensure continuity between the original business intent and the target system.

Who is concerned

Business context and modernization stakes.

When .NET Core makes sense for COBOL

.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).

Sectors concerned

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.

What .NET Core brings versus Java

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.

Source platform

COBOL (IBM z/OS mainframe, AS/400, Unisys)

IBM z/OS↗AS/400↗Unisys↗COBOL↗

Target technology

.NET Core 8, C#, SQL Server or PostgreSQL, Azure

.NET Core 8↗PostgreSQL↗SQL Server↗Azure↗C#↗

Technology alternatives

Compare target trajectories.

.NET Core 8 + C# + SQL Server + Azure

Microsoft ecosystem dominant, Azure as target platform, SQL Server already in production. The default choice for Microsoft-first IT departments.

.NET Core 8 + C# + PostgreSQL + Kubernetes

Technological sovereignty sought, desire to avoid Azure SQL Database, agnostic containerized deployment (Azure, AWS, on-premise). Suited to the European public sector.

Java 21 + Spring Boot

Java ecosystem already dominant in the IT, strong in-house Java skills. See COBOL to Java.

TypeScript + Node.js or Cloudflare Workers

Serverless architecture, moderate volumes, priority on velocity of evolution. See COBOL to TypeScript.

Scoping reference

Typical duration and team for this path.

A COBOL to .NET Core migration is structured as a sequence of functional batches, with the cadence set at scoping based 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, .NET developers ideally with a Java or Pascal background to understand strict typing, QA engineers specialized in characterization tests, a SQL Server or PostgreSQL DBA for the VSAM/DB2 data migration, and a delivery director. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured.

Challenges

Porting business rules to the .NET ecosystem while preserving their exact behavior.
Migrating VSAM or DB2 databases to SQL Server or PostgreSQL without data loss.
Reproducing COBOL arithmetic specifics in .NET (decimal, COMP-3).

ATLAS approach

Intake and mapping of the COBOL estate: programs, COPY, files, CICS transactions.
Automated characterization test suite, comparison legacy / target.
Incremental migration by subsystem with legacy / .NET coexistence during the transition.
Parity audit with discrepancy registry before go-live.

Expected outcomes

Portable .NET Core 8 application, deployable on Azure or on-premise infrastructure.
Reusable regression test suite for future evolutions.
Technical and functional documentation of the migrated code.

Identified pitfalls and ATLAS response

What we learned on this migration path.

Pitfall 01

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.

ATLAS response

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).

Pitfall 02

Translating PIC S9(n)V9(n) COBOL with the double or float type in C#. Financial rounding errors are guaranteed.

ATLAS response

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.

Pitfall 03

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.

ATLAS response

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.

Pitfall 04

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.

ATLAS response

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.

Pitfall 05

Declaring the migration complete before validating complete business workflows in production with real datasets and real users.

ATLAS response

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.

Related expertise

Legacy to Cloud

See modules, services, and use cases.

Proprietary methodology

ATLAS methodology

10 steps, 9 principles, proven parity.

Cell composition

A specialized cell for this modernization path.

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.

Duration

Set at scoping based on volume and criticality

Volume

Determined after the POC and scoping

Profiles

Mainframe ↔ .NET architect

Bridge between z/OS, AS/400 and the Microsoft .NET Core / Azure ecosystem

.NET Tech Lead

.NET Core 8, C#, Entity Framework, COBOL→.NET migration patterns

Developers (.NET)

Ideally with COBOL background for pattern-by-pattern translation

Mainframe → SQL Server DBA

DB2/IMS/VSAM schema migration to SQL Server or Azure SQL

Azure & DevOps engineer

Azure, containers, Azure DevOps CI/CD, Application Insights observability

QA & functional parity

Test bench, legacy/target comparison, ATLAS audit validation

Access field experience

This path in real conditions.

Internal Access POCs — multi-sector

Multiple internal POCs covering representative scopes (banking, insurance, sovereign tax, CRM, billing). COBOL to .NET patterns validated, observed ratio of eight lines of COBOL per one line of .NET, arithmetic parity ensured via decimal mapping.

Multi-sector POCs · Observed ratio 8:1 COBOL→.NET · Arithmetic parity

Frequently asked questions

What decision-makers ask about this path.

Should we choose .NET Core over Java for financial COBOL?+

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.

Can .NET Core be deployed elsewhere than Azure?+

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.

How are COBOL JCLs migrated to .NET?+

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.

Can tools like Microsoft Azure Mainframe Migration automate the migration?+

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.

How much does a COBOL to .NET Core migration cost?+

Three variables set the cost: the number of COBOL lines genuinely in scope, the share of code with no modern equivalent (proprietary runtime calls, CICS transaction boundaries), and whether you keep a vendor runtime or go fully idiomatic .NET. The Intake phase measures all three before any figure is committed. Free initial scoping call, 30 minutes to 2 hours.

How do you handle the COBOL / .NET coexistence during the transition?+

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. Coexistence duration is set at scoping based on risk profile and batched cutover cadence — extended dual maintenance must be anticipated in the handover plan. See Legacy to Cloud expertise for detailed patterns.

Considering a COBOL to .NET Core migration?

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.

COBOL audit (4-6 weeks) →Legacy to Cloud expertise →Build-Operate-Transfer model →

Case studies