IBM Power Migration Stories

Power Migration Stories: What Worked, What Broke, What Changed

Old Power systems are interesting because of what their owners did next. These seven stories show the savings, downtime, mistakes, and practical choices behind real moves across Power generations and from other platforms.

Read the Stories Open the Public Dataset

Nobody needs another page telling them that a newer server is faster. The useful part is what people changed around the server, what they gained, and where the plan nearly fell apart.

Success had more than one shape

Some teams removed physical servers. Others cut software cost, shortened backups, or finally built a recovery system they could trust.

The mistakes belong in the story

An untested restore and an unavailable backup specialist teach more than a clean vendor diagram ever will.

Old moves explain new ones

The same choices around storage, licensing, downtime, and outside help still matter when Power9 moves to Power11.

1
Real migration story

Power7 to Power9: A retailer changed the storage problem too

The public account reports lower annual cost, less iSeries capacity, faster storage, and more room to scale storage when needed.

Where it started

A North American retailer ran IBM i on an on-premises Power7 environment. Its storage was due for replacement, and the platform had become expensive and inflexible.

What changed

TCS and IBM moved the AS/400 environment to IBM Power Virtual Server running on Power9.

reported annual savings
$450,000
reported decrease in iSeries capacity
30%
landing generation
Power9

What worked

The team did not treat the server as the whole project. Moving compute and storage together removed an aging storage purchase and changed how capacity could be added.

What was hard

The public story does not publish the downtime window or the application changes. It proves the business result, but not that every Power7 workload can make the same move the same way.

What the next owner can use

The strongest migration may solve the storage bill and capacity problem at the same time as the processor change.

2
Real migration story

Power5 and Power7 to Power8: Carhartt replaced eight servers with two

The smaller physical footprint reduced upkeep while virtual servers gave a three-person operations team room to expand for seasonal demand.

Where it started

Carhartt had eight Power5 and Power7 servers supporting IBM i workloads while its international sales operation kept growing.

What changed

The company consolidated those systems onto two Power8 servers and IBM storage. It later moved to Power E980 enterprise servers as the workload kept growing.

physical Power servers
8 to 2
reported footprint reduction
70%+
reported planned downtime per application
30 min
estimated savings
$1.1M

What worked

The smaller Power estate supported seasonal growth. Carhartt could add virtual application servers during peak online demand, then scale the virtual estate as needs changed.

What was hard

The useful result was not a faster chip by itself. The team had to move data, storage, and application workloads while keeping planned downtime short for each application.

What the next owner can use

A generation change earns its keep when it removes machines and daily work while preserving room to grow.

3
Real migration story

Power 795 to Power8: Copel kept the core count and changed the economics

Copel reported more capacity, shorter backups, reusable Oracle licenses, and a lower migration and hardware cost than the next-best option it studied.

Where it started

Copel ran Oracle Database on two Power 795 systems with 128 Power7 cores. Business growth was pushing the environment beyond the performance it could comfortably deliver.

What changed

The utility moved the Oracle workload to two Power E880C systems with 128 Power8 cores after comparing Power with x86 alternatives.

estimated savings
$2M
Oracle licenses freed for other use
49%
reported backup-time reduction
43%
cores before and after
128

What worked

The team compared the full business case instead of treating core count as the answer. Power8 delivered more work per core while the same total core count supported a larger workload.

What was hard

Oracle licensing made processor efficiency part of the financial decision. A technically smaller design would not have been useful if the licensing plan had been ignored.

What the next owner can use

Count the software tied to the cores, not only the cores in the frame.

4
Real migration story

Power9 to Power11: Dekko cut every reported save window

All four LPAR save windows reported by the owner became shorter. The team kept the same virtual tape library for backup.

Where it started

Dekko ran IBM i and AIX on a Power9 9009-41A with internal SSD storage.

What changed

The team moved to a Power11 9824-22A with an IBM FlashSystem 7300 SAN and NVMe drives. Consultants configured VIOS, Fibre Channel switches, and the SAN.

LPAR 1 save time
2:04 to 1:30
LPAR 2 save time
1:07 to 0:33
LPAR 3 save time
0:23 to 0:14
LPAR 4 save time
2:21 to 1:22

What worked

The owner used a scratch install from tape so microcode and program temporary fix levels matched. Storage and network specialists handled the parts that were outside the day-to-day application role.

What was hard

The story is refreshingly plain about outside help. VIOS, the switches, and the SAN were consultant work rather than magic performed by the faster server.

What the next owner can use

A successful generation move can keep a familiar recovery method while specialists rebuild the storage and virtualization foundation around it.

5
Real migration story

x86 to Power9: Electrolux moved the recovery plan with the workload

The migration finished in under four weeks. Electrolux reported faster recovery, lower disaster recovery cost, and shorter maintenance work.

Where it started

Electrolux had SAP HANA workloads spread across x86 appliances and expected its storage demand to keep rising.

What changed

The company centralized its European SAP HANA environment on two Power E980 systems with FlashSystem storage. IBM Services also built and supported a disaster recovery environment.

reported migration time
Under 4 weeks
reported disaster recovery cost reduction
30%
reported recovery-time reduction
75%
key-system restart time
60 to under 10 min

What worked

System replication moved the SAP environment while training helped the internal engineers take over the new platform. Recovery was designed as part of the project instead of a later promise.

What was hard

This was more than a server replacement. SAP, storage, private cloud management, financing, staff training, and disaster recovery all moved together.

What the next owner can use

A migration is stronger when the recovery system is one of the deliverables, not a note at the bottom of the project plan.

6
Real migration story

HP-UX to IBM Power: Jebsen & Jessen traded seven servers for three

IBM's published account says the project doubled performance and reduced total cost of ownership.

Where it started

Jebsen & Jessen SEA needed to move a business-critical SAP environment to a new database while reducing physical server sprawl and total cost.

What changed

The company replaced seven HP-UX servers with three IBM System p5 servers running AIX and moved SAP ERP to IBM Db2.

physical servers
7 to 3
reported performance
2x
reported TCO reduction
20%

What worked

The change joined platform consolidation with the database move. Fewer servers mattered because the application and database were redesigned around the new environment.

What was hard

This older story uses IBM System p5 rather than Power7 or a current model. Its value is the migration pattern: an HP-UX move changed the database and server estate together.

What the next owner can use

Cross-platform migrations create more work, but they can remove more of the old environment when the database and hardware decision are made together.

7
Real migration story

Power5 failure to Power9 recovery: The backup existed, but the recovery had not been tested

The business returned in just over 36 hours. The delay came from a recovery process that was not fully automated or tested and from the backup specialist being unavailable when needed.

Where it started

GCI lost an old stand-alone Power5 system running OS/400 V5R3. The company had extended hardware support and off-site backups, but the failing server could not simply be repaired.

What changed

The recovery team rebuilt the logical partition in a hosted Power9 environment running IBM i 7.4.

reported time from failure to recovery
36+ hours
generation move
Power5 to Power9
operating-system move
V5R3 to 7.4

What worked

The off-site data existed, a hosted Power9 target was available, and experienced people were able to bridge an unusually large operating-system jump.

What was hard

The recovery plan had never proved that the data could be retrieved and restored during an actual outage. A required technician was not immediately available during the holiday weekend.

What the next owner can use

A backup is not a recovery until someone has restored it on the equipment and schedule the business will actually have during a failure.

Outcome figures are attributed to the named organization, IBM case study, IBM community account, or trade publication. Power7.AS400System.com did not independently measure them.