How long it takes to migrate an AS/400: real timelines in 2026

The most honest answer to the question “how long it takes to migrate an AS/400” is: 6-18 months in most cases, with peaks of 24-36 months for complex scenarios. The range is wide because migration strategies have very different timelines (4-6 months for replatforming, 18-36 for replacement), and each strategy has typical modifiers that can double the timeline. Let’s see how to estimate your specific case.

Answer in 3 lines

• Replatforming (lift-and-shift to cloud, RPG code unchanged): 4-6 months typical.
• Gradual refactoring (strangler fig, module-by-module rewrite): 12-24 months, with the legacy system active throughout.
• Replacement (replacement with standard ERP): 18-36 months including data migration and user training.

Which factors really shift the timeline

Five factors in order of impact.

1. Number of active RPG/COBOL programs

Above 1,500 active programs timelines double compared to the baseline of 800-1,500 programs. The reason is simple: the time for assessment, dependency mapping, decision on what to migrate/discard grows non-linearly with code size. Below 500 programs, on the other hand, migration is significantly faster.

2. Number of external integrations

Each active external integration typically adds 4-8 weeks to the total project. Integrations with systems that have modern REST APIs are faster; integrations with old SOAP APIs, FTP, file drops or shared databases slow things down. An AS/400 with 12 external integrations brings 3-6 months of integration work alone.

3. Volume and quality of historical data

Below 10 million records data migration is fast (4-8 weeks). Between 10 and 50 million is the average case (8-16 weeks). Above 50 million you enter “industrial” dimensions that require dedicated batch planning, multi-weekend cut-over windows, possible incremental migrations (6-12 months on the data tier alone).

4. Availability of key internal staff

Projects where there’s an internal technical point of contact (1-2 people who know the legacy well and are dedicated to the project for half their time) proceed 30-50% faster. Those where internal staff is fragmented or saturated by other activities go slowly due to difficult access to key information.

5. Required operational continuity

If the business allows a downtime of 1 long weekend (mid-August, Christmas) for cut-over, direct replacement is fast. If the business allows no downtime (24/7, healthcare, continuous distribution), a compatibility layer must be built for parallel running: typically adds 2-4 months to the project.

Timelines for each strategy

Replatforming (lift-and-shift): 4-6 months

Moves the existing AS/400 to cloud infrastructure (IBM Power Virtual Server, Skytap, Connectria) without touching RPG code.

Phase 1 (weeks 1-3): Infrastructure assessment, cloud provider selection, network connectivity planning, SLA evaluation.

Phase 2 (weeks 4-10): Cloud environment setup, AS/400 configuration replication, compatibility testing, complete backup.

Phase 3 (weeks 11-16): Dry run migration, final cut-over in agreed downtime window, go-live.

Phase 4 (weeks 17-24): Post-cut-over stabilization, cloud cost optimization, on-premise hardware decommissioning.

Replatforming is the fastest strategy but only covers the infrastructure problem: dependency on RPG programmers and integration limits remain.

Gradual refactoring (strangler fig): 12-24 months

Rewrites software module by module in modern technology while the legacy system continues to run. Strategy with the lowest operational risk.

Phase 1, assessment and foundation (months 1-3):

• Complete legacy codebase audit
• Critical business process mapping
• Target architecture design (microservices, API gateway, transition facade)
• Development environment setup + CI/CD

Phase 2, strangler facade (months 4-5):

• Building the HTTP/REST facade that intercepts requests
• Initial routing: all requests still go to the legacy
• Observability setup (logs, metrics, tracing)

Phase 3, first module migrated (months 6-8):

• Selection of low-risk module (e.g. customer master data)
• Rewrite in modern technology (Java, Node.js, .NET)
• Shadow mode: new module receives requests in parallel to the legacy, outputs compared
• Single module cut-over, legacy fallback for 4-8 weeks

Phase 4, incremental modules (months 9-22):

• Same pattern for each subsequent module
• Typical order: master data → orders → invoicing → warehouse → accounting
• Speed that grows with team experience

Phase 5, legacy decommissioning (months 22-24):

• Last modules and historical data
• AS/400 shutdown, historical data preserved in query-only archive

Replacement (full replacement): 18-36 months

Adopt a standard ERP in place of the AS/400 and migrate data + processes.

Phase 1, vendor selection (months 1-3):

• Vendor evaluation (SAP, Microsoft Dynamics, Odoo, TeamSystem Enterprise, NetSuite)
• Demo and POC with two or three options in parallel
• Commercial negotiation and signing

Phase 2, discovery and blueprint (months 4-6):

• Mapping current processes vs new ERP standard
• Gap definition: what goes into customization, what changes in the business process, what is dropped
• To-be design

Phase 3, configuration and customization (months 7-15):

• Standard ERP module configuration
• Customization of identified gaps
• Development of integrations with external systems
• Historical data migration (subproject in itself)

Phase 4, testing and training (months 16-22):

• UAT (User Acceptance Test) with end users
• Key user training (40-80 hours per power user)
• Multiple dry runs of go-live
• Parallel run stabilization

