Expertise 04

Their legacy modernized. With proven parity and signed discrepancies.

Access International ports legacy applications to the cloud. Our programs rely on the ATLAS methodology: ten steps, nine guiding principles, three legacy families. Every migration ships with a signed discrepancy registry.

Typical engagements

Five structural trajectories, proven patterns.

Each legacy family has its catalog of migration patterns, characterization-test library, and known-discrepancy reference.

COBOL → Java / .NET Core

Source platforms

IBM z/OS mainframe, AS/400, Unisys, open COBOL

ATLAS approach

Pattern-by-pattern translation, pre-migration state capture, upstream characterization test suite, parity audit after porting.

Technology target

Java 21, .NET Core 8, TypeScript, Python

Delphi & 4GL → .NET / TypeScript

Source platforms

Delphi Object Pascal, PowerBuilder, Uniface, client/server

ATLAS approach

Native Windows interface rebuild, embedded database porting, proprietary component rewrite, audited UI parity.

Technology target

.NET Core 8, TypeScript, React, Angular

BizTalk → Azure Logic Apps

Source platforms

BizTalk Server 2010 / 2016 / 2020

ATLAS approach

Mapping of orchestrations, XSLT maps and pipelines, rebuild on Logic Apps, Functions, and Service Bus, interface contracts preserved.

Technology target

Azure Logic Apps, Azure Functions, Service Bus

Mainframe RPG → Cloud-native

Source platforms

IBM Z, AS/400 RPG, CICS

ATLAS approach

Incremental modernization with strangler fig pattern, legacy/target coexistence during transition, batched transactional cutover. See our dedicated AS/400 / IBM i 7.5/7.6 page.

Technology target

Azure, AWS, Kubernetes containers

AS/400 / IBM i approach

Lotus Notes / HCL Domino → estate recovery

Source platforms

IBM Lotus Notes, HCL Domino, iNotes, .nsf databases

ATLAS approach

The .nsf file is encrypted by Domino: outside the server it holds no usable text. Recovery therefore goes through the server itself, which renders the decrypted content to an authenticated user. Extraction of messages, views and attachments, then classification by business topic ahead of decommissioning.

Technology target

Searchable archive, knowledge base, input corpus for document RAG

Lotus estate recovery
Guiding principles

The six principles that neutralize classic traps.

P1

Tests first, migration second

The test suite characterizes the legacy before any target code change.

P2

Iterative with parallel runs

Legacy and target run in parallel during transition, continuous comparison.

P5

Isolated architecture

Migration subsystem by subsystem, no big-bang.

P7

Fidelity audit

Functional fidelity is not a wish, it's a measurable deliverable.

P8

Pre-delivery consistency audit

Before delivery, all discrepancies are traced and decided.

P9

Capture state before migration

We freeze a ground truth of the current system before migrating.

The ten ATLAS steps

An operational sequence, from intake to delivery.

Each step has an identified deliverable, an exit criterion, and a validation gate (kill/go). No step starts until the previous one is validated.

Intake

Scope, constraints, and success-criteria framing.

Discovery

Deep legacy code understanding, mapping of business intent.

Functional specification

Rebuilding a functional analysis from existing code.

Existing-system capture

Setting a ground truth: screens, reports, datasets, transactions.

Dependency mapping

Exhaustive mapping of system interactions, files, databases, interfaces.

Target architecture

Designing the technology target: cloud, target language, patterns.

Pre-migration tests

Characterization test suite before touching target code.

Migration

Pattern-by-pattern code translation, line-by-line traceability.

Validation (parity)

Proof of functional equivalence between legacy and target.

Delivery

Go-live, documentation, ops handover, signed discrepancy registry.

Migration journeys

The detail, technology by technology.

Each migration trajectory has its own dedicated page: specific challenges, ATLAS approach, target technologies and FAQ.

COBOL to Java modernization

COBOL (mainframe IBM z/OS, AS/400, Unisys, GnuCOBOL)Java 21, Spring Boot, PostgreSQL, Kafka

COBOL to .NET Core modernization

COBOL (mainframe IBM z/OS, AS/400, Unisys).NET Core 8, C#, SQL Server ou PostgreSQL, Azure

COBOL to TypeScript modernization

COBOL batch (mainframe, AS/400)TypeScript, Node.js, PostgreSQL, conteneurs

COBOL to Python modernization

COBOL batch (calcul, reporting, analytique, actuariat)Python 3, pandas, NumPy, PostgreSQL ou Databricks

Delphi to .NET / C# Migration

Delphi (Object Pascal, VCL, FireDAC).NET Core 8, C#, WinForms ou Avalonia, SQL Server

Delphi to TypeScript modernization

Delphi (client-serveur, VCL)TypeScript, React ou Angular, Node.js, PostgreSQL

Delphi to Java Migration & Modernization

Delphi (Object Pascal, VCL, FireDAC, dbExpress, composants tiers)Java 21, Spring Boot, JPA, PostgreSQL, REST API, frontend SPA ou JavaFX

PowerBuilder modernization

