COBOL to C# Migration - A UK Enterprise Guide 2026

COBOL still underpins a vast amount of the software running in UK banks, insurers, public sector bodies, and large retailers. Much of it processes money, and much of it has been running since long before the developers maintaining it today joined the organisation. As COBOL expertise retires out of the workforce, the pressure to modernise grows every year, and a COBOL to C# migration is one of the routes UK organisations most often consider.

For organisations already invested in the Microsoft stack, C# on .NET is one of the strongest migration targets available. It is a modern, statically typed, object-oriented language, it runs cross-platform on .NET 8 and later, and it has one feature that makes it particularly well suited to COBOL: a native decimal type built for exact financial arithmetic.

This guide explains what a COBOL to C# migration actually involves, the approaches available to UK enterprises, what it costs, and how to manage the risk.

TL;DR

• C# is the best-fit COBOL migration target for organisations already on .NET or Azure, and its native 128-bit decimal type maps directly to COBOL packed-decimal fields without third-party libraries
• The three main approaches (automated conversion, parallel rewrite, and incremental “strangler fig” migration) carry different risk and cost profiles; most UK enterprises use a hybrid
• A mid-size migration typically costs £200,000 to £800,000 and takes one to two years; underestimating scope is the most common failure mode
• Automated conversion tools produce structurally correct C# but not a finished system; the data access layer, testing, and business validation remain manual work regardless of tooling

Why C# Is a Strong Target for COBOL Migration

C# is not the only sensible destination for COBOL. Python, Java, Go, C++, and Rust are all valid depending on context. C# stands out for specific reasons:

Native decimal precision. This is the single strongest technical argument for C#. COBOL financial fields use packed decimal (COMP-3) and PIC 9 numeric clauses that represent exact base-10 values. C#’s built-in decimal type is a 128-bit fixed-precision, base-10 type designed specifically for financial and monetary calculations. COBOL decimal fields map directly onto it, preserving exact arithmetic with no rounding surprises and no external library. Java can achieve the same correctness with BigDecimal, but only through a more verbose object API; languages that lean on binary floating point (double in Java, float64 in Go, f64 in Rust) are a poor fit for money without extra work.

The .NET ecosystem. Many UK enterprises already run Windows Server, SQL Server, Active Directory, and Azure. For these organisations, migrating COBOL to C# keeps the modernised system inside a stack their teams already operate, monitor, and secure. Data access maps cleanly to ADO.NET, Entity Framework Core, or Dapper.

Cross-platform, modern runtime. Modern .NET is not Windows-only. C# 12 code compiles and runs on .NET 8 or later (a Long Term Support release) across Windows, Linux, and macOS, and deploys naturally as a container on Azure, AWS, or GCP. Migrating to C# no longer locks you into a single operating system.

Static typing and tooling. C#’s strong static typing catches whole categories of error at compile time, which matters when translating decades-old business logic. Visual Studio, Rider, and the .NET CLI provide mature debugging, profiling, and refactoring support.

Developer availability. C# is consistently among the most widely used enterprise languages in the UK, so the long-term hiring and maintenance pool is deep.

Understanding What You Are Migrating From

COBOL systems in the UK enterprise context usually fall into a few categories, and the character of the migration changes with each:

Batch processing systems. The classic COBOL workload: large volumes of records read from files, processed sequentially, and written back out. These are typically the most straightforward to migrate and map well to C# background services and streaming I/O.

Transaction processing systems. Online transaction processing, often driven by CICS or IMS on IBM mainframes. These carry the most risk because transaction boundaries, rollback behaviour, and connection management all need careful mapping onto .NET equivalents.

Report generation systems. COBOL reporting is commonly migrated to C# pipelines that output modern formats: PDF, Excel, or web dashboards.

Interface and middleware layers. COBOL programs sitting between older systems and databases often become C# services in the modernised architecture.

The COBOL Constructs That Need Real Translation

A safe migration depends on translating COBOL semantics, not doing line-by-line text substitution. The constructs that need genuine mapping include:

• PERFORM ranges become C# method calls, with paragraphs and sections decomposed into methods.
• EVALUATE / WHEN maps to C# switch statements or pattern matching.
• 88-level condition names become boolean properties or helper methods.
• MOVE CORRESPONDING, REDEFINES, and OCCURS require careful mapping to typed fields, unions of intent, and arrays or collections.
• PIC clauses map to the appropriate C# type: string for alphanumeric, short / int / long for sized integers, and decimal for packed-decimal fields with preserved precision.
• COPY and REPLACE directives (copybooks) must be resolved before or during parsing, including nested copybooks.
• EXEC SQL (DB2), EXEC CICS, and VSAM file access have no drop-in C# equivalent and are the parts most likely to need deliberate redesign onto ADO.NET / Entity Framework Core and modern service patterns.
• EBCDIC encoding and fixed-width record layouts need explicit conversion to Unicode and typed models.

Migration Approaches

There are three main approaches, each with a different risk and cost profile.

1. Automated Conversion

Tooling parses COBOL and generates equivalent C#. Done well, the output is structurally correct C# 12 with namespaces, classes, and correct decimal mapping. Done naively, it produces a single class stuffed with static methods that is harder to maintain than the original COBOL.

Best for: Large codebases where the priority is eliminating COBOL dependency quickly, followed by incremental refactoring.

Risk: No tool produces a finished, production-ready system. Embedded SQL, CICS interactions, and dynamic calls still need human decisions.

