Modernization path

Port a COBOL estate to Python for compute and analytics.

Q: Is Python really suited to transactional COBOL?

**No, in most cases**. Python is perfectly suited to **analytical batches** and **scientific calculations**, but not to high-availability transactional (real-time banking, payments, critical transactions). For these perimeters, [Java](/parcours/cobol-to-java) or [.NET Core](/parcours/cobol-to-dotnet-core) remain preferable. Python sweet spot: actuarial, scoring, regulatory reporting, analytical ETL.

Q: How to guarantee arithmetic parity between COBOL and Python?

Three levers. **decimal.Decimal** systematic for all financial calculations (never float). **Explicit precision context and rounding mode** aligned with source COBOL (typically ROUND_HALF_EVEN or ROUND_HALF_UP per business conventions). **Characterization tests** on production datasets with line-by-line comparison, reconciliation of discrepancies classified as CRITICAL / ADAPTATION / COSMETIC per our ATLAS methodology.

Q: How much does a COBOL to Python migration cost?

For **30 to 80 thousand lines of COBOL** compute/analytical in nearshore co-delivery, plan **400 to 800 k€** parity tests and documentation included. Cost typically lower than Java or .NET thanks to Python conciseness (ratio ~10:1) and more compact cell (4 to 6 people). See the [delivery models](/modeles).

Q: How to integrate the migrated Python code with Databricks or Jupyter?

**Databricks**: encapsulate migrated calculations as PySpark notebooks, orchestrate via Databricks Workflows or Airflow. Git versioning, CI/CD via Databricks Repos. **Jupyter**: for ad hoc exploration and interactive documentation of business calculations. **Production**: Python packaging (poetry or uv), execution in Docker containers orchestrated by Kubernetes or serverless (Cloud Run, Lambda). See the [Data engineering pipelines](/parcours/data-engineering-pipeline) path.

Migration of COBOL batch, compute, and analytical workloads to Python, pandas, NumPy, and scientific libraries. ATLAS methodology, proven functional parity, integration with the modern data ecosystem (Databricks, Jupyter).

Who is concerned

Business context and modernization stakes.

When Python makes sense for COBOL

Python as a COBOL migration target is only relevant on specific perimeters. For compute workloads (actuarial, risk scoring, Monte Carlo simulations, statistical analyses), Python brings an unmatched scientific ecosystem (NumPy, SciPy, pandas, scikit-learn). For batch analytical pipelines feeding a data lake or lakehouse, Python integrates naturally with Databricks, Airflow, and Jupyter. For high-availability transactional or critical financial programs, Java or .NET Core remain preferable.

Suitable COBOL perimeters

Good candidates for Python migration: life or P&C insurance analytical batches (provisions, reinsurance), bank credit scoring, administration tax calculations, regulatory reporting (Solvency II, BCBS 239), scientific data processing in industry or healthcare. Typical volume: 20 to 100 thousand lines of COBOL per perimeter. For larger volumes or transactional, see the other paths COBOL to Java, .NET Core, or TypeScript.

Source platform

COBOL batch (calcul, reporting, analytique, actuariat)

COBOL↗

Target technology

Python 3, pandas, NumPy, PostgreSQL ou Databricks

PostgreSQL↗Databricks↗Python 3↗

Technology alternatives

Compare target trajectories.

Python 3 + pandas + PostgreSQL + Airflow

Classic analytical batches, data lake integration, Airflow orchestration. Default choice for analytical pipelines.

Python 3 + Databricks (PySpark + Delta Lake)

Massive volumes (TB), distributed workloads, ML integration. See [Data engineering pipelines](/parcours/data-engineering-pipeline).

Python + FastAPI for APIs

Exposing calculations as REST APIs. Lightweight, fast, easy to industrialize.

Java 21 or .NET Core

High-availability transactional, critical performance, dominant enterprise ecosystem. See [COBOL to Java](/parcours/cobol-to-java) or [COBOL to .NET Core](/parcours/cobol-to-dotnet-core).

Scoping reference

Typical duration and team for this path.

A COBOL to Python migration is typically structured over **six to fifteen months** depending on volume and calculation complexity. Typical cell: a legacy-Python architect, a Python tech lead, two to four Python developers (ideally with scientific or data engineering background), a QA engineer specialized in characterization tests, a business referent (actuary, data analyst, tax expert). For 30 to 80 thousand lines of COBOL, plan **six to ten months** with a cell of four to six people.

Challenges

Faithfully reproducing financial or actuarial calculations in Python (decimal).
Migrating batch reports to observable Python pipelines.
Integrating with modern analytical tools (Databricks, Jupyter).
Vectorizing COBOL loops with pandas and NumPy for performance.

ATLAS approach

Capturing existing calculations and reference datasets.
Characterization tests on representative samples.
Migration with parallel runs and parity audit.
Systematic pandas/NumPy vectorization of sequential loops.

Expected outcomes

Observable Python pipelines, integrated with the modern data ecosystem.
Automated regression tests, signed discrepancy registry.
Performance improved vs COBOL thanks to vectorization.

Identified pitfalls and ATLAS response

What we learned on this migration path.

Pitfall 01

Using the Python float type for financial calculations. Floating-point rounding errors are guaranteed and cent-level discrepancies eventually exceed acceptable thresholds of business controls.

ATLAS response

Systematic mapping of PIC S9(n)V9(n) and COMP-3 to the native decimal.Decimal Python class with explicit context precision and rounding mode. Unit parity tests on overflow, underflow, deterministic rounding division. Automatic comparison of outputs with COBOL reference datasets.

Pitfall 02

Reproducing sequential COBOL loops in Python without using pandas or NumPy. The result is slow Python that doesn't benefit from the language's advantages.

ATLAS response

