AS/400 modernization with running business: manufacturing scenario

Editorial note: the scenario described is an industry-typical pattern built from elements common to real AS/400 modernization projects in Italian manufacturing. It is not a specific Obsidian client case.

A manufacturing company in the Marche region, 120 employees, two production plants, AS/400 in production since 1998. Three production lines running 24/7 shifts. The system handles orders, MRP, warehouse, invoicing, quality control. Turning it off is not an option: every hour of downtime means 8,000-12,000 euro of lost production. Let’s look at how to set up a strangler fig modernization in this context, because it is the most replicable pattern in Italian manufacturing.

The scenario context

A manufacturing company in the precision-mechanical sector in the province of Pesaro:

• 120 employees total: 90 in production on three shifts, 30 in offices (admin, sales, quality, IT)
• Two plants, main site + production branch
• Revenue around 25-35 million euro/year
• AS/400 IBM Power7 (2010 hardware, already on IBM extended support)
• ~1,400 active RPG programs developed in-house between 1998 and 2018
• 8 external integrations: B2B e-commerce, line MES, cloud CRM system, electronic invoicing via SDI, logistics system for shipping, quality control (with scales and measurement instruments), digital signature system, document management
• Historical database: ~80 million production records, 12 million order records, 4 million master data records (customers + items + BOM components)
• In-house RPG staff: 1 senior aged 58 (retiring in 2027), 1 junior aged 41 with limited RPG skills

The concrete pain: hardware out of IBM maintenance, rising management costs, increasingly expensive new integrations ($30-50k per integration for cloud CRM), no pipeline to integrate AI/automation that the board would like to test, prospect of the senior retiring with undocumented knowledge.

What is available (project constraints)

• Budget: 280-400k euro total, distributable over 24-30 months
• Timeline: no external deadline, but the senior RPG developer retires at the end of 2027 (soft constraint)
• Internal team: 1 senior RPG part-time on the project (50%), 1 junior full-time (for the handover), 1 IT manager (10%)
• Non-negotiable constraint: zero production downtime. The three 24/7 lines cannot stop for migration, ever
• Non-negotiable constraint: historical production data (useful for quality certifications, customer warranties, potential recalls) must remain queryable for at least 10 years
• Non-negotiable constraint: every change to the line MES (line-to-AS/400 protocol) requires coordination with a line-stop of max 2 hours in the night window

The chosen approach: modular strangler fig

Three scope decisions in the first 4 weeks.

Decision 1: modular strangler fig instead of big-bang or replacement. The alternatives evaluated:

• Big-bang replacement with SAP Business One or TeamSystem Enterprise: ruled out due to operational risk (1-2 weekends of minimum downtime in cut-over phase, not sustainable for 24/7).
• Monolithic refactoring: ruled out due to dependency on the retiring senior RPG developer.
• Pure replatforming (lift-and-shift to IBM Cloud): considered as an intermediate phase, but does not resolve the RPG dependency.
• Strangler fig: chosen because it keeps production active, distributes risk module by module, and progressively frees up the senior RPG developer.

Decision 2: migration order driven by risk + opportunity. We start from modules with low operational risk + high modernization value:

1. Customer master data module (low risk, high value: enables simpler cloud CRM integrations)
2. Item/BOM master data module (medium risk, high value)
3. Orders module (high risk but core, to be done carefully)
4. Invoicing module (medium risk, standard value)
5. Warehouse module (high risk, high value)
6. MRP + production module (highest risk, last module migrated)

Historical production data stays on the AS/400 in read-only mode after the MRP module is decommissioned.

Decision 3: deliberate target stack.

• Backend: Node.js + TypeScript (wide talent pool, excellent AI tooling, fit with the microservices that the junior team can maintain)
• Database: PostgreSQL on a cloud instance (Hetzner Helsinki, GDPR-friendly)
• Compatibility layer: an “AS/400 facade” service that translates REST requests into calls to the legacy business management system (via IBM i Access Client Solutions API)
• Observability: Grafana + Loki + Tempo, self-hosted

The execution: the first 24 months

Months 1-3: foundation

• Complete audit of the RPG code with AI assistance to accelerate reverse-engineering
• Mapping of the ~340 business rules hidden in the core RPG programs
• Setup of target infrastructure (cloud, CI/CD, monitoring)
• Construction of the initial AS/400-to-REST facade

Months 4-6: first module (customer master data)

• Rewrite of the customer master data module in Node.js + PostgreSQL
• Development in shadow mode: the new module receives requests in parallel with the AS/400, outputs compared
• Week 24: cut-over of the customer master data module, legacy as fallback for 4 weeks
• Week 28: decommissioning of the RPG master data module, the AS/400 now calls the new service via facade

Months 7-10: second module (item/BOM master data)

• Same pattern, greater complexity due to the recursive BOM structure
• Weeks 36-40: cut-over with longer shadow period (BOM is critical)

Months 11-14: third module (orders)

• Core module, the rewrite requires maximum attention
• 8 sub-modules: customer orders, confirmations, changes, fulfillments, cancellations, RMAs, back-orders, anomalies
• Extended shadow mode (6 weeks) before cut-over

Months 15-18: fourth module (invoicing)

• Including migration of SDI integrations from the RPG system to the new system
• Cut-over with particular attention to fiscal reconciliation

Months 19-22: fifth module (warehouse)

• Integration with barcode readers and industrial scales (the proprietary protocols are the hidden cost driver here)
• Cut-over in a night window agreed with the warehouse staff on shift

Months 23-30: sixth module (MRP + production)

• The most critical module, manages the three 24/7 lines
• Extended shadow mode (12 weeks) with bit-by-bit comparison of outputs
• Gradual cut-over: first one line, then the second, then the third, each in 2-hour night stop windows

