AS/400 migration guide for 2026: 5 concrete strategies

The AS/400 (today IBM i) has been running in the information systems of many Italian SMEs for 25 to 40 years. It works. It is stable. It will hold up for another 10 years if needed. So why modernize it? It is not a rhetorical question: there are many cases in which it is not worth touching. And there are others, increasingly frequent since 2024, in which postponing the migration is the highest hidden cost a company pays on its IT.

In this guide we try to draw the line between the two, and to explain the 5 concrete strategies for migration available in 2026. No whitepaper theory. Only what actually works when you touch a legacy system with 30 years of layered business logic.

TL;DR

• There are five real AS/400 migration strategies in 2026: replatforming, refactoring, replacement, retirement and hybrid approach. None is universally better.
• The dominant constraint is almost never technical: it is the coexistence between operational continuity of the business and availability of staff who know the existing codebase.
• Realistic cost ranges for a medium-sized Italian company: 80,000 to 500,000 euros. Timeframes go from 4 months (clean replatforming) to 24 to 36 months (replacement with complex historical data).
• The strangler pattern (module-by-module replacement with the legacy system still active) is the strategy with the lowest operational risk. It costs time: often 12 to 18 months. Almost always worth it.
• Modern AI tooling helps in reverse-engineering RPG/COBOL code but does not replace human work on domain knowledge. Anyone promising AI-driven automatic migrations is selling hot air.

Why are we talking about AS/400 again in 2026?

Because four things that until 2022 seemed manageable separately are now expiring at the same time.

First, RPG and COBOL programmers are retiring. The average age of Italian developers specialized in IBM i is today above 55. It is not a forecast: it is the observable data from CVs in circulation and from university curricula (no Italian ITS has been training RPG developers for around 15 years). Industry estimates indicate a significant contraction of active RPG personnel by 2030. For a company that depends on this staff for the evolutionary maintenance of its business management system, it is a problem that materializes in practice already in 2026 to 2027.

Second, integrations with modern systems are getting increasingly expensive. An AS/400 isolated from the rest is manageable. An AS/400 that has to exchange data with an e-commerce, a cloud CRM, a WMS, an electronic invoicing system, a modern BI and now also AI platforms is a permanent construction site. Each new integration requires building a custom bridge, and each custom bridge needs to be maintained. The technical debt of integrations grows faster than the value they produce.

Third, regulatory pressure. NIS2 (in Italy D.Lgs. 138/2024) imposes specific cyber risk management requirements, and a legacy system with layered historical accesses, incomplete logs and 2000s patch policies is objectively hard to bring into compliance. It is not impossible: it is expensive. The vintage 2018 GDPR has already required heavy interventions. NIS2, AgID, and looking ahead the AI Act (from August 2026) add further layers. On a 30-year-old AS/400 you end up spending on compliance what you would spend on a real migration.

Fourth, AI integration is impossible on closed systems. A company that wants to use LLMs to automate customer service, to extract information from contracts, to generate reports from its data, stops at the boundary of its AS/400 silos. The data is there but it is not queryable in a modern way: no native REST APIs, no streaming, no SDKs for cloud services. You can build bridges, but they are expensive and fragile. The opportunity cost of missed AI is invisible on financial statements, but it has already become one of the top drivers of modernization requests that we observe in the 2025 to 2026 market.

When these four weights add up on the same company, the question stops being “whether” to modernize and becomes “how, when, in what order”.

When is it NOT worth modernizing an AS/400?

A counter-intuitive but important section: there are real cases in which staying on legacy is the rational choice.

The first case is the end-of-life system. If the company has already decided to close that business line within 3 to 5 years, or if it has already planned the complete replacement of the AS/400 with another system (for example a new standard ERP) by 2027, modernizing the AS/400 ahead of decommissioning is a waste. You keep it operational, you patch the bare minimum needed for compliance, you switch it off when the time comes.

The second case is the stable, static, well-defined system. An AS/400 that manages a single flow (e.g. warehouse management of a single plant), that does not need to integrate with anything else, that still has 2 or 3 competent internal developers and none retiring in the next 5 years, can comfortably stay as it is. Modernizing a system that is not creating problems is a cost without upside.