PowerBuilder (PowerScript, DataWindow, PBL, Appeon PowerServer).NET Core 8 ou Java 21 ou TypeScript, PostgreSQL ou SQL Server, REST API, frontend SPA ou WinForms selon contexte

IBM Z mainframe to Azure modernization

Mainframe IBM z/OS, CICS, DB2, VSAMAzure (AKS, App Service, SQL Database, Service Bus)

Mainframe to AWS modernization

Mainframe IBM z/OS, AS/400, Unisys, OpenVMS — applications COBOL, PL/I, CICS, JCL, batchAWS — EKS / ECS, RDS PostgreSQL ou Aurora, EventBridge, Step Functions, S3, Lambda, AWS Mainframe Modernization (Blu Age, Micro Focus)

AS/400 modernization

AS/400 (IBM i, RPG, DB2/400, CL)Java, .NET Core, TypeScript, PostgreSQL, conteneurs

BizTalk to Azure Logic Apps migration

BizTalk Server 2010 / 2016 / 2020Azure Logic Apps, Azure Functions, Service Bus, API Management

Frequently asked questions

Legacy modernization — what CIOs ask.

How long does a legacy migration take?+

Duration depends on code volume, functional complexity, and the chosen delivery model. ATLAS engagements are scoped at Intake with per-pattern pricing. Migration is segmented by subsystem to maintain service continuity.

How do you prove functional parity between legacy and target?+

We produce a characterization test suite that runs legacy and target on the same datasets. Each gap is documented, weighted, and submitted to the program committee for validation or compensation. The parity report is a contractual deliverable.

What happens with identified discrepancies?+

Every discrepancy is traced in an official registry: cause, business impact, decision. Acceptable discrepancies are documented with justification; blocking ones are fixed or compensated before delivery. The registry is signed with the client.

Can we start with a POC before launching the program?+

Yes, we regularly deliver multi-week migration POCs to validate technology direction, per-pattern productivity, and pricing. The POC reuses exactly the tools, methods, and templates of the full program.

What's real COBOL migration productivity with vibe coding?+

Our teams migrate 500 to 1,500 COBOL lines per person-day depending on pattern complexity, accelerated by Claude Code and Copilot. 2x-3x productivity vs. classical manual methods. A short POC measures real productivity on the client's specific code before committing to the full program.

Strangler fig strategy: how does it work concretely?+

Legacy keeps running while we migrate subsystem by subsystem to the target. Each migrated module goes to production independently, with parallel legacy/target runs and automatic comparison. No big-bang. No service interruption. ATLAS principle P5.

Does the discrepancy registry become the client's property?+

Yes. All ATLAS deliverables (code, tests, documentation, signed discrepancy registry, patterns) are the client's property. No black box. On early exit, the client has all material to continue in-house or with another vendor.

Does Access co-deliver with a prime contractor?+

Frequently. The prime (CGI, Capgemini, Cofomo) carries the client relationship and governance, Access operates the ATLAS cell from Tunis or Paris as subcontractor or partner. Our deliverables and rituals integrate with their methodologies. ATLAS adds parity guarantees and the discrepancy registry.

How is service continuity managed on a critical mainframe migration?+

Legacy/target coexistence with parallel runs. Batched transactional cutover after parity audit. Priority targeting of non-critical transactions first, then critical with automatic fallback. Reversible CI/CD (ATLAS principle P4): any deployment can be rolled back in minutes.

Does Access maintain legacy code during migration?+

Yes if requested. We can maintain the legacy in parallel with the migration program (critical bug fixes, minor evolutions), via TM or SC model. This avoids the client managing two vendors during transition.

Can mainframe be replaced by AI?+

AI does not replace a mainframe — it accelerates the work to modernize off the mainframe. Mainframes (IBM Z, AS/400, Unisys) run business-critical workloads measured in millions of transactions per hour with deterministic latency and decades of accumulated business rules. No AI agent today writes greenfield production code at that scale of complexity unattended. What AI does change: it makes legacy modernization 2x to 3x faster by reading COBOL or RPG, extracting business intent, generating characterization tests, and proposing target patterns under human review. The combination of AI-augmented engineering plus a structured methodology (ATLAS) plus parallel-run validation makes mainframe modernization economically rational where it wasn't five years ago. See the Legacy to Cloud expertise and the ATLAS methodology.

What are the four types of data migration?+

The classical taxonomy lists four migration types, each with different effort and risk profiles. (1) Storage migration — moving data from one storage system to another (SAN to cloud blob, on-premises NAS to S3) without changing format or schema. Lowest risk. (2) Database migration — moving from one database to another (Oracle to PostgreSQL, DB2 to Azure SQL) often with schema transformations. Medium risk, requires careful data type mapping. (3) Application migration — moving an entire application stack (lift-and-shift, replatform, or refactor). Higher risk because business logic moves with the data. (4) Business process migration — re-engineering workflows in addition to moving data and applications, typically during a major modernization. Highest effort, highest payoff. Most enterprise programs combine all four. See the Legacy to Cloud expertise.

Considering a legacy-modernization program?

We audit feasibility, cost, and trajectory. A migration POC can be delivered in a few weeks before committing to the full program.