SAP on IBM i: how to add capacity without changing platforms

By the Redsis Infrastructure team · October 2026 · 6 min read

A sector growing at double digits

Colombian retail is in an expansion cycle. The sector's 20 largest companies posted combined revenue of COP 117.3 trillion in 2025, up 12.3% year over year, and the top five captured 65.2% of that revenue, according to the ranking published by El Colombiano. Our client is one of those five.

For IT teams, that growth means more SKUs, more stores, more transactions and more history piling up in the database. And in an ERP that has been in production for years, the memory and storage consumption curve is rarely flat.

Two ceilings at once: compute and storage

The chain's situation was typical but demanding. Analysis of SAP's behavior showed the IBM Power E870 server would need more processing power and memory to support production for roughly another year. At the same time, every bit of storage available to production had already been allocated across two IBM Storwize V7000 systems virtualized behind an IBM SAN Volume Controller.

When both limits arrive together, it's tempting to solve everything with one big project: a new server, new storage, a full migration. Sometimes that's the right call. In this case, there was a more efficient option.

Capacity on demand: pay for what the business needs, when it needs it

Enterprise-class IBM Power servers can ship with processors and memory that are physically installed but inactive. With Capacity on Demand, that capacity is switched on through licensing, either permanently or for a set period, without swapping hardware or taking the system down.

For the chain, Redsis enabled the equivalent of 20 POWER8 cores and 512 GB of memory on its Power E870 for a defined term. The 512 GB were added to the existing 1.5 TB for a total of 2 TB of RAM, enough to cover the operating horizon the application analysis pointed to. The chain can draw on that capacity as business needs dictate, with no platform change.

Storage: refresh the hardware, keep the architecture

On the storage side, the decision was to keep what worked (a virtualized architecture with a local replica) and refresh the components with current-generation flash:

• IBM SAN Volume Controller 2147-SV2. SVC virtualizes storage and presents servers with a single pool of capacity, independent of the physical arrays behind it. The new model brings more processing power and more cache, and includes a spare.
• Two IBM FlashSystem 7200 arrays for production. Each with 107 TB of effective capacity, they replace the Storwize V7000 systems and spread the SAP workloads.
• A third FlashSystem 7200 for the local copy. Another 107 TB effective to keep a replica of the environment on a separate system, using SVC Volume Mirroring.
• FlashCopy with thin provisioning. The chain keeps its snapshot-based backup process, with volumes that consume only the space actually written.
• Two new SAN switches for server-to-storage connectivity.

The result is 321 TB of effective flash capacity on an architecture the client's team already knew, which shortens the learning curve and lowers the operational risk of the change.

Five lessons for sizing SAP on IBM i

1. Size from application data, not gut feel

The starting point was how SAP actually behaved in production. Projecting CPU and memory consumption from current operations lets you buy capacity for a specific horizon instead of oversizing "just in case."

2. Decouple the compute decision from the storage decision

Servers and storage don't always age at the same pace. Tackling each with the right tool (capacity on demand for one, a refresh for the other) is often more efficient than a wholesale replacement.

3. Put storage virtualization to work

With a layer like SVC, swapping the arrays behind it is far less disruptive: servers keep seeing the same volumes while data moves to the new hardware.

4. Design the local copy in from the start

A replica on a separate system isn't an add-on for later. Designing it alongside production capacity ensures both grow at the same pace.

5. Make it a total-cost-of-ownership conversation

This was the key to the project. Redsis presented a TCO analysis that let the chain see how replacing its storage systems would deliver better performance and more capacity at a lower total cost. Support on aging hardware, power, data center floor space and administration effort weigh as much as the purchase price.

The result: more capacity, lower total cost

Today the chain's SAP Retail runs with 2 TB of RAM, 20 additional POWER8 cores available on demand and 321 TB of effective capacity on IBM FlashSystem 7200, with a local replica of the entire environment and its backup process intact. All of it on the same IBM Power and IBM i platform that already supported its national operation, with better performance and a lower total cost of ownership.

Where to start

If your SAP on IBM i environment is showing signs of saturation (memory at the limit, storage 100% allocated or hardware nearing end of support), the first step is a capacity assessment based on real data. At Redsis we combine more than 25 years of mission-critical infrastructure experience in Latin America with our IBM Platinum partnership to design the right mix of compute, storage and cost.