Systematic vectorization with pandas and NumPy for data transformations. COBOL PERFORMs become vector operations or pandas `apply`. For massive volumes: PySpark on Databricks. Typical performance gain: 5 to 20× vs naive translation.

Pitfall 03

Migrating one program at a time without revising the data model. The COBOL estate typically uses VSAM or QSAM files with positioned access — naively ported to relational SQL, performance is lost.

ATLAS response

Relational modeling adapted to target queries with relevant composite indexes. For massive analytics: columnar storage (Parquet, Delta Lake) instead of classic PostgreSQL. See the Data engineering pipelines path for lakehouse patterns.

Pitfall 04

Declaring the migration complete after calculation conversion, without validating on complete production datasets. Domain edges (overflow, outliers, dates before 1900) reserve surprises.

ATLAS response

Principle E7 — validation on real production datasets mandatory before delivery. Parallel runs COBOL/Python for four to eight weeks on complete production datasets, automatic line-by-line comparison of outputs, registry of classified discrepancies. See the ATLAS methodology.

Related expertise

Legacy to Cloud

See modules, services, and use cases.

Proprietary methodology

ATLAS methodology

10 steps, 9 principles, proven parity.

Access field experience

This path in real conditions.

Access capability — COBOL to modern stacks

Proven capability on COBOL migration with 10 internal POCs (35,524 lines of COBOL converted to Java and TypeScript, 39 COBOL patterns covered, 44 tracked discrepancies). The documented patterns are applicable to a Python target: decimal.Decimal for COMP-3, pandas for vectorization, Airflow or Databricks for orchestration. Capability combinable with our [data engineering expertise](/parcours/data-engineering-pipeline).

10 COBOL POCs · 35,524 lines · 39 patterns · capability applicable to Python target

Frequently asked questions

What decision-makers ask about this path.

Is Python really suited to transactional COBOL?+

No, in most cases. Python is perfectly suited to analytical batches and scientific calculations, but not to high-availability transactional (real-time banking, payments, critical transactions). For these perimeters, Java or .NET Core remain preferable. Python sweet spot: actuarial, scoring, regulatory reporting, analytical ETL.

How to guarantee arithmetic parity between COBOL and Python?+

Three levers. decimal.Decimal systematic for all financial calculations (never float). Explicit precision context and rounding mode aligned with source COBOL (typically ROUND_HALF_EVEN or ROUND_HALF_UP per business conventions). Characterization tests on production datasets with line-by-line comparison, reconciliation of discrepancies classified as CRITICAL / ADAPTATION / COSMETIC per our ATLAS methodology.

How much does a COBOL to Python migration cost?+

For 30 to 80 thousand lines of COBOL compute/analytical in nearshore co-delivery, plan 400 to 800 k€ parity tests and documentation included. Cost typically lower than Java or .NET thanks to Python conciseness (ratio ~10:1) and more compact cell (4 to 6 people). See the delivery models.

How to integrate the migrated Python code with Databricks or Jupyter?+

Databricks: encapsulate migrated calculations as PySpark notebooks, orchestrate via Databricks Workflows or Airflow. Git versioning, CI/CD via Databricks Repos. Jupyter: for ad hoc exploration and interactive documentation of business calculations. Production: Python packaging (poetry or uv), execution in Docker containers orchestrated by Kubernetes or serverless (Cloud Run, Lambda). See the Data engineering pipelines path.

Does this modernization path match your context?

We frame the trajectory, the budget, and the deliverables in a first thirty-minute conversation. A short POC can be proposed before committing to the full program.

Start this path →

Recent insights

POC & retour d'expérience

10 POCs migration legacy : nos learnings

Méthodologie propriétaire

ATLAS : la modernisation legacy prévisible

IA & productivité

Vibe coding : consultants augmentés par IA

Other paths in the same pillar

Continue your exploration.

Path

COBOL to Java modernization

Read the path →

Path

COBOL to .NET Core modernization

Read the path →

Path

COBOL to TypeScript modernization

Read the path →

Path

Delphi to .NET Core modernization

Read the path →

Path

Delphi to TypeScript modernization

Read the path →

Path

Delphi to Java modernization

Read the path →

Business context and modernization stakes.

When Python makes sense for COBOL

Suitable COBOL perimeters

Compare target trajectories.

Python 3 + pandas + PostgreSQL + Airflow

Classic analytical batches, data lake integration, Airflow orchestration. Default choice for analytical pipelines.

Python 3 + Databricks (PySpark + Delta Lake)

Massive volumes (TB), distributed workloads, ML integration. See [Data engineering pipelines](/parcours/data-engineering-pipeline).

Python + FastAPI for APIs

Exposing calculations as REST APIs. Lightweight, fast, easy to industrialize.

Java 21 or .NET Core

High-availability transactional, critical performance, dominant enterprise ecosystem. See [COBOL to Java](/parcours/cobol-to-java) or [COBOL to .NET Core](/parcours/cobol-to-dotnet-core).

What we learned on this migration path.

Pitfall 01

Using the Python float type for financial calculations. Floating-point rounding errors are guaranteed and cent-level discrepancies eventually exceed acceptable thresholds of business controls.

ATLAS response

Pitfall 02

Reproducing sequential COBOL loops in Python without using pandas or NumPy. The result is slow Python that doesn't benefit from the language's advantages.

ATLAS response

Pitfall 03

ATLAS response

Pitfall 04

Declaring the migration complete after calculation conversion, without validating on complete production datasets. Domain edges (overflow, outliers, dates before 1900) reserve surprises.

ATLAS response

What decision-makers ask about this path.

Is Python really suited to transactional COBOL?+

How to guarantee arithmetic parity between COBOL and Python?+

How much does a COBOL to Python migration cost?+

How to integrate the migrated Python code with Databricks or Jupyter?+