The Mecanik COBOL to C# migration tool illustrates what good automated conversion looks like. It runs a full compiler pipeline (lexer, parser, semantic analyser, code generator) rather than text substitution, decomposes COBOL sections and paragraphs into C# methods, maps COMP-3 fields to native decimal, resolves COPY / REPLACE directives including nested copybooks, and produces a Migration Report that flags every EXEC SQL, EXEC CICS, and dynamic CALL that needs manual attention. It also handles the practical details, such as prefixing identifiers that collide with C# reserved words and converting ACCOUNT-RECORD style names to PascalCase.

2. Parallel Rewrite

The C# system is built alongside the existing COBOL system. Both run against the same inputs, and outputs are validated against each other until the C# system passes, at which point COBOL is decommissioned.

Best for: Mission-critical systems where continuity cannot be risked, such as payments, payroll, and benefits.

Risk: Running two systems in parallel doubles operational cost during the migration and demands disciplined reconciliation.

3. Incremental Migration (Strangler Fig)

Individual COBOL programs are replaced with C# equivalents one at a time. The system becomes a hybrid and then, eventually, pure C#.

Best for: Large monolithic COBOL systems where a full rewrite is impractical. It lets the team learn and iterate while keeping the business running.

Risk: The hybrid state can persist longer than planned, and it demands careful interface design between the COBOL and C# components.

For most UK enterprise migrations, the strangler fig approach combined with selective automated conversion for boilerplate-heavy sections gives the best balance of risk and velocity.

COBOL to C# Migration Costs in the UK

Cost depends heavily on codebase size, complexity, and approach. Indicative ranges for UK enterprise projects:

These figures cover analysis, migration, testing, and go-live support. They exclude ongoing operational costs, training, and downstream integration work that often surfaces mid-project.

The Mecanik COBOL to C# migration service specialises in UK enterprise migrations, covering assessment, conversion, Entity Framework data access layer implementation, and output parity testing. For organisations weighing multiple target languages, the COBOL migration overview sets out the full range of options including Python, Java, Go, C++, and Rust, and the COBOL to Python migration guide covers the most popular alternative target in the same depth as this one.

For migrations where the COBOL is running on IBM z/OS or similar infrastructure, the Mecanik legacy mainframe migration service covers the infrastructure decommission alongside the code migration.

Key Risks and How to Manage Them

COBOL to C# migrations overrun or fail for predictable reasons:

Undocumented business logic. COBOL systems often carry 30 to 40 years of business rules embedded in the code with no external documentation. Discovering and documenting that logic is the most time-consuming and risk-intensive part of any migration.

Data format dependencies. Packed decimal (COMP-3), EBCDIC encoding, and fixed-width layouts have no automatic C# equivalent. C#’s decimal type solves the arithmetic side cleanly, but every field still needs to be mapped and tested with real data before cutover.

The data access layer. Converting COBOL logic is often easier than replacing its data access. EXEC SQL against DB2 and VSAM file handling must be redesigned onto ADO.NET, Entity Framework Core, or Dapper, and this is frequently the largest single work item.

Performance expectations. A COBOL batch job that clears 10 million records overnight sets a bar a naive C# rewrite may not meet. Profiling, optimisation, and sometimes architectural change are required.

Regression testing coverage. The only reliable way to prove the C# output matches the COBOL is comprehensive regression testing with real (anonymised where required) data. Building that test suite before migration begins is not optional.

Cut-over risk. Switching to C# in production is the highest-risk moment. A detailed cut-over plan with rollback procedures and reconciliation checks is mandatory.

Key Takeaways

• C# is the strongest COBOL migration target for organisations on the .NET or Azure stack, largely because its native 128-bit decimal type maps directly to COBOL packed-decimal fields with exact precision and no external library.
• The three main approaches are automated conversion, parallel rewrite, and incremental migration; most UK enterprise projects use the strangler fig approach with selective automation.
• Costs range from around £80,000 for small systems to multi-million-pound programmes for full mainframe decommissions.
• The biggest risks are undocumented business logic, data format dependencies, and the data access layer redesign. Addressing all three before migration begins is essential.

Frequently Asked Questions (FAQ)

Why migrate from COBOL to C# rather than Java or Python? Choose C# when your organisation runs on the .NET ecosystem or Windows and Azure infrastructure. Its native decimal type is a particularly strong fit for COBOL’s financial fields. Java is the natural choice for teams on the JVM, and Python suits organisations prioritising readability and AI integration.

What makes C#’s decimal type better for COBOL migration? C# decimal is a 128-bit, base-10, fixed-precision type built for financial calculations, so COBOL COMP-3 and PIC 9 decimal fields map directly onto it with exact arithmetic and no third-party library. Languages that use binary floating point for numbers need extra work to match COBOL’s decimal behaviour.

Does migrated C# code run on Linux, or only Windows? It runs on both. C# 12 targets .NET 8 or later, which is cross-platform across Windows, Linux, and macOS, and deploys as a standard application or container on Azure, AWS, or GCP.

Can COBOL logic be automatically converted to C#? Yes, with tooling. A good converter produces structurally correct C# with proper class structure and decimal mapping, but it flags embedded SQL, CICS interactions, and dynamic calls for manual work rather than guessing. The data access layer and business validation remain human tasks.

What happens to COBOL data formats like COMP-3 and EBCDIC? COMP-3 fields map cleanly to C# decimal. EBCDIC text and fixed-width layouts require explicit conversion to Unicode and typed models, and every structure should be tested against real data before production use.

How long does a COBOL to C# migration take? Small, well-documented systems take three to nine months. Medium enterprise systems run twelve to twenty-four months. Large mainframe programmes can take three to five years for a full decommission.