Informatica PowerCenter to IDMC or dbt
Cohash moves PowerCenter estates to Informatica IDMC Cloud Data Integration, to dbt running inside the warehouse, or to a mix of both. We export the repository, sort every mapping and workflow into convert, rebuild or retire, and run old and new pipelines side by side until outputs match row for row. The scheduler, parameter files and shell scripts around PowerCenter move too, so nothing depends on the old servers.
- 01Repository export and usage
- 02Decide per mapping
- 03Convert and rebuild
- 04Runtime and connectivity
- 05Parallel run
- 06Scheduler cut-over and shutdown
The story
Told without the client's name or anything that could identify them.
A health plan's data engineering group still ran a large PowerCenter estate on servers with an old OS, even though its warehouse had already moved to the cloud. Nobody could say which mappings still fed a report, and the licence renewal was coming up. We exported the repository, joined it with run history and retired what never ran before estimating anything. Every remaining mapping got one decision: IDMC for multi-source mappings, dbt for reshaping data already in the warehouse. Old and new pipelines ran side by side until row counts and checksums matched, then the scheduler moved and the PowerCenter servers were turned off.
why it was urgentInformatica has belonged to Salesforce since 18 November 2025. It runs a modernization program from PowerCenter to IDMC and also sells PowerCenter Cloud Edition. On the dbt side, v2 went generally available on 16 September 2026. End-of-support for PowerCenter depends on the version, and we look yours up in Informatica's support portal before planning.
- openThe PowerCenter servers run an old OS, and the upgrade path keeps getting deferred.
- recurringSnowflake, Databricks or Fabric is the target, but data still comes in through an on-premises ETL tier.
- blockedThousands of mappings exist, and nobody can say which ones still feed a report.
- openRenewal talks have started, and the team wants a real IDMC-versus-dbt comparison first.
The estate, before and after
Before: an on-premises PowerCenter tier in front of a cloud warehouse
Everything bound for the cloud warehouse went through PowerCenter servers on an old OS. The workflows were started and fed by cron, an enterprise scheduler and shell scripts nobody had put in the repository.
Read the diagram as text
- On-premises databases → PowerCenter servers: extract
- Flat files → Shell scripts: file renames
- Shell scripts → PowerCenter servers: trigger files
- Cron and enterprise scheduler → PowerCenter servers: pmcmd
- PowerCenter servers → Cloud warehouse: load
- Cloud warehouse → Reports: queries
After: IDMC and dbt split the work, one orchestrator runs it
We run multi-source mappings in IDMC Cloud Data Integration, through Secure Agents placed near the on-premises sources. Transformations inside the warehouse are dbt models. A single orchestrator schedules both.
Read the diagram as text
- On-premises databases → IDMC Secure Agent: extract
- IDMC Cloud Data Integration → IDMC Secure Agent: mapping tasks
- IDMC Secure Agent → Cloud warehouse: load
- File and SaaS sources → Warehouse loaders: ingest
- Warehouse loaders → Cloud warehouse: load
- Orchestrator → IDMC Cloud Data Integration: schedule
- Orchestrator → dbt models: schedule
- Cloud warehouse → dbt models: transform
- dbt models → Reports: models
How we run it, phase by phase.
6 phases take you from Informatica PowerCenter (self-managed) to Informatica IDMC or dbt on the warehouse. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Repository export and usage
Export mappings, mapplets, sessions, workflows and parameter files, and join them with run history to see what actually runs. Unused objects are retired before anyone estimates conversion.
- phase 02
Decide per mapping
If a mapping reads many sources and pushes to many targets, IDMC with Informatica's migration tooling is often the right home. If it only reshapes data already in the warehouse, it usually becomes a dbt model. We record one decision per mapping, with the reason next to it.
- phase 03
Convert and rebuild
Converted IDMC mappings get fixed and retested in the cloud designer. The dbt rebuilds are SQL models with tests, sources and docs, and they go through pull requests like anything else in the repo.
- phase 04
Runtime and connectivity
Place IDMC Secure Agents near on-premises sources, set firewall rules and secrets in a vault, and move ingestion that doesn't need Informatica to the warehouse's own loaders.
- phase 05
Parallel run
We run old and new pipelines side by side on the same inputs and compare each target table's row counts, checksums and key aggregates. A table only moves on when they match.
- phase 06
Scheduler cut-over and shutdown
Move pmcmd calls, cron jobs and enterprise scheduler dependencies to the new orchestrator, switch targets in batches, then archive the repository and turn off the servers.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every mapping has one decision and a reason
We marked each mapping, mapplet, session and workflow as convert, rebuild or retire, using run history and a read of what the mapping really does.
- result 02
Warehouse logic lives in a dbt project
We rebuilt the reshaping-only mappings as dbt SQL models, each with tests, sources and documentation, and they're reviewed in pull requests.
- result 03
Outputs proven to match before switching
During the parallel run we compared row counts, checksums and key aggregates per target table. Targets moved in batches, and only once they matched.
- result 04
Nothing depends on the PowerCenter servers
We moved the pmcmd calls, cron jobs and scheduler dependencies to the new orchestrator, archived the repository, and switched the PowerCenter servers off.
Risks we plan for
-
Logic with no SQL equivalent
Java transformations, stored procedure calls, dynamic lookup caches and update strategies with complex conditions need redesigning if they move to dbt. A line-by-line translation won't work.
-
Hidden dependencies
The repository export won't show you the shell scripts that rename files, wait on triggers or call pmcmd. We find those by reading server crontabs and scheduler definitions.
-
Paying twice
PowerCenter and the new platform overlap during the parallel run. The order of batches should follow licence and server end dates, not only technical convenience.
-
Roadmap under a new owner
Salesforce plans to tie Informatica into Agentforce and Data 360, and packaging may shift as that happens. Write the contract and the architecture so you aren't locked in without a reason.
Where AI helps, and where it needs guardrails
Informatica's modernization program advertises AI-powered migration automation, and Salesforce plans to tie Informatica into Agentforce and Data 360. On our side, an LLM reads exported mapping XML and writes a plain-English spec plus a draft dbt model for each mapping. An engineer reviews it, and the parallel-run diff decides whether it ships. Agents work from exported metadata, not production credentials.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Mapping and workflow inventory with run history and a decision per object
yours to keep - tests02
Converted IDMC assets or dbt project with tests and documentation
yours to keep - report03
Parallel-run comparison report per target table
yours to keep - plan04
Scheduler and dependency map, with the new orchestration configuration
yours to keep - plan05
Decommission plan for PowerCenter servers and repository
yours to keep
Platforms and services on this move
Services involved
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01IDMC or dbt?
Often both. IDMC fits integration work: many sources, many targets, CDC and data quality rules. dbt fits transformations that run inside Snowflake, Databricks or Fabric. The split depends on what your mappings actually do, which the inventory shows.
02Can the conversion be automated?
Partly. Informatica's tooling and LLM-drafted dbt models handle routine mappings. Complex transformations and the scripts around PowerCenter still need engineers, and every converted pipeline is proven in a parallel run.
03Is PowerCenter going out of support?
It depends on your version. Informatica publishes end-of-support dates per version in its support portal. We look yours up before setting the timeline.
04Do you also handle data quality and MDM?
Yes. If Informatica Data Quality or MDM rules sit alongside PowerCenter, we inventory them in the same pass and decide where each rule should live.
Often on the same roadmap
AD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAI pilot to production with forward deployed engineers
Taking an AI pilot into production with forward deployed engineers who work with the business team, build evals, connect real systems and hand over cleanly.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case study25c5d923 - 01Salesforce: Salesforce completes acquisition of Informatica (18 Nov 2025)salesforce.com ↗
- 02Informatica: PowerCenter to Cloud Modernizationinformatica.com ↗
- 03dbt docs blog: dbt v2 is GA (16 Sep 2026)docs.getdbt.com ↗
- 04dbt Labs: licensing FAQgetdbt.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it