The third case is the business in transition. If the company is being sold, merging, or undergoing deep restructuring, freezing IT is often the right choice. A migration carried out in the middle of an M&A becomes a construction site that blocks other things. Better to wait for organizational stabilization and tackle the migration with a clear scope.

The fourth case is the unit value of the legacy higher than the value of modernization. Some AS/400s contain business logic so specific, so refined by decades of iteration, that they represent a real competitive advantage. Thinking of rewriting it is dangerous: every rewrite loses something, and that something could be exactly what makes the company work. In these cases it is better to encapsulate the legacy behind a modern API layer (see strangler pattern later on) instead of replacing it.

What are the risks of NOT modernizing an AS/400?

Four main risks, in order of probability: (1) the impossibility of finding competent RPG/COBOL programmers within 5 years, with consequent explosion of rates for the few remaining ones; (2) growth of technical debt in integrations with modern systems, which at some point becomes more expensive to maintain than to rewrite; (3) a progressive compliance gap on NIS2, GDPR, accessibility and upcoming regulatory requirements; (4) a structural brake on the adoption of AI and automation, which becomes an increasingly expensive opportunity cost.

If none of these four risks applies to your case, you are probably in the “do not modernize” quadrant and you are right to stay there.

What are the 5 AS/400 migration strategies?

The operational strategies in 2026 are five. Not four, not six. Five is the right point between completeness and decision manageability.

1. Replatforming (lift-and-shift)

You take the AS/400 as it is and you move it onto cloud infrastructure, keeping the IBM i environment and the RPG/COBOL code unchanged. The main providers are IBM Cloud (Power Virtual Server), Skytap, Connectria, or hybrid setups on Azure/AWS.

When it makes sense: when the existing code works and the problem is infrastructural (old hardware, expensive maintenance contracts, need for modern disaster recovery). The added value is almost entirely operational: you pay less for hardware maintenance, you gain resilience, you delegate machine management to the hyperscaler.

What it does NOT solve: the RPG programmers problem. You continue to depend on that skill, simply on a different infrastructure. The integrations problem also remains: the AS/400 in the cloud still speaks its own dialect.

Timeframes and costs: 4 to 6 months, 80,000 to 150,000 euros for medium-sized companies. It is the fastest and least risky strategy, but it is also the one with the lowest transformation value.

2. Refactoring (gradual modular rewrite)

You progressively rewrite the software, module by module, in modern technologies (typically Java, .NET, Node.js or Python depending on the team), while the legacy system continues to run. The reference pattern is called strangler fig and is documented as a formal software engineering pattern: you gradually “strangle” the old system by replacing its pieces.

How it works in practice: you put an API layer in between (an HTTP/REST facade that talks to both systems), you identify an AS/400 module with a reasonably isolated interface (e.g. customer records management), you rewrite it in the new technology, you redirect traffic to the new one. The old module stays operational as a fallback for a few weeks, then is dismissed. You repeat for each module, in order of increasing risk.

When it makes sense: when there is strong dependency on the system (you cannot stop the business), when the existing code contains valuable logic that must be preserved, when the team has internal engineering capability for a long-term project.

What it does NOT solve in the short term: it does not immediately reduce dependency on RPG programmers, in fact in the first months it increases it (both skill sets are needed). The benefit is collected after 12 to 18 months.

Timeframes and costs: 12 to 24 months, 150,000 to 300,000 euros for medium-sized companies. It is the strategy with the lowest operational risk, because every step is reversible.

Can I migrate while keeping the system active?

Yes, with the strangler fig pattern. The legacy system continues to function while modules are progressively replaced. It is the safest strategy for business-critical systems. It takes more time (typically 12 to 24 months) but it eliminates the risk of a big-bang failure, that is the case in which you switch off the old system and the new one does not hold up the first day of production.

3. Replacement (complete substitution)

You abandon the custom software of the AS/400 and you adopt a standard market ERP: SAP, Microsoft Dynamics, Odoo, or an Italian vertical (TeamSystem, Zucchetti, ESA, NTS). The old system is switched off when the new one is in production, after data migration and user training.

When it makes sense: when the AS/400 software is not really a competitive advantage but a commodity that has become expensive to maintain. Typical in manufacturing and distribution SMEs, where the AS/400 does things that all modern standard ERPs also do, just in its own way.

