Legacy ↔ Python architect
Bridge between COBOL batch/analytical and the Python data ecosystem, COMP-3/PIC pattern mapping, pipeline design
Modernization path
Port a COBOL estate to Python for compute and analytics.
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).
Key figures
~10:1
extrapolated COBOL → Python ratio (Python conciseness + pandas vectorization), to validate on client POC
5-20×
typical performance gain vs naive translation thanks to pandas/NumPy vectorization
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 & perimeter selection
ATLAS stepsE1 Intake · E2 Discovery · E2b Functional specInventory of candidate COBOL programs (analytical batch, actuarial computing, scoring, reporting), exclusion of transactional (targeted to Java/.NET). Python target choice (pandas+PostgreSQL, Databricks/PySpark, FastAPI). Functional spec rebuild of calculation rules.
Phase deliverableInventory + signed perimeter + functional spec + target choice - 02Phase 2
Capture & reference datasets
ATLAS stepsE2e Capture · E3 Dependency mappingCapture of representative production datasets (inputs, expected outputs), freezing the ground truth. Dependency mapping: VSAM/QSAM files, copybooks, JCL scheduling, DB2 integrations.
Phase deliverableFrozen reference datasets + complete dependency map - 03Phase 3
Python target architecture
ATLAS stepsE4 Target architecture · E4b Pre-migration testsPython pipeline design: decimal.Decimal for financial calculations, pandas for transformations, relational (PostgreSQL) or columnar (Parquet/Delta Lake) modeling per volume, Airflow or Databricks Workflows orchestration, observability (logging, metrics). Characterization test suite preparation.
Phase deliverableSigned target architecture + test suite + pipeline mockup - 04Phase 4
Migration & vectorization
ATLAS stepsE5 Migration · E6 Parity validationPattern-by-pattern translation: PIC S9(n)V9(n) → decimal.Decimal, sequential PERFORMs → pandas/NumPy vectorized operations (5-20× gain), CALL → Python modules, VSAM files → tables or DataFrames. COBOL/Python parallel runs for 4-8 weeks on production datasets, automatic line-by-line comparison.
Phase deliverablePython code + parity tests + tracked discrepancy registry - 05Phase 5
Deployment & data integration
ATLAS stepsE7 DeliveryProgressive go-live with COBOL ↔ Python coexistence during transition. Databricks or Jupyter integration for exploration. Packaging (poetry/uv) and containerization (Docker/Kubernetes or serverless Cloud Run). Ops handover to client team with documentation and runbooks.
Phase deliverablePython pipelines in production + integrated data ecosystem + autonomous client team
At the core of the ATLAS method
AI to understand COBOL, not to translate it.
A line-by-line COBOL-to-Python conversion reproduces sequential PERFORM loops where the whole point of the target is vectorization. The result is a Python batch slower than the original mainframe, feeding the opposite conclusion to the one expected: that modernization degrades performance. 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: actuarial and scoring rules to re-express as pandas/NumPy operations, and decimal precision to port to decimal.Decimal rather than float. 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 Python data engineers. Together they ensure continuity between the original business intent and the target system.
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.
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.
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 or COBOL to .NET Core.
Scoping reference
Typical duration and team for this path.
A COBOL to Python migration is structured as a sequence of functional batches, with the cadence set at scoping based on volume and calculation complexity. Typical cell: a legacy-Python architect, a Python tech lead, Python developers (ideally with scientific or data engineering background), a QA engineer specialized in characterization tests, a business referent (actuary, data analyst, tax expert). Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured.
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, internal classified 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.
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 calculation complexity
Volume
Determined after the POC and scoping
Profiles
Python Tech Lead
Python 3, pandas, NumPy, decimal.Decimal, COBOL→Python translation patterns, line-by-line traceability
Python data developers
Ideally with scientific or data engineering background (NumPy, SciPy, vectorization, advanced pandas)
Business referent
Actuary, data analyst, tax expert — resolves accumulated calculation rule ambiguities, validates parity gaps
DBA & data migration
Migration of VSAM/QSAM files to PostgreSQL or columnar storage (Parquet, Delta Lake), data parity audit
QA & functional parity
Characterization test bench, line-by-line legacy/target comparison on production datasets, classified discrepancy registry
Access field experience
This path in real conditions.
Access capability — COBOL to modern stacks
Proven capability on COBOL migration with 10 internal POCs covering Java and TypeScript targets (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.
10 COBOL POCs · 39 patterns · 44 discrepancies · 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?+
Cost depends mostly on the nature of the processing. Three variables matter: the volume of computation code actually ported once dead code is excluded, the decimal precision required (an actuarial engine demands far heavier parity auditing than reporting), and the degree of vectorization targeted on pandas/NumPy. We quote after the ATLAS Intake, which produces the program inventory. Free initial scoping call, 30 minutes to 2 hours.
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.
Considering a COBOL to Python migration?
Three concrete ways to start — from a POC on your code to a full program. Python is perfectly suited to analytical batches and scientific calculations; we explicitly exclude critical transactional workloads (targeted to Java/.NET).
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 / C# Migration
Read the path →
Path
Delphi to TypeScript modernization
Read the path →
Path
Delphi to Java Migration & Modernization
Read the path →