Loading...
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.
Each legacy family has its catalog of migration patterns, characterization-test library, and known-discrepancy reference.
IBM z/OS mainframe, AS/400, Unisys, open COBOL
Pattern-by-pattern translation, pre-migration state capture, upstream characterization test suite, parity audit after porting.
Java 21, .NET Core 8, TypeScript, Python
Delphi Object Pascal, PowerBuilder, Uniface, client/server
Native Windows interface rebuild, embedded database porting, proprietary component rewrite, audited UI parity.
.NET Core 8, TypeScript, React, Angular
BizTalk Server 2010 / 2016 / 2020
Mapping of orchestrations, XSLT maps and pipelines, rebuild on Logic Apps, Functions, and Service Bus, interface contracts preserved.
Azure Logic Apps, Azure Functions, Service Bus
IBM Z, AS/400 RPG, CICS
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.
Azure, AWS, Kubernetes containers
The test suite characterizes the legacy before any target code change.
Legacy and target run in parallel during transition, continuous comparison.
Migration subsystem by subsystem, no big-bang.
Functional fidelity is not a wish, it's a measurable deliverable.
Before delivery, all discrepancies are traced and decided.
We freeze a ground truth of the current system before migrating.
Each step has an identified deliverable, an exit criterion, and a validation gate (kill/go). No step starts until the previous one is validated.
Scope, constraints, and success-criteria framing.
Deep legacy code understanding, mapping of business intent.
Rebuilding a functional analysis from existing code.
Setting a ground truth: screens, reports, datasets, transactions.
Exhaustive mapping of system interactions, files, databases, interfaces.
Designing the technology target: cloud, target language, patterns.
Characterization test suite before touching target code.
Pattern-by-pattern code translation, line-by-line traceability.
Proof of functional equivalence between legacy and target.
Go-live, documentation, ops handover, signed discrepancy registry.
Each migration trajectory has its own dedicated page: specific challenges, ATLAS approach, target technologies and FAQ.
COBOL (mainframe IBM z/OS, AS/400, Unisys, GnuCOBOL) → Java 21, Spring Boot, PostgreSQL, Kafka
COBOL (mainframe IBM z/OS, AS/400, Unisys) → .NET Core 8, C#, SQL Server ou PostgreSQL, Azure
COBOL batch (mainframe, AS/400) → TypeScript, Node.js, PostgreSQL, conteneurs
COBOL batch (calcul, reporting, analytique, actuariat) → Python 3, pandas, NumPy, PostgreSQL ou Databricks
Delphi (Object Pascal, VCL, FireDAC) → .NET Core 8, C#, WinForms ou Avalonia, SQL Server
Delphi (client-serveur, VCL) → TypeScript, React ou Angular, Node.js, PostgreSQL
Delphi (Object Pascal, VCL, FireDAC, dbExpress, composants tiers) → Java 21, Spring Boot, JPA, PostgreSQL, REST API, frontend SPA ou JavaFX
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
Mainframe IBM z/OS, CICS, DB2, VSAM → Azure (AKS, App Service, SQL Database, Service Bus)
Mainframe IBM z/OS, AS/400, Unisys, OpenVMS — applications COBOL, PL/I, CICS, JCL, batch → AWS — EKS / ECS, RDS PostgreSQL ou Aurora, EventBridge, Step Functions, S3, Lambda, AWS Mainframe Modernization (Blu Age, Micro Focus)
AS/400 (IBM i, RPG, DB2/400, CL) → Java, .NET Core, TypeScript, PostgreSQL, conteneurs
BizTalk Server 2010 / 2016 / 2020 → Azure Logic Apps, Azure Functions, Service Bus, API Management
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
We audit feasibility, cost, and trajectory. A migration POC can be delivered in a few weeks before committing to the full program.