How LPARs and Business Units Multiply IBM i Implementation Cost
Why each LPAR or business unit in scope raises both IBM i licensing and implementation labor, with four shop scenarios and how to keep the multiplier under control.
Every LPAR or business unit in scope multiplies cost twice. Once on the license side, because IBM i is licensed on the processor capacity your partitions use at the system's software tier, and many third-party products are priced by tier, partition, or serial number. And once on the labor side, because each partition and each business unit has to be configured, connected, and tested. The good news is that neither multiplier is fixed.
The licensing side moves faster than most people expect. In the published configuration pricing on our IBM i Tier Economics page, the same Power S1122 hardware carries $84,698 in IBM i software for one partition with unlimited users and $176,141 for four partitions. The hardware price didn't change. The software bill more than doubled.
Labor works differently. It doesn't scale with the number of partitions or business units so much as with how different they are from each other. That's the part you have the most control over.
Find your situation
Small shop
Adding a development and test partition
Users
About 30
Footprint
1 production LPAR today
Plan
Add a test LPAR
Trigger
The project needs a safe place to test
Sound familiar?
The partner recommends a separate test partition for the implementation, which makes sense, right up until someone asks whether it doubles the IBM i bill. Nobody in the room is sure, and it's exactly the kind of question that stalls a project for a month.
What's really driving the number
A partition that needs its own processor capacity needs that capacity licensed, so a test LPAR isn't free. It also isn't automatically a second production system. The cost depends on how much processor capacity testing actually needs, how your third-party software licenses non-production use, and how long you need the partition at all.
What takes the pressure off
Ask your business partner to price the test partition at the processor capacity testing actually needs, not as a mirror of production.
Check each third-party contract for development, test, or non-production license terms before assuming full price.
Decide whether the test environment is permanent or only for the implementation window, and price both options.
If a separate partition isn't justified, ask what a controlled set of test libraries would cost instead, and be clear-eyed about the risk of testing on the production system.
If this is you
Don't assume a test partition doubles anything. Get what non-production capacity actually costs for your configuration, in writing, before the question stalls the decision.
Mid-market
Production plus a high availability target system
Users
About 150
Footprint
Production plus HA target
HA option
PowerHA or logical replication
Trigger
Audit or insurance requirement
Sound familiar?
An auditor or insurer wants a real recovery plan, and the first HA quote looks like buying a second system's worth of software. It's hard to justify paying full price for a box that's supposed to sit and wait.
What's really driving the number
Two costs are getting blended together. One is licensing on the target system, which depends on how that system is configured and which HA product you choose. The other is implementation labor: setting up replication, then testing role swaps until everyone trusts the switch. This site's benchmarks put PowerHA implementation at roughly $5,000-$20,000 for SMB and $50,000+ for enterprise, before the licensing question even comes up.
What takes the pressure off
Ask your IBM business partner whether the target qualifies for a Capacity BackUp (CBU) configuration, which IBM offers for Power systems used as standby capacity. Eligibility and IBM i license terms vary by model and generation, so get the answer for your exact configuration in writing.
Compare PowerHA and third-party logical replication on total cost, including target-side licensing, not just product price.
Put role-swap tests inside the implementation plan, not after it. An HA setup nobody has switched over is a plan, not protection.
If this is you
A standby system shouldn't be priced like a second production system if it's set up as a standby. Make sure the quote knows the difference.
Multi-company
Three business units on one IBM i, each with its own habits
Business units
3
Users
About 250 total
Footprint
1 shared system
Trigger
Consolidating to one ERP
Sound familiar?
The implementation came back looking like three projects stapled together. Each business unit's leadership insists its processes are different, and the budget can't absorb three of everything.
What's really driving the number
Business units don't multiply labor by their count. They multiply it by their differences. If three companies run the same order-to-cash process under different company numbers, units two and three are mostly configuration copies. If each one prices, costs inventory, and ships differently, the partner is designing three systems and has to quote it that way.
What takes the pressure off
Design one common template first, one set of processes for everyone, and document each unit's variations as exceptions that have to justify themselves.
Decide early whether the units run as multiple companies in one environment or as separate environments, since licensing and labor differ between the two.
Roll out in waves, starting with the unit closest to the template, and quote each later unit as a delta from it.
Ask the partner to show which parts of the quote are shared build and which are unit-specific, so every exception has a visible price.
If this is you
Three business units don't cost three times as much. Three different ways of doing the same job do, and that part is a decision you get to make.
Enterprise
LPAR sprawl left over from acquisitions
Partitions
6 and counting
Origin
Each acquisition kept its own
Utilization
Uneven
Trigger
Company-wide implementation
Sound familiar?
Every acquisition brought its own partition, and nobody ever merged them. Now the implementation scope includes all six, and the estimate treats each one as its own configuration, its own test cycle, and its own license bill.
What's really driving the number
Each partition carries its own licensing, setup, and testing, even when several of them run light workloads. On the licensing side, consolidating onto fewer, larger partitions can cut total cost even at a higher tier. The part people miss is timing. An implementation is already paying to test everything, which makes it the cheapest moment you'll get to consolidate.
What takes the pressure off
Inventory what each partition actually runs, and how busy it is, before the scope is final.
Model licensing both ways, current partitions versus a consolidated layout, including any tier change.
Fold consolidation into the implementation's test cycles instead of running it as a separate project later.
Keep a partition separate only where there's a real reason for it, like security or regulatory isolation.
If this is you
If you're testing everything anyway, the biggest cost of consolidating is already in the budget. This is the project to do it in.
These scenarios are composites built from common IBM i project patterns and the published figures on this site, not individual client case studies. Licensing terms vary by model, tier, and contract, so confirm every licensing assumption for your exact configuration before budgeting against it.
Questions to ask before you sign
How many partitions and business units does this quote assume, and what changes if we remove one?
What processor capacity is licensed on each partition, and at what tier?
Which third-party products are priced per partition, per tier, or per serial number?
Does any standby or test capacity qualify for reduced licensing terms?
Which parts of the labor are shared build, and which are repeated per partition or business unit?