What it does NOT solve: the adaptation of business processes to the new system. All the specificities you decided to encode in custom software 30 years ago, you now have to decide whether to: (a) bring into the standard system via customization (expensive), (b) change the processes to adapt them to the standard (politically difficult), (c) keep part of the processes outside the standard system (proliferation of Excel).

Timeframes and costs: 18 to 36 months, 250,000 to 500,000+ euros for medium-sized companies, including multi-year licenses and implementation consulting. It is often the most expensive migration and the one with the highest risk of organizational rejection.

4. Retirement (progressive dismissal)

You decide that some AS/400 functionalities are no longer strategic and you remove them without replacing them, or you replace them with distributed niche tools (e.g. invoicing with a dedicated service, warehouse with a vertical WMS, customer records inside a modern CRM). The monolith is decomposed into multiple pieces managed separately.

When it makes sense: when the AS/400 has grown over the years accumulating functions that today are better covered by specific tools. Often this is the reality in companies that have done little IT hygiene in the last 20 years and find themselves with a business management system that also does things it should not.

What it does NOT solve: the integration problem between all the new pieces. You go from a monolith to a set of systems that still have to talk. It is a simplification that brings complexity of another kind.

Timeframes and costs: 12 to 24 months depending on how many pieces are separated, 100,000 to 250,000 euros. Often combined with another strategy (e.g. retirement + replatforming of the core).

5. Hybrid approach

A combination of the previous ones. Almost always, when you go into the detail of a real case, the actual strategy is hybrid: replatforming of the core, refactoring of 2 or 3 critical modules, retirement of functionalities now marginal, replacement of one piece with a market tool.

When it makes sense: practically always, after a serious assessment. The “pure” strategies are useful as a framework for reasoning, but real companies sit in between.

Timeframes and costs: depend on the composition, but typically 180,000 to 400,000 euros in 18 to 30 months.

How to choose the right migration strategy?

Five decision criteria, in order of weight.

1. Required operational continuity. If the company cannot stop even for a weekend (e.g. 24/7 distribution, healthcare, continuous production), the strangler pattern (gradual refactoring) is almost mandatory. If instead there is a reasonable stop window (e.g. the August holiday week for seasonal manufacturing), more aggressive big-bang options open up.

2. Depth of custom business logic. If the AS/400 contains unique logic, accumulated through years of iteration (e.g. custom product configurator, algorithmic pricing, compliance rules specific to your industry), replacement with SAP/Dynamics risks losing it. Refactoring or hybrid are safer.

3. Budget and timeline. Replatforming is bought with 100k in 6 months. Replacement requires half a million in 2 to 3 years. The difference is not just financial: it is organizational absorption. How much can the company bear in terms of managerial attention towards a multi-year IT project?

4. Internal team skills. Do you have an internal IT team capable of managing a refactoring (it requires advanced engineering skills), or is it better for you to take a path that depends less on the internal team (replatforming, replacement)?

5. Market maturity for your industry. For some industries there are very mature Italian vertical ERPs (TeamSystem for professional firms, Zucchetti for HR, ESA for project-based manufacturing). For others the market is fragmented and custom remains the healthier choice. Studying what your industry peers really do helps calibrate the decision.

A useful 2x2 matrix to visualize:

                  LOW investment              HIGH investment
                ┌──────────────────────┬──────────────────────┐
   Operational  │                      │                      │
   risk         │   REPLATFORMING      │     REPLACEMENT      │
   LOW          │   (lift-and-shift)   │   (substitution)     │
                │                      │                      │
                ├──────────────────────┼──────────────────────┤
                │                      │                      │
   Operational  │     RETIREMENT       │     REFACTORING      │
   risk         │  (dismissal)         │  (strangler fig)     │
   HIGH         │                      │                      │
                └──────────────────────┴──────────────────────┘

The matrix has a second meaning that is often overlooked: “high” operational risk does not mean dangerous. It means it requires greater vigilance in the process, because you directly touch the business logic. Refactoring is in the top right not because it is dangerous, but because it touches the heart of the system while the system is running.

What are the most frequent mistakes in AS/400 migrations?

Seven failure patterns that we see repeating themselves.

1. Underestimating the domain knowledge hidden in the code. Twenty-year-old RPG code contains not only logic, but decisions: discount rules verbally agreed with three historical clients, exceptions for the Brescia warehouse that only it has, commission calculations that nobody remembers anymore because they just work that way. People always estimate by lines of code. They should estimate by business rules to disambiguate, which are typically 3 to 5 times more.

