Replacing an AS/400 merchandising system: what specialty retailers should consider
A retailer moving off AS/400 or IBM i should shortlist by retail segment before shortlisting by size. For fashion, apparel, footwear and specialty retailers, two requirements narrow the field faster than anything else: whether the system handles style, color and size matrix inventory natively, and whether it can take over merchandising in stages while the existing platform keeps running. Enterprise suites will handle the transaction volume. Matrix merchandising and phased cutover are where specialty replacements usually fail.
Which merchandising systems should a specialty retailer consider?
The field divides into three groups, and most specialty retailers only need to evaluate two of them.
Enterprise suites.
Oracle Retail Merchandising and SAP S/4HANA for Retail are built for high transaction volume, multi-banner and multi-currency operations, and deep retail accounting. Both will do what an AS/400 merchandising system does. Both carry long implementation programs and substantial process redesign, and for a chain below a few hundred stores the capability usually exceeds the need.
Planning and supply chain platforms.
Blue Yonder and RELEX are strong where the reason for moving is forecasting, allocation or replenishment rather than merchandising itself. Neither is an automatic one-for-one replacement for a system that owns items, vendors, purchase orders and the stock ledger, so check what stays behind before treating either as the core.
Specialty and mid-market merchandising systems.
Aptos, Infor CloudSuite and Island Pacific are built around the way fashion and specialty retailers actually buy, which means matrix inventory, seasonal buying and markdown behavior are part of the design rather than a configuration exercise. NetSuite belongs here too if the AS/400 has been acting as a lightweight ERP rather than as a merchandising system of record.
The useful way to cut this is not by vendor size. It is by asking which group your current system belongs to. A retailer whose AS/400 owns items, vendors, costs, purchase orders, allocation and the stock ledger is replacing a merchandising system of record and should shortlist from the first and third groups. A retailer whose AS/400 is mostly holding inventory and feeding a separate finance system is replacing something smaller, and the shortlist changes accordingly.
What to work out before you shortlist anything
Most AS/400 replacements go wrong at the requirements stage, not the selection stage. Three things are worth establishing before a single vendor conversation.
The rules that exist only in code.
A merchandising system that has run for twenty or thirty years accumulates logic that was never written down. Supplier exceptions, pre-pack handling, promotional rules and markdown triggers commonly live inside RPG programs rather than in any document, and in many cases they were built by people who have left. Some of them are real business requirements. Some are workarounds for something the system could not do in 1998. You need to know which is which, because a commercial platform will enforce standardized fields and will not accommodate a rule nobody can explain.
What the overnight batch is actually doing.
AS/400 merchandising typically runs allocation, replenishment and inventory positions as overnight batch jobs. The business has spent years building working practice around the timing of those jobs, often without noticing. Buyers expect a position at a certain hour. Store replenishment lands on a certain cycle. Moving to a system that calculates in near real time changes that rhythm, and every downstream integration built on the old timing needs revisiting.
The matrix question.
Matrix inventory means a single product managed across style, color and size, so that a shirt in four colors and six sizes is one item with twenty four sellable variants, held and planned as a grid rather than as twenty four unrelated SKUs. Most general merchandising and ERP systems can be made to hold this. Fewer handle it natively in buying, allocation, replenishment and markdown at the same time. If your AS/400 handles it and the replacement does not, that gap will surface late and expensively, so test it early with your own assortment rather than accepting a demonstration built on someone else’s.
Should you replace the system, move in stages, or modernize where you are?
Three routes exist and the honest answer is that not every retailer should take the first one.
Full replacement.
Suits a retailer whose business model has moved past what the current system was built for, or whose merchandising processes need redesigning anyway. It is the cleanest end state and the highest risk, because it concentrates the risk into a single cutover.
Phased replacement
Moves merchandising functions across one at a time while the existing platform keeps running the rest. Planning might move first, then buying, then inventory, with the AS/400 continuing to hold the ledger until the last stage. It takes longer overall and it demands that both systems stay in step during the transition, which is a real integration burden. It also means no single date on which the business is betting everything.
Modernizing in place
Keeps the AS/400 as the transaction engine and wraps its DB2 data in an API layer so modern tools can sit on top of it. If the platform is stable and the actual complaint is the interface, the reporting or the lack of ecommerce integration, this is a legitimate answer and it is cheaper than a replacement. It does not solve a skills problem, and it leaves the undocumented logic exactly where it is.
One assumption worth checking before you choose. IBM Power 9 reaching end of support is not the same as IBM i ending, and the two often get conflated in migration conversations. IBM announced Power11 in July 2025, with general availability from 25 July 2025. IBM i 7.4, 7.5 and 7.6 all carry the code levels needed to run on Power11 hardware. The platform continued. That does not mean staying is right for you, but it does mean the decision should rest on what your business needs rather than on a hardware deadline.
How to evaluate a merchandising system for matrix inventory
Run the same scenario through every vendor on the shortlist, using your own assortment and your own numbers rather than a scripted demonstration. Six steps separate systems that handle specialty retail from systems that can be configured to survive it.
Create a seasonal style across a color and size grid, and count the steps it takes.
Buy it against an open-to-buy position and see whether the position updates as the buy is committed.
Allocate it across stores with different size profiles, because uniform allocation is the failure mode.
Take a mid-season markdown on one color only and check that the rest of the style is unaffected.
Fulfill an online order from store stock and confirm the inventory record stays correct across both.
Close the period and reconcile margin.
If a vendor needs custom development for any of those, that is not a gap in the demonstration. It is the shape of the implementation you are buying. The same discipline applies to markdown behavior, where most of the damage traces back to buying and allocation rather than to the discount itself.
Where Island Pacific fits
Island Pacific builds merchandise management, merchandise planning, inventory management, order management and analytics software for fashion, apparel, footwear and specialty retailers. The company has been doing that since 1977, which covers the working life of the IBM midrange platform, and its applications run on multiple IBM Power platforms, on Windows, and in a range of cloud configurations. On-premise deployment remains available. Retail Robot, launched in 2025, is cloud software sold as SaaS.
Two things follow that are relevant to a retailer in the middle of this decision.
The first is that phased replacement is a route Island Pacific supports rather than an exception it tolerates. The platform is modular, its components are chosen to fit the job each one does, and merchandising functions can move across while the existing environment continues to run. Island Pacific has had a planning product since 1997, so planning is a viable first stage rather than something bolted on at the end.
The second concerns the customizations. Island Pacific runs a fixed-fee program that analyzes and remediates modifications as part of an upgrade, including rewriting custom code into a service-oriented architecture so that later upgrades get easier. That matters for a retailer carrying decades of accumulated modifications, because the alternative on most platforms is to carry the customization debt across and pay for it again at every upgrade.
For scale, Island Pacific’s merchandising software runs for Primark, American Eagle and Urban Outfitters, which grew from three stores to more than 800 on the platform. Implementation for a mid-size chain takes four to six months, with the source and quality of the migrating data the variable that moves that range most. Upgrades take one to four months and customers typically take one a year.
Island Pacific is not an ERP. It does not carry full financials or HCM, and it integrates with systems that do, including Workday. If that boundary matters to your architecture, we set it out in full here. If the question behind your move is whether the platform itself is current, that is answered separately.
Common questions
Is AS/400 the same as IBM i?
They are stages of the same platform. AS/400 was the name IBM used from 1988. The hardware line became iSeries, then System i, and now IBM Power; the operating system is IBM i. A retailer who says they are on the AS/400 is almost always running IBM i on Power hardware.
Do we have to replace everything at once?
No. Merchandising functions can move across in stages while the existing platform continues to run the rest, with planning as a common first step. It takes longer and requires both systems to stay in step during the transition, and it removes the single-date risk of a full cutover.
What happens to our historical data?
AS/400 systems store numeric data in packed decimal format and text in EBCDIC encoding, neither of which transfers cleanly into a modern SQL database without conversion. Precision loss in cost, margin and historical purchase order data is the usual failure, and it tends to surface during a financial reconciliation rather than during testing. Scope the data conversion separately from the software selection.
How long does a merchandising system replacement take?
For a mid-size chain on Island Pacific, four to six months, with the quality of the migrating data the main variable. Enterprise suite implementations at large retailers commonly run considerably longer.
Is IBM i being discontinued?
No. IBM i 7.4, 7.5 and 7.6 all support the current Power11 hardware generation, which became generally available in July 2025. Power 9 reaching end of support is a hardware generation ending, not the platform.
Working out whether a phased move is right for you?
Bring the shortlist criteria above and we will walk through them against your own assortment, including which functions could move first and what stays where it is.
