Loading...
Loading...
Most legacy modernization programs drift for organizational reasons, not technical ones. ATLAS structures these programs into ten documented steps, with kill/go gates between each phase. The result: programs that land on budget, on date, and on scope.
Three structural anti-patterns recur in programs that fail to hold their commitments.
The first is refactoring during migration. Restructuring code at the same time as migrating it makes every regression indistinguishable: migration drift or redesign drift? Resolution times multiply by three, four, sometimes ten.
The second is insufficient test coverage before migration. Without a behavior reference, functional parity is no longer measurable. Validation becomes an opinion, not a deliverable.
The third is lack of discrepancy traceability. Spot deviations are documented "later", then surface in production, at the most expensive and least acceptable moment.
ATLAS neutralizes these three traps by design.
ATLAS is our operational framework for legacy application modernization (COBOL, Delphi, PowerBuilder, BizTalk), built and industrialized within Access International (group founded in 1999, 27 years of existence). It is structured into ten sequential steps, each with an identified deliverable, an exit criterion, and a validation gate (kill/go).
E1 Intake: scope and success criteria. E2 Discovery: deep understanding of the legacy code. E2b Functional specification: rebuilding a readable analysis. E2e Existing-system capture: setting a ground truth. E3 Dependency mapping. E4 Target architecture. E4b Pre-migration tests: writing the characterization test suite. E5 Migration: pattern-by-pattern translation. E6 Parity validation. E7 Delivery with internal classified discrepancy registry.
No step starts until the previous one is validated. The nine guiding principles (tests first, parallel runs, strangler fig, fidelity audit, etc.) permeate every decision.
If a single step were to summarize ATLAS, it would be E2e. This is the moment when we freeze a ground truth of the current system before any change.
Concretely: produced screens are captured in high fidelity, reports are exported as datasets, critical transactions are replayed and recorded with their effects. This base becomes the characterization test suite that will, at the end of the migration, formally prove functional parity.
Teams that skip this step find themselves at final validation having to prove something they can no longer measure — the expected behavior was never set. ATLAS makes this capture mandatory, documented, and internally classified before opening E3.
On a multi-year IT modernization program for a North American public sector organization, Access operated a multi-stream service center from Tunisia, in subcontracting for a local prime contractor, covering normal North American business hours. Several streams covered: systems development, Java and .NET programming, project management, organic architecture.
Agile methodology imposed by the end-client: daily stand-ups, weekly progress reports, steering committees. Access resources embedded in the prime's and client's teams, under the prime's governance, with B3 personnel security clearance obtained for the profiles mobilized.
Outcome: program renewed during execution, additional mandate obtained (migration of enterprise file repositories to Microsoft SharePoint 365). Access's ability to run a nearshore service center for a North American public sector organization under strict governance constraints is confirmed by the duration of the partnership and the renewals secured.
ATLAS is not a public methodology that Access International would follow like others. It is a framework we built, industrialized, and refined within the Access group (27 years of existence since 1999). It includes our libraries of migration patterns by family (COBOL, Delphi, BizTalk), our catalogs of recurring discrepancies, our characterization test templates, and our proven governance rituals.
Each client signs an ATLAS program in the sense that they buy both the human cell, the method, and the methodological heritage that comes with it. This authorizes them to continue evolutions in-house after delivery, equipped with the same rigor as us. See the four delivery models to understand how ATLAS is operationalized in time and materials, fixed price, or service center.
Duration depends on code volume, functional complexity, and delivery model. A short 2-to-6-week POC measures real productivity before committing to the full program. Typical multi-year mainframe COBOL programs last 24 to 48 months, broken into incrementally delivered subsystems.
Yes, frequently. The prime (CGI, Capgemini, Cofomo) holds the client relationship and governance. Access operates the ATLAS cell in subcontracting or partnership. Our deliverables, rituals, and tooling integrate with the prime's methodology, to which ATLAS adds parity guarantees and the discrepancy registry.
Yes, this is even recommended via the strangler fig strategy (principle P5). The legacy continues to run while we migrate subsystem by subsystem. Each migrated module enters production independently with parallel legacy/target runs. No client is forced into a big-bang.
Every ATLAS program is delivered with comprehensive documentation, internal classified discrepancy registry, and transferred automated test suite. Migrated patterns and tools are the client's property. In case of exit, the client has sufficient material to continue in-house or with another provider.
We frame every program at Intake, with transparent budgeting. A short POC of a few weeks can be delivered before committing to the full program.
Engage an ATLAS POC →