2. Treating the migration as an IT project instead of a business transformation project. Migrations that fail often fail because the company thinks the CTO is enough. Actually you need commitment from the CEO, because you touch flows that cross all departments. Without continuous executive sponsorship, the first conflict between IT and operations blocks the project.

3. Big-bang without fallback. Switching off the old system the day the new one starts, without a tested rollback plan, is the single most risky decision. Even the best-planned migrations have bugs on go-live day. Without fallback, a critical bug becomes an operational catastrophe.

4. Ignoring legacy data quality. Historical AS/400 data contains errors, duplicates, obsolete encodings, empty fields with implicit meaning. Migrating them “as they are” to the new system carries the same problems into the new world. Data cleansing should be done before migration, but it is a job nobody wants to pay for.

5. Underestimating end-user training. The new system is different, the screens are different, the function keys disappear. Users who have been using the old system for 25 years have the muscle memory of key sequences that the new system does not reproduce. Without a serious training plan (40 to 80 hours per power user), user rejection sinks the migration even if it is technically perfect.

6. Relying on vendors that sell standard packages without adaptation. There are integrators who “migrate AS/400s” by selling the same playbook to everyone. If the consultant does not first ask you what exactly your AS/400 does, they are selling something pre-built that might not fit your reality.

7. Not planning for post-go-live. The first 3 to 6 months after go-live are the most critical. Residual bugs are found, unmanaged cases are discovered, users ask for adaptations. Without a budget and a team allocated for the post-go-live phase, the project closes formally but leaves an unstable system as legacy.

How long does it take to migrate an AS/400?

Migrating an AS/400 typically requires 6 to 18 months, depending on the complexity of the code and the chosen strategy. Replatforming can be completed in 4 to 6 months. Gradual refactoring takes 12 to 24 months but with lower operational risk. Total replacement takes 18 to 36 months.

The factors that shift timeframes are: number of RPG programs (above 1,500 programs the timeframes double), number of external integrations (each external integration adds 4 to 8 weeks), volume of historical data to migrate (above 50 million records you enter double-digit weeks just for data transfer), customizations accumulated over the years.

A useful benchmark: for an average Italian AS/400 (1,000 to 2,000 RPG programs, 8 to 12 external integrations, 10 to 50 million historical records) a serious refactoring typically requires 15 to 18 months. If somebody proposes less than 9 months for this range, either they have not understood the problem or they are mis-selling.

How much does an AS/400 migration cost in 2026?

The realistic range for a medium-sized Italian company is 80,000 to 500,000 euros, but it is a range too wide to be useful. Breaking it down by strategy: replatforming 80 to 150k, refactoring 150 to 300k, replacement 250 to 500k+, retirement 100 to 250k depending on the depth, hybrid typically 180 to 400k.

The main factors that vary the price are four: number of RPG programs (a proxy for functional complexity), number of external integrations (each custom bridge costs tens of thousands of euros), volume of historical data (impacting both transfer and cleansing), accumulated customizations (the more there are, the more assessment is needed before estimating).

An operational rule that works: take the number of active RPG programs and multiply by 100 to 150 euros to get a minimum order of magnitude for refactoring. For replatforming divide by 2 to 3. For replacement add the multi-year licenses of the new system (typically 50 to 200k depending on the product and number of users). They are orders of magnitude, not estimates: every real case requires assessment.

What role does modern AI tooling play in AS/400 modernization?

Here we need to be honest, because industry marketing has been hyping up the topic for almost three years.

What AI does really well today: reverse-engineering legacy RPG code. Modern models (Claude, GPT, Gemini in coding version) read thirty-year-old RPG code and produce very understandable explanations in Italian. For a team that inherits a codebase without documentation, this accelerates the discovery phase significantly: what required 4 to 6 weeks of manual reverse-engineering now takes 2 to 3 weeks with AI as a copilot.

What AI does decently: translate RPG into modern languages at the syntactic level. You give the model an RPG program and ask it to produce the equivalent in Java or Python. The output is readable, but almost always does not work in production without heavy editing. Not because AI is incapable: because the real RPG program contains assumptions about the context (file on tape, DB2 for i journaling, indexed access) that the target language does not natively replicate.

