Informatica implementation cost: IPUs, services and quotes after the Salesforce deal

Informatica is a different kind of Salesforce purchase. Most Salesforce products are priced by the seat, and the implementation cost follows the number of people and processes involved. Informatica is priced by consumption, and the implementation decides how much you consume. A clumsy mapping that reloads ten million rows every night costs more to run than a careful one that moves only what changed, every day, for as long as you own it. That makes design quality a licence question as much as a services one.

Salesforce completed the acquisition on 18 November 2025. Its announcement summarised what came across: "The close of the acquisition brings Informatica’s rich data catalog, integration, governance, quality and privacy, metadata management, and Master Data Management (MDM) services to the Salesforce platform." This guide covers how that is priced today, what an implementation with Salesforce is made of, and what to ask before you sign.

#What you pay for Informatica

Informatica Intelligent Data Management Cloud, usually shortened to IDMC, is sold on Informatica Processing Units. Informatica describes the model this way: "The IPU is a flexible, scalable and transparent consumption-based pricing model that enables you to pre-pay for usage on an annual basis and access the supported services, connectors and processing engines within IDMC in the same way." In practice you commit to a block of IPUs for the year and draw them down across whichever cloud services you use: data integration, data quality, master data management, the data catalogue and governance tools.

There is no public rate card. As at October 2026, the Informatica pricing page describes the approach rather than the numbers: "Informatica consumption pricing enables you to pay for what you need now and scale for the future." It offers a "get quote" path and a sample price range based on your use case, and it lists a free Cloud Data Integration offer you can use to test before committing. Salesforce's own Informatica pages describe capabilities, not prices. So treat Informatica as quote-only, in US dollars or your contract currency, and expect the quote to turn on these inputs:

The pricing page also notes that administrators can watch usage on a dashboard and set consumption threshold alerts. Use them from day one. An IPU pool that runs out in month nine is a budget conversation you do not want to have halfway through a programme.

#Why the design decides the run cost

Because the meter runs on usage, three design choices matter more on Informatica than on most Salesforce projects.

Full versus incremental loads. The quickest way to build a Salesforce integration is to reload everything every night. It is also the most expensive way to run one on a consumption model. Incremental loads, keyed on SystemModstamp or a change data capture feed, take longer to build and test, but they move a fraction of the rows each day. Ask your partner which jobs are full reloads and why.

Schedules. Business users often ask for data "in real time" when hourly or daily would do. Every increase in frequency is a recurring IPU cost. Agree the freshness each consumer genuinely needs, and write it into the design.

Profiling and scanning. Data quality profiling and catalogue scans are valuable at the start and in moderation afterwards. Left on a tight schedule across every source, they quietly become a large share of consumption.

None of this means a cheap design is a good one. It means the implementation quote and the IPU quote are linked, and the person designing the jobs should be able to tell you roughly what each one will cost to run.

#A worked example: how scope turns into effort and IPUs

Take a hypothetical distributor with Sales Cloud, an ERP that holds customer accounts and invoices, a separate billing platform, and a marketing list that lives in spreadsheets. The business wants one trusted customer record in Salesforce and clean data flowing into Data 360 for segmentation.

Discovery finds four sources for the customer entity, each with its own idea of an address. The integration work is three mappings into Salesforce (accounts, contacts, invoice summaries) and one into Data 360. Each mapping can be built as a nightly full reload or as an incremental feed. The incremental version takes longer to build, because it needs reliable change markers in the ERP, but it moves a small slice of the rows each night instead of all of them.

The data quality work is address standardisation, email and phone validation, and a handful of rules for company names. The master data work is where the hours go: match rules for companies that trade under several names, survivorship rules for which source owns the billing address, and a stewardship queue for the matches that fall below the confidence threshold. Someone in finance and someone in sales operations must agree those rules, and the build waits for them.

Run cost follows the same choices. Four incremental nightly jobs, a weekly profile and a stewardship queue worked by one person is a modest, predictable draw on the IPU pool. Four full reloads every hour, daily profiling of every source and a catalogue scan of systems nobody asked about is a very different bill, for the same business outcome. The services quote for the first design will be higher. The total cost of ownership will usually be lower.

#What an Informatica and Salesforce implementation is made of

Informatica projects with Salesforce tend to take one or more of four shapes: moving data into or out of Salesforce, cleaning it, mastering it, and governing it. Each has its own work packages.

Master data management deserves a warning of its own. Building the match rules is technical work. Deciding which source wins when the CRM, the ERP and the billing system disagree about a customer's address is a business decision, and it often takes longer than the build. If nobody in the business has the authority to make those calls, the project stalls, and the services quote grows while it waits.

