IPU pricing: why Informatica lands 40-60% over budget

Informatica prices its cloud platform in Intelligent Processing Units, a single synthetic meter that spans ingestion, transformation, API calls, data quality and cataloguing across the whole suite. Because the vendor publishes no public list prices and the unit aggregates work your engineers do not directly provision, most teams cannot forecast it: documented consumption bills run 40-60% over their initial projections. The March 2026 PowerCenter end-of-support deadline is now herding on-prem users onto that meter before anyone has modelled it.

What is an IPU, and why is it hard to forecast?

An IPU is a normalised credit. The same unit is drawn down by a mapping run, an API invocation, a data-quality rule, a change-data-capture stream and a cataloguing job, each at a different conversion rate that depends on the service and the compute tier. You are not billed for something you sized and provisioned; you are billed for an abstraction that moves with data volume, job frequency and how many features your teams adopt.

Two properties make the forecast fragile. First, price discovery is deliberately weak:

Informatica does not publish public list prices.

So buyers anchor on a sales-quoted annual pool of IPUs and a discount they have no way to benchmark. Almost the only visible reference point sits on AWS Marketplace, where a 120-IPU-per-month plan is listed at $129,600 per year (as of August 2025). Second, consumption is elastic in exactly the wrong direction: every new pipeline, every retry storm, every extra non-production environment pulls from the same pool. Adoption success and cost overrun become the same event.

Where does the 40-60% overrun actually come from?

Not from a single line item; it accumulates. A migration re-expresses hundreds of PowerCenter mappings as cloud tasks, and the cloud runtime meters differently than a processor you owned outright, so a workload that was effectively free at the margin on-prem now draws IPUs every time it runs. The usual accumulators:

• Re-platform metering: logic that carried zero marginal cost on owned hardware now draws IPUs on every execution.
• Environment multiplication: dev, test, UAT and a DR copy each meter the same pipelines again.
• Retry and reprocessing: failed loads and backfills consume the pool with nothing to show for it.
• Feature adoption: data quality, cataloguing and API management are separate draws, not a bundle.

The migration itself is where the number first surfaces. One documented IDMC programme saw a $250k plan turn into $460k, and realistic timelines land at 6 to 18 months against a vendor-quoted 3 to 6. That is not the accident of one bad project; it is the predictable result of quoting a re-platforming as if it were a lift-and-shift, then discovering that mappings, parameter files and reusable transformations all have to be re-authored and re-tested before a single IPU of production value is delivered.

What does the PowerCenter deadline force?

PowerCenter 10.5.x support ends on 31 March 2026, which removes the comfortable option of doing nothing. The on-prem model was expensive but legible: reviewers cite $100,000 to $300,000 per processor annually plus 18-22% maintenance (as of August 2025), a large number, but one tied to hardware you could count and a bill that did not move when a pipeline got chattier. The consumption model trades that legibility for elasticity, and the deadline means most buyers make the trade under time pressure rather than after a proper baseline.

Why is this a governance problem, not a pricing problem?

Consumption pricing is not wrong in principle; plenty of infrastructure is billed that way and forecast fine. It fails here because the meter sits at the wrong altitude. The IPU abstracts spend away from the engineer who creates it: the person adding a pipeline sees a ticket, not a running total, so there is no natural backpressure between the act that costs money and the budget that pays for it. Finance is handed a monthly figure it cannot decompose into controllable levers, which is the same structural trap as the full integration bill for a mid-size brewer: real money, no line-item ownership.

It compounds when the platform itself keeps moving. Consumption rates and packaged features change on the vendor's cadence, not yours, the same dynamic behind when a platform's modules move faster than the team maintaining them. And the specialists who can actually tune IPU consumption are scarce and expensive, so the migration you under-quoted also leans on a thin partner ecosystem at exactly the moment you need surge capacity.

The direction of the fix is unglamorous: baseline your real consumption before you sign, meter it yourself, and keep the cost driver visible to the people who move it. When we run integration on a single event bus we instrument ourselves, spend maps to events we can name and cap, which is precisely the property a synthetic credit quietly removes.

None of this makes Informatica a bad tool; it makes it a hard thing to budget. The teams that reach the far side of 2026 without a nasty variance will be the ones treating the PowerCenter deadline as a forecasting project rather than a licensing one, measuring current pipeline behaviour now, while a legible on-prem bill still exists to measure against, so the pool they buy is grounded in observed load instead of a sales estimate they cannot yet challenge.