What AI does NOT do: understand the implicit business logic. The model translates what it sees, not what it should be. If the RPG code calculates customer discount with a formula that changes based on the agent code, and there is an exception documented only as a comment in 1998 Piedmontese dialect, AI does not understand that that rule no longer applies since 2015. It just translates it. Only a human being who talks to whoever manages the product can decide what to preserve, what to eliminate, what to change.

The most important warning: anyone proposing “AI-driven” AS/400 migrations as if they were one click is offloading the risk onto the client. The real value of AI in modernization is as an accelerator of the analysis phase and the first draft of the new code, not as an automaton. Senior supervision remains indispensable, and total timeframes are compressed by 20 to 30% at most, not 70 to 80% as you sometimes hear promised.

For those who want to experiment, the approach that works is: use a modern LLM as a translation copilot, not as an engine. You give it an RPG program, you ask for translation + explanation + list of assumptions, and then a senior developer decides what to keep. It is the way we use AI in the modernization projects we run internally.

FAQ

Can you migrate an AS/400 without rewriting RPG?

Yes, with replatforming. The RPG code stays unchanged, only the underlying infrastructure changes (cloud instead of on-premise hardware). It is the fastest strategy but it does not solve the problem of scarcity of RPG developers: you continue to depend on them, just on a different machine.

What happens to historical data when you migrate?

It is decided case by case. The options are: (1) migrate everything to the new system (expensive, long, but “all in one place”); (2) migrate only active data and archive the rest on a data lake or read-only system (faster, but two places to consult for historical searches); (3) keep the AS/400 in read-only mode for years as a source of historical consultation, while the new system runs (a pragmatic compromise often adopted).

How much does it cost to maintain an AS/400 today versus the cloud?

For medium-sized companies, the annual TCO of an on-premise AS/400 (hardware, IBM hardware maintenance, IBM i licenses, RPG staff, energy, physical space) is typically 45,000 to 90,000 euros per year. The same workload in the cloud (IBM Power Virtual Server, Skytap, Connectria) settles at 30,000 to 55,000 euros per year. Savings of 25 to 40% on TCO, plus superior resilience. The replatforming pays for itself in 3 to 5 years.

Is an Italian partner or a global one better for migration?

It depends on the scope. For pure replatforming a global partner works fine (IBM, Skytap, certified IBM Cloud partners) because the value is infrastructural. For refactoring and replacement an Italian partner has clear advantages: speaks the local business language, knows Italian regulatory constraints (GDPR, NIS2, electronic invoicing via SDI, digital preservation), and has rates more aligned with Italian SMEs (typically 50 to 65% of the cost of an equivalent global big player). It is not always true, but it is worth using as a starting hypothesis.

What should you do before starting the assessment?

Three things, in order. (1) Document what the AS/400 actually does today: list of main modules, external integrations, users, volumes (even approximate ones). (2) Map the internal stakeholders: who are the three people without whose input any migration will fail? Involve them from the start. (3) Define the indicative budget at three horizons: what we are willing to invest within 6 months (pilot/replatforming), within 18 months (partial refactoring), within 3 years (complete modernization). Without these three pieces of information, any estimate you receive will be generic.

Conclusion and next steps

Migrating an AS/400 in 2026 is not a pure IT project: it is a strategic decision that touches operational continuity, internal skills, compliance and future ability to adopt AI. The five available strategies (replatforming, refactoring, replacement, retirement, hybrid) cover all sensible cases. Which one is right for your company depends on the specific mix of constraints, not on a universal framework.

What emerges from conversations with CIOs and IT directors of Italian SMEs: those who start tackling the decision in 2026 have time to do it well. Those who wait until 2028 probably will not have the availability of RPG programmers to manage the transition calmly. The time to start the assessment, even just to understand where you stand, is now.

If you are evaluating an AS/400 migration and you want a concrete conversation, without automatic estimates and without invented flat fees, let’s talk. The first conversation is free and lasts the time of a phone call.

To go deeper on other dimensions of the topic, the following internal references are useful: the pillar page legacy modernization, the page dedicated to AS/400 cloud migration, and the industry page manufacturing, where the AS/400 is still today a hidden protagonist of the Italian production chain.