#Where Informatica, MuleSoft and Data 360 meet

Salesforce now owns three products that move and shape data, and its own announcement says MuleSoft combined with Informatica will "create a comprehensive, end-to-end integration offering." That is a sensible direction, but it creates a scoping trap for buyers right now.

As a working rule, MuleSoft is built for APIs and events between applications: a quote created in Salesforce triggering an order in the ERP. Informatica is built for bulk data integration, quality, mastering and governance: reconciling five customer lists into one trusted record. Data 360 is where Salesforce unifies profiles and activates them across marketing, service and agents. The name is recent: "As of October 14, 2025, Data Cloud has been rebranded to Data 360."

The trap is overlap. If MuleSoft, Informatica and Data 360 all claim identity resolution or all load the same Account data, you pay three times: three meters drawing down, three teams building, three places to debug. Before you ask anyone for a quote, draw the boundary. Which product owns each flow? Which product owns the match rules for a person or a company? Partners will price what you ask for, so ask for one owner per job. For a fuller view of how Informatica now feeds Data 360, read Informatica and Data 360.

#What changes now Informatica is part of Salesforce

For existing Informatica customers, the immediate answer is less than the headlines suggest. Salesforce has said: "Informatica will also continue to support and integrate its AI-powered data management solution with its broad ecosystem of partners." Your non-Salesforce sources and targets remain in scope, and your existing IPU contract runs to its term.

The questions worth asking at renewal are commercial. Will the renewal be written by Informatica or by your Salesforce account team? Can it be co-termed with your Salesforce contract so the two meters are reviewed together? Are there bundles that combine Informatica with Data 360 or MuleSoft, and if so, how does the price compare with buying each on its own? Nobody should assume a bundle is cheaper until the line items are on the table.

#Getting quotes you can compare

You will usually have two quotes: the IPU commitment from Informatica or Salesforce, and the services from a partner. They need to be read together.

Ask the licence side for the IPU block size, the unit price at that tier, what happens when you exceed it, whether unused IPUs carry over, and whether non-production work draws from the same pool. Ask for a usage estimate built from your own volumes and schedules, not a generic sizing.

Ask the services side for the job list, with each job marked as full or incremental, its schedule, and an estimate of its IPU draw. Ask how many match rules and survivorship rules the MDM design assumes, who in your business signs them off, and how many stewardship exceptions per week the design expects. Ask what reconciliation the cutover includes: row counts are the minimum, field-level checks on a sample are better.

If one quote is much lower than another, check the job list first. The cheapest services quote is often the one that builds full reloads, and you pay the difference every month in IPUs.

A short paid pilot is often the best way to make both quotes honest. Pick one representative flow, such as accounts from the ERP into Salesforce, build it properly with incremental loads and the quality rules you expect to keep, and run it for a few weeks at production volume. You come out with a measured IPU draw for a real job, a feel for how your partner works, and a list of the data problems that will shape the rest of the programme. That evidence is worth more in a licence negotiation than any sizing spreadsheet, and it stops the services quote from resting on guesses about how clean your sources are.

#Costs that sit outside the first quote

1. Secure Agent hosting. The runtime that processes data near your sources runs on servers or cloud machines you provide, patch and monitor.
2. IPU growth. New sources, higher frequencies and extra profiling all increase consumption. Plan a review at the halfway point of each contract year.
3. Data 360 credits. Data you feed into Data 360 is then processed under Data 360's own consumption model, which is a separate meter and a separate budget.
4. MuleSoft capacity. If MuleSoft still carries some flows, its subscription continues alongside Informatica.
5. Stewardship staff. Someone has to resolve the matches the rules cannot. That is ongoing headcount, not a project cost.
6. PowerCenter overlap. If you are modernising from on-premises PowerCenter, both may run in parallel for a period. Budget for the overlap and the regression testing.
7. Governance time. A catalogue nobody curates goes stale quickly. Glossary and policy ownership is a recurring commitment.
8. Change for data owners. New match rules change which address, phone number or account owner people see. Sales and service teams need to hear why before go-live, or they will fix the "wrong" data by hand and undo the work.

#Where to go next

For the history of the deal, read what happened to Informatica. The licence side, including how IPU blocks are structured, is covered in Informatica licence cost. For the connection patterns between the two platforms, see integrating Informatica with Salesforce, and if you are weighing a move away from an existing Informatica estate, should I migrate from Informatica sets out the trade-offs. When you are ready to compare implementation partners, hiring an Informatica Salesforce partner lists the questions worth asking.

The point to carry into every conversation: on Informatica, the implementation design is the run cost. Ask for both numbers together.