COBOL powers an estimated hundreds of billions of lines of code still running in global financial systems, government infrastructure, and enterprise backends.
In the UK, many of those systems are running in banks, insurance companies, public sector organisations, and large retailers.
The developers who wrote them are retiring.
The organisations running them are feeling the pressure.
Python has become the migration target of choice for most COBOL modernisation projects, and for good reason.
It is readable, has a vast library ecosystem, is the primary language for AI integration, and can be structured to replicate the procedural logic patterns that COBOL systems rely on.
This guide explains what a COBOL to Python migration actually involves, the different approaches available to UK enterprises, what it costs, and how to manage the risk.
TL;DR Python is the primary COBOL migration target in 2026 because it maps naturally to COBOL's procedural logic and gives the migrated system immediate access to Python's AI and ML ecosystem The three main approaches (automated transpilation, parallel rewrite, and domain-driven reimplementation) have different risk and cost profiles; most UK enterprises use a hybrid of the latter two A mid-size COBOL migration costs £200,000 to £500,000+ and takes one to three years; underestimating scope is the most common failure mode Automated transpilation tools do not produce production-ready code; manual review, testing, and business validation remain essential regardless of tooling Why Python is the Right Target for Most COBOL Migrations Python is not the only language COBOL systems are being migrated to.
Java, C#, Go, and C++ are all valid targets depending on the context.
But Python has become the default for several converging reasons in 2026: Readability over verbosity.
Python's syntax is close to pseudocode.
When a COBOL routine is translated to Python, the business logic remains legible to non-developers.
That matters for regulated industries where audit and review are requirements.
Procedural compatibility.
COBOL is inherently procedural: it processes data step by step, paragraph by paragraph.
Python supports procedural programming naturally, making logic translation more straightforward than migrating to an object-oriented language like Java.
AI integration readiness.
Once migrated to Python, the system gains native access to the full Python ML and AI ecosystem.
For enterprises planning to add AI-powered analytics, anomaly detection, or natural language interfaces on top of migrated systems, Python is the most direct path.
Developer availability.
Python is the most widely taught language in UK universities and bootcamps.
The hire pool for Python developers is larger than for any other backend language, which reduces long-term maintenance risk.
Library ecosystem.
Python's standard library and PyPI ecosystem cover data processing, numerical computation, database access, API integration, and testing comprehensively.
COBOL-era batch processing patterns have direct Python equivalents.
Understanding What You Are Migrating From COBOL systems migrated in the UK enterprise context typically fall into several categories: Batch processing systems.
The most common COBOL pattern: large volumes of records read from files, processed sequentially, and written to output files or databases.
These translate well to Python with libraries like Pandas for data manipulation.
Transaction processing systems.
Online transaction processing systems, often connected to CICS or IMS on IBM mainframes.
These require more careful mapping of transaction boundaries, rollback logic, and connection management.
Report generation systems.
COBOL-generated reports are often migrated to Python-based reporting pipelines that output to modern formats: PDF, Excel, web dashboards.
Interface layers.
COBOL programs acting as middleware between older systems and databases.
These often become Python microservices in the modernised architecture.
The character of the migration changes significantly depending on which type of system you are moving.
Batch processing migrations are typically the most straightforward; transaction processing systems carry the most risk.
Migration Approaches There are three main approaches to COBOL to Python migration, each with different risk and cost profiles:
1.
Automated Conversion Tools exist that parse COBOL code and generate equivalent Python.
The output is functional but typically unreadable: it mirrors the COBOL structure rather than producing idiomatic Python.
The result is Python that behaves like COBOL but looks nothing like how a Python developer would write it.
Best for: Large codebases where the primary goal is eliminating COBOL dependency quickly, followed by incremental refactoring.
Risk: The generated code is hard to maintain and often contains COBOL-specific patterns that do not translate well to Python idioms or modern tooling.
2.
Parallel Rewrite The Python system is built alongside the existing COBOL system.
Both run in parallel, processing the same inputs and producing outputs that are validated against each other.
The COBOL system is decommissioned once the Python system passes validation.
Best for: Mission-critical systems where continuity cannot be risked.
Financial transaction processing, payroll, benefits administration.
Risk: Running two systems in parallel doubles operational cost during the migration period and requires disciplined reconciliation processes.
3.
Incremental Migration (Strangler Fig) Individual COBOL programs or modules are replaced with Python equivalents one at a time.
The new Python modules are integrated into the existing system, which gradually becomes a hybrid and then eventually a pure Python system.
Best for: Large monolithic COBOL systems where a full rewrite is impractical.
Allows the team to learn and iterate while keeping the business running.
Risk: The hybrid state can persist longer than planned if business priorities shift.
Requires careful interface design between the COBOL and Python components.
For most UK enterprise migrations, the strangler fig approach combined with selective automated conversion (for boilerplate-heavy sections) delivers the best balance of risk and velocity.
COBOL to Python Migration Costs in the UK Cost varies enormously based on codebase size, complexity, and the approach taken.
Indicative ranges for UK enterprise projects: System Size Approach Estimated Cost Small (< 50,000 lines) Parallel rewrite £80,000 to £200,000 Medium (50,000 to 500,000 lines) Strangler fig £200,000 to £800,000 Large (500,000+ lines) Automated + incremental refactor £500,000 to £2,000,000+ Legacy mainframe decommission Full programme £1,000,000 to £10,000,000+ These figures include analysis, migration, testing, and go-live support.
They do not include ongoing operational costs, training, or downstream integration work that often surfaces during migration.
The Mecanik COBOL to Python migration service specialises in UK enterprise migrations, covering analysis, conversion, testing, and go-live support.
For organisations evaluating multiple target languages, the COBOL migration overview sets out the full range of options including C#, Java, Go, and Rust.
For mainframe-level 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 Python migrations fail or overrun for predictable reasons: Undocumented business logic.
COBOL systems often contain 30 to 40 years of accumulated business rules embedded directly in the code, with no external documentation.
Discovery and documentation of this logic is the most time-consuming and risk-intensive part of any migration.
Data format dependencies.
COBOL systems use packed decimal (COMP-3), EBCDIC encoding, and fixed-width file formats that have no direct Python equivalent.
The