Months 31-32: legacy decommissioning + historical data freeze

• AS/400 in read-only mode
• All historical data accessible via query, but writes disabled
• Partial shutdown (reduction of IBM extended support costs)

The results after 24 months (module 5 completed)

(illustrative numbers from industry-typical patterns):

• Zero production stops attributable to migration (zero downtime)
• 5 of 6 modules migrated, 64 KLOC out of ~95 removed from the AS/400
• Cost savings already measurable: -35k euro/year in AS/400 infrastructure costs + -25k/year in external consultancy on the now-modern modules
• 3 new integrations enabled by the new stack (impossible on pure legacy): real-time management dashboard, AI agent for customer service, integration with modern production scheduling system
• Senior RPG developer: retired at the end of 2027 as planned, the junior now handles 80% of the remaining legacy modules (only MRP)
• Onboarding time for a new developer: from 8-12 months (to learn RPG) to 4-6 weeks (to be productive on Node.js + PostgreSQL)

What would make the difference in similar projects

1. More time on the AS/400 facade in the first weeks. The initial compatibility layer is typically underestimated by 4-5 weeks. Investing more time in it at the start pays off, rather than patching it during the first two modules.

2. Automated shadow mode from the first module. Manual comparison of legacy vs new outputs (developer sampling) does not scale. From the start, a diff automation service that logs all divergences is needed. Introducing it only from module 3 onwards is too late.

3. Involve the MES vendor sooner. The line MES typically has proprietary APIs that are only really understood once you reach module 5 (warehouse). A technical deep-dive call with the MES vendor in month 1-2 avoids 3-4 weeks of reverse-engineering later on.

Transferable lessons learned

1. Strangler fig requires 50% more time than a “pure” refactoring, but it eliminates operational risk. For 24/7 businesses this is the decisive advantage. The additional cost is almost always less than the cost of a failed big-bang outage.

2. The order of the modules matters more than speed. Wrong to start from the “most important” module (MRP) out of a desire to show results. We start from the less risky but high enabling-value modules (master data), we build the team’s muscle memory, we attack the core only when the team is experienced.

3. AI as a copilot for RPG analysis is a game-changer. Without AI assistance, reverse-engineering 1,400 RPG programs would have taken 6-9 months. With AI as a reading copilot (Claude / GPT in code mode), it was reduced to 3-4 months. For writing the new code, AI contributed less (business-specific code, AI doesn’t know it), but for understanding the legacy it was decisive.

4. A well-built facade is the single most profitable investment. The compatibility layer between legacy AS/400 and new services is what allows the system to work throughout the transition. Underinvesting in it leads to fragility that costs dearly to recover.

5. Junior backfill of the retiring senior: 18 months are not enough. The senior RPG part-time + junior full-time for the 24 months of the project was the minimum formula. Starting earlier (3 years before retirement) would have been better: the junior would have absorbed more domain knowledge.

FAQ

How much does a strangler fig migration cost for a company of this size?

For similar scenarios (100-200 employees, revenue 20-50M, AS/400 with 1,000-2,000 active programs): 250-450k euro total over 24-36 months. It is more expensive than replacement (200-350k) but eliminates the operational risk that for 24/7 businesses is the dominant constraint.

Can it be done with a smaller vendor-side team?

In projects of this scale the typical setup is 2-3 dedicated developers + 1 architect + 1 project manager. With fewer people, timelines rise linearly. With more people it does not scale well beyond 4-5: coordination on the complex parts of the legacy requires a few senior engineers who have the full picture, not many hands.

What happens if the senior RPG developer retires before the end of the project?

A real risk scenario, mitigated as follows: (a) involvement of the senior in all domain knowledge mapping decisions in the first 12 months, (b) serious documentary handover (60-80 pages of structured documentation on the core modules), (c) contractual agreement for post-retirement consultancy of 30-50 hours/year if needed. External consultant cost: 80-150 euro/hour. It can be managed, but prevention is better.

How much does it cost to keep the AS/400 in read-only after decommissioning?

Typically 4-8k euro/year if kept in the cloud (Skytap, IBM Cloud) with minimum config. How long to keep it is evaluated case by case: often 2-3 years after complete cut-over, then historical data is migrated to a modern data lake with a consultation interface.

Can AI replace the senior RPG developer?

No. AI is an analysis accelerator, not a substitute for expertise. The senior RPG developer knows the operational history of the code (who wrote what, why, what is still valid, what is not). AI can read code but does not know implicit decisions. Companies that try to replace the senior with pure AI discover after 6-9 months that they have lost important pieces of operational know-how.

Can the same pattern be applied to systems other than AS/400 (e.g. custom ERP in .NET 2.0)?

Yes, perfectly. The strangler fig is agnostic with respect to the starting technology. The pattern works for any monolithic system that you want to modernize without operational downtime: AS/400, custom ERP in .NET/Java/Delphi, IBM z/OS mainframe systems. The technical details of the facade and reverse-engineering change, but the project structure is the same.

Conclusion

Modernizing an AS/400 with a 24/7 running business is not easy but it is feasible with a strangler fig strategy, modular order driven by risk and opportunity, a senior team with the necessary patience. Companies that tackle it calmly over 24-36 months get a modern system without a single hour of downtime. Those that try to do it in 12 months with big-bang almost always fail, and the costs of failure far exceed the savings sought.

If you run a manufacturing company with a critical AS/400 and want to discuss the modernization pattern applicable to your case, let’s talk. The first conversation is free.

To go deeper: the pillar page legacy modernization, the page dedicated to AS/400 cloud migration, the manufacturing sector page, and related articles AS/400 migration guide and 5 legacy migration traps.