IBM Power Migration Timeline: How Long It Actually Takes
How long does an IBM Power migration take, end to end?
A lift-and-shift of AIX or IBM i to cloud Power typically runs 3 to 6 months from decision to cutover, in four phases: discovery and assessment (weeks 1 to 4), design and pilot (weeks 4 to 10), migrate and validate (weeks 10 to 22), and optimize and close (weeks 22 to 26). An IBM i modernization or an AIX-to-Linux replatform is a different animal at 9 to 18 months or more, because application recompile, remediation, and regression testing set the pace instead of infrastructure. The single most common cause of a slipped date is not technical: it is testing sign-off that nobody was assigned to own.
At a glance
Key takeaways
Lift-and-shift: 3 to 6 months
Moving AIX or IBM i LPARs to PowerVS or a managed Power host keeps the operating system and applications intact. Most of the calendar goes to inventory, a pilot LPAR, wave migrations, and testing, not to engineering.
Modernization: 9 to 18 months or more
Rewriting interfaces, replatforming AIX to Linux, or restructuring an IBM i application adds a long application track on top of the infrastructure work. That track, not the migration, sets the end date.
Testing sign-off is the usual pacing item
Standing up the target is fast. Getting application owners to run and formally accept a test cycle is slow. Name the owner and book the windows during discovery, not the week before cutover.
Procurement is the hidden phase
A hardware refresh adds quote, approval, lead time, delivery, and installation before migration work starts. Against an end-of-support deadline, that lead time is often the number that decides the whole strategy.
What Actually Sets the Pace
The instinct is to estimate an IBM Power migration from the size of the infrastructure: how many LPARs, how many terabytes, how much memory. That is the wrong meter. On a lift-and-shift, the infrastructure work is the predictable part. Provisioning a target LPAR on IBM Power Virtual Server or with a managed Power hosting provider takes days, and restoring a mksysb or a SAVSYS is a well-worn procedure with known timings.
What consumes the calendar is everything that requires a human decision: confirming what actually runs on each LPAR, chasing an ISV for license portability confirmation, waiting on a change advisory board, and above all getting application owners to test and sign off. Those items are scheduled around other people’s priorities, and they do not compress just because the infrastructure team is ready.
This is why the same estate can take three months or nine. The variables that move the number are dependency complexity, the number of maintenance windows you can get, license and ISV confirmations, and who owns testing. Size matters far less than most plans assume.
One consequence worth planning around: if your deadline is an end-of-support date rather than a business date, work backwards from it with the procurement and testing time included. Our guides on IBM Power end-of-life dates and Power9 end-of-support options cover which deadlines are real and which have paid extensions available.
The Four Phases of a Cloud Power Migration
Week ranges below describe a typical 3 to 6 month lift-and-shift of AIX or IBM i LPARs to cloud Power. Phases overlap in practice, and a modernization program adds a parallel application track that runs far longer than any of them.
- 1
Discovery and assessment, weeks 1 to 4
LPAR and workload inventory, operating system versions against hardware support dates, software and ISV licensing, RTO and RPO targets, and a shortlist of destinations. This phase produces the dependency map that every later estimate depends on, so under-investing here is what causes surprises in month four. Our IBM i and AIX migration checklists cover what to capture.
- 2
Design and pilot, weeks 4 to 10
Target sizing, network and connectivity design, a pilot LPAR migration, the backup and DR approach, and written go/no-go criteria. The pilot is the point of this phase: it converts assumptions about restore times, performance, and integration behavior into measured numbers you can plan the remaining waves against.
- 3
Migrate and validate, weeks 10 to 22
Non-production moves first, then production LPARs in waves, with performance and integration validation at each gate before the next wave starts. This is the longest phase and the one most sensitive to how many maintenance windows the business will grant. Dual-running costs land here too, and they are real money.
- 4
Optimize and close, weeks 22 to 26
Right-size capacity now that real load is visible, confirm and test HA and DR on the new platform, update runbooks, train the team, and decommission the old hardware. Projects that skip this phase keep paying for over-provisioned cloud capacity and for a data center footprint that nobody switched off.
Timeline by Migration Type
Durations are directional planning ranges drawn from common IBM Power migration patterns, not quotes. Scope your own estate before committing to a date.
| Option | Typical duration | What paces it | Biggest schedule risk |
|---|---|---|---|
| AIX or IBM i lift-and-shift to cloud Power | 3 to 6 months from decision to cutover | Testing sign-off and the number of maintenance windows available | Dependencies discovered late, after the wave plan is already committed |
| IBM i modernization in place (UI, APIs, database access) | 9 to 18 months or more, usually incremental | Application change and regression testing per component | Scope creep, as a modernization becomes an unplanned rewrite |
| AIX to Linux replatform | 9 to 18 months or more | Recompile, remediation, and per-application test cycles | ISV support on the target platform, confirmed too late to change course |
| On-premises hardware refresh (Power10 or Power11) | 3 to 6 months, plus procurement lead time before it starts | Capital approval, quoting, delivery, and installation | Procurement lead time colliding with a fixed end-of-support date |
| Disaster recovery only (DRaaS or replicated standby) | 6 to 12 weeks to a first tested failover | Agreeing RPO and RTO, then proving them in a real test | A DR environment that is built but never actually tested |
The pattern worth noticing: every row is paced by a decision or a test, not by a data transfer. That is also why the migration type you choose matters more to the calendar than the size of the estate. Our comparison of migrating versus modernizing covers how to make that call, and what drives the cost of a Power migration covers what each path does to the budget.
Single Cutover or Waves?
The same estate can be migrated in one window or across several. The choice sets both the calendar and the risk profile. Two representative shapes, drawn from common patterns rather than named engagements.
Best fit
Single cutover: roughly three months
A handful of AIX or IBM i LPARs, clean and well-understood dependencies, and one maintenance window the business will grant. A single-wave lift-and-shift with a full test cycle before cutover. Testing sign-off, not infrastructure, sets the pace, and the whole program can land in about three months.
Best fit
Phased waves: closer to six months
Dozens of systems with tangled interdependencies and tight change control. Waves across several maintenance windows, decommissioning old hardware as each wave proves out. Longer end to end, but risk is spread across waves instead of concentrated in one high-stakes weekend.
Key decision
The question that decides it
How much simultaneous change can the business absorb, and how many windows will it actually grant? If the answer is one window a quarter, you have a wave plan whether you wanted one or not. Settle this in discovery, because it drives the dual-running budget.
What Stretches a Timeline
Use caution
A generic template instead of your dependencies
A partner who quotes the same phase plan for every customer has not looked at your estate. The dependency map from discovery is what makes a date credible. Without it, the schedule is a hope with week numbers attached.
Use caution
Unowned testing sign-off
The most common cause of slipped Power migration dates is not technical. Nobody was assigned to schedule, run, and accept the application test cycle. Name that person in phase one and book their windows in the plan.
Use caution
Licensing confirmed too late
IBM entitlement transfer and ISV license portability need confirming during discovery, not during cutover week. A single ISV that will not license the target platform can invalidate the destination and restart the clock.
Use caution
No decommissioning plan or budget
Dual running is a real line item: maintenance, power, floor space, and sometimes software licensing on two environments at once. If nobody owns the decommissioning date, the old hardware stays powered on for months after cutover.
Before You Commit to a Date
A lift-and-shift to cloud Power runs 3 to 6 months. These five questions are what move that number inside the range, or push it outside it. Answer them before a date goes into a board pack.
- 1
How many LPARs and applications are in scope, and what depends on what?
Dependency complexity, not raw size, is the variable that decides where inside the range you land.
- 2
Is this a single cutover, or waves across several windows?
Ask the business how many maintenance windows it will actually grant, then build the plan around the answer rather than around the ideal.
- 3
Are license portability and network connectivity confirmed?
IBM entitlements, ISV terms, and the connectivity design belong in phase one. Each one is capable of invalidating a destination on its own.
- 4
Who owns testing sign-off?
Name the person, not the department, and put their test windows in the schedule. This is usually the real pacing item on the whole program.
- 5
When does the old hardware get decommissioned, and who pays until then?
Set the date and the owner in the plan. Dual running is a budget line, and it grows quietly when nobody owns the switch-off.
Frequently Asked Questions
How long does an IBM Power cloud migration take?
A lift-and-shift of AIX or IBM i LPARs to cloud Power, whether that is IBM Power Virtual Server or a managed hosting provider, typically runs 3 to 6 months from decision to cutover. Small, clean estates with a single maintenance window can land closer to three months. Large estates with tangled interdependencies and tight change control run to six months or beyond. These are directional ranges for planning, not a quote.
Why do modernization projects take so much longer?
Because application work, not infrastructure, sets the pace. A lift-and-shift keeps the operating system and applications intact, so the schedule is dominated by data transfer, testing, and cutover. An IBM i modernization or an AIX-to-Linux replatform adds recompile, remediation, and regression test cycles per application, which is what stretches those programs to 9 to 18 months or more.
What is usually the real pacing item?
Testing sign-off, and it is almost always owned by the business rather than by IT. Infrastructure teams can stand up a target LPAR in days. Getting application owners to schedule, run, and formally accept a full test cycle is what consumes calendar time. Projects that name a testing owner and book the windows in phase one finish on schedule far more often than projects that leave it implied.
Can I migrate IBM Power workloads in waves?
Yes, and most estates of any size do. You move non-production first, then production LPARs in waves, validating performance and integrations at each gate before starting the next wave. Waves spread risk across several maintenance windows instead of concentrating it in one high-stakes weekend. The trade-off is a longer overall calendar and a period of dual running, which has to be budgeted.
When can the old hardware be decommissioned?
In the final phase, after capacity is right-sized on the new platform, HA and DR are confirmed and tested, runbooks are updated, and the team is trained. Decommissioning too early removes your rollback path. Leaving it too late means paying for maintenance, power, floor space, and in some cases software licensing on two environments at once. Both the date and the owner belong in the plan, not in an assumption.
Does a hardware refresh take less time than a cloud migration?
The project work is comparable, but the procurement clock is different. A Power10 or Power11 purchase adds quoting, approval, lead time, delivery, and installation before migration work can even start, and capital approval cycles are frequently the longest single item. A cloud target can usually be provisioned in days. If your deadline is driven by an end-of-support date, that procurement lead time is the number to check first.
Sources
- Durations on this page are directional planning ranges reflecting common IBM Power migration patterns, not specific client engagements or quotes.
- Confirm hardware and operating system support dates against IBM's own lifecycle pages before working backwards from a deadline.
- Confirm license portability and target-platform support with IBM and each ISV in your estate during discovery.
Related pages
- IBM i Cloud Migration Checklist
- AIX Cloud Migration Checklist
- What Drives the Cost of an IBM Power Cloud Migration
- Migrate vs. Modernize: Which Path Fits
- Power Hardware Refresh vs. Moving to Cloud
- IBM Power End of Life Dates: Every Server, IBM i, and AIX Release
- Linux on Power: Cloud Options Compared
- IBM Power Disaster Recovery: Options and Planning
Need a Timeline Sized to Your Estate?
We sequence a Power migration into phases and gates built from your dependencies, not from a template, and tell you where the date is likely to slip.