Phase 5, go-live + hyper-attention (months 22-30):

• Final cut-over
• 3-6 months of post-go-live hyper-attention (bugs, fixes, user fine-tuning)
• Gradual roll-out for sites/divisions if applicable

Phase 6, legacy decommissioning (months 30-36):

• AS/400 shutdown in read-only mode for 12-24 months (historical data consultation)
• Total shutdown with long-term archiving

What always slows projects (more than expected)

Five “stall categories” we see repeating.

1. Reverse-engineering of undocumented code. The average Italian AS/400 has internal documentation stuck in the 2000s, comments in dialect, authors retired. The time to understand what the code actually does is always 2-3x what was estimated upfront. Mitigation: serious assessment in phase 1, AI as a copilot for RPG analysis.

2. Data quality issues that emerge only after migration tests. 30-40% of projects discover during migration tests that historical data has unknown problems: duplicates, mixed encodings, broken cross-references. Data cleansing typically adds 8-16 unplanned weeks. Mitigation: pilot sample of migrated data in the first 4-6 weeks of the project.

3. Stakeholder approval delays. Scope decisions requiring board or executive sponsor wait for monthly meetings. Each important decision can add 2-4 weeks if governance is not lean. Mitigation: weekly steering committee dedicated to the project, with decision-making authority.

4. Integration with downstream systems. AS/400s that have 8-15 active external integrations discover during testing that some “minor” integrations are actually critical for processes no one remembered. Mitigation: complete integration map documented in phase 1, audit of all overnight batch interactions.

5. Resistance from end users. Users who have been using the AS/400 for 20-30 years have muscle memory of key sequences, screens, shortcuts. New interface = initial rejection, even if objectively more ergonomic. Without a serious change management plan you risk operational boycott that blocks the go-live. Mitigation: early training, champion users involved from month 4-6, not just from month 18.

How to make a realistic estimate for your case

Four questions to estimate non-fantastically:

1. How many active RPG/COBOL programs do you have? (Not how many you have total, but how many actually executed in the last 12 months. Typically it’s 50-70% of the total, the others are “abandoned but not removed”).

2. How many active external integrations? (Systems that exchange data with your AS/400, in batch or real-time).

3. What is the availability of internal staff? (Are the 1-2 people who really know the legacy partially dedicated to the project?).

4. What is the required operational continuity? (Can the system be stopped for one or more weekends, or never?).

With these 4 pieces of information, an initial estimate with confidence band ±25% is feasible. Estimates below ±25% require a formal assessment of 3-6 weeks on the code and data.

Example: AS/400 with 1,200 active RPG programs, 8 integrations, 1 internal person dedicated at 50%, downtime window only mid-August.

• Replatforming: 5-6 months
• Strangler refactoring: 18-22 months (limited downtime forces strangler)
• Replacement: 24-28 months

FAQ

Can migration be done in less than 6 months?

Only for pure replatforming and small AS/400s (under 500 programs, few integrations). Refactoring under 12 months is realistic only if the legacy code is already well modularized and the data is clean, a rare situation in 25-40 year old systems.

How long does the parallel running last?

Typically 4-12 weeks for replacement strategies. Shorter for strangler strategies where modules are migrated one at a time with 2-4 week fallback each. Shorter (1-2 weeks) for replatforming where systems don’t differ functionally.

What happens to the data after migration?

Typically the AS/400 stays on in read-only mode for 12-24 months after cut-over, as a source of historical consultation. Then it is shut down and the data is archived in long-term storage (typically with a separate query access system on historical data). Some companies keep the AS/400 in cold storage for 5-10 years for tax and legal compliance reasons.

Do the timelines include organizational change management?

Only partially. Technical timelines include training and roll-out, but deep change management (changes to business processes, resistance management, organizational redesign) is a parallel project that often continues 6-12 months after the technical go-live. Underestimating it is the single most frequent cause of “technical project OK, but the company doesn’t benefit from it”.

Which phase costs the most in time?

In strangler refactoring: phase 3 (first module migrated) is the most expensive in proportion because it’s where the team learns the specifics of the legacy. Once past it, migration speeds double. In replacement: phases 3-4 (configuration + UAT) are the longest in absolute terms.

Can the timeline be compressed by hiring more consultants?

Only within certain limits. Above a certain threshold (typically 8-12 external people on the project), adding consultants slows things down rather than speeding them up due to coordination problems and access to key information (which is concentrated in a few internal people). The curve is not linear.

Conclusion

AS/400 migration timelines in 2026 are predictable within a reasonable confidence band if the initial assessment is serious. They are unpredictable if you start directly from the vendor pitch without assessment. The worst thing you can do is commit to an aggressive timeline without having studied the code: each month that turns out to be “slower than expected” costs much more than one extra month planned upfront.

If you are evaluating an AS/400 migration and want a realistic estimate of the timeline for your specific case, let’s talk. A 3-4 week assessment gives an estimate at ±15% that holds for decade-long projects.

To explore further: the pillar page legacy modernization, the page dedicated to AS/400 cloud migration, and the related article guide to AS/400 migration in 2026 for the complete strategic picture.