You're on Informatica PowerCenter: It Runs Your Long-Lived ETL. Data Workers Keeps What It Loads Right Through the Move to IDMC
PowerCenter runs your nightly workflows while you modernize to IDMC. Data Workers keeps what they load right in production and holds each wave until parity is proven.
Your enterprise has run on PowerCenter for years. Thousands of mappings turn source rows into warehouse rows, sessions run them with the connections and parameter files your administrators tuned, and workflows chain them into the nightly load the finance close and the morning reports depend on. Workflow Monitor shows green, and the repository is your record of how every number is built. Now Informatica, "Informatica from Salesforce" since Nov 18, 2025, is steering PowerCenter customers to its Intelligent Data Management Cloud (IDMC): its PowerCenter page is now "PowerCenter to Cloud Modernization", with Cloud Data Integration for PowerCenter, a PC2CDI Modernization Service that converts mappings, sessions and workflows, and Cloud Data Validation to compare old and new data side by side. PowerCenter 10.5.11 still shipped in August 2026, so most of you run PowerCenter in production while you move it in waves. PowerCenter runs the enterprise's long-lived ETL workflows. Data Workers owns whether what they load is right, in production and through the modernization, behind approvals.
Key takeaways
- •PowerCenter keeps its job, and so does IDMC. Mappings, sessions, workflows and converted taskflows stay with your integration team.
- •Data Workers owns the outcome. It checks what every load lands in Snowflake, traces a wrong number across PowerCenter, IDMC, dbt and BI, and routes one plan to the owners.
- •Every wave ships on proof. Your parity evidence comes from Cloud Data Validation or your own reconciliation. Data Workers plans each wave with its checks, tracks the results every night and holds the completion gate for the wave owner's sign-off.
- •Nothing runs without a named approver. An unanswered request expires and escalates, never auto-grants, and no agent can promote its own work.
- •Autonomy is set per domain, from L0 manual to L4 autonomous.
PowerCenter runs the long-lived workflows. Data Workers owns whether the numbers survive the move.
PowerCenter and IDMC do the moving. Data Workers answers the question every migration lead faces before sign-off: are the numbers the same, and right? Here is a Thursday at a food and beverage distributor in week three of a parallel run, an illustration rather than a customer case. JD Edwards EnterpriseOne holds sales orders and invoices for every operating company. The PowerCenter workflow wf_jde_sales_nightly loads Teradata, where the old reports run. Wave 3 converted it to a Cloud Data Integration taskflow, tf_jde_sales_nightly, that loads Snowflake, where dbt Cloud builds the sales marts and Power BI serves the new reports. Nothing new gets built on Teradata, so a Japan subsidiary live this week reports in Power BI only. Cloud Data Validation test cases passed in September, the parity checks in the wave plan run every night in Cloud Data Validation and the migration team's reconciliation query, and the wave owner is due to sign off Friday. Tickets live in ServiceNow and approvals reach people in Slack.
One detail matters. JD Edwards stores amounts without a decimal point, and each currency's setting in the currency codes table (F0013) says where the point goes: two places for dollars and pesos, none for yen.
| Time | System | What happens |
|---|---|---|
| Wed 08:00 | JD Edwards | Japan company 00700 goes live; the first 1,284 invoice lines post in yen |
| Wed 23:30 | PowerCenter | wf_jde_sales_nightly runs session s_m_jde_sales_detail. The mapping's lookup reads each currency's decimals from F0013, and Teradata EDW.SALES_DETAIL gets ¥186.4M for company 00700. Succeeded |
| Thu 00:40 | IDMC Cloud Data Integration | tf_jde_sales_nightly loads Snowflake SALES.SALES_DETAIL. During the wave 3 rebuild a developer replaced the currency lookup with a fixed divide by 100, which matched every currency in the September test window. Yen lands at ¥1.864M. Succeeded |
| 01:10 | dbt Cloud | The sales_nightly job builds fct_net_sales and fct_sales_by_entity; every test passes |
| 01:30 | Cloud Data Validation and Snowflake | The nightly checks run: the Cloud Data Validation row count and key test case passes (186,240 rows on both sides), and the migration team's per-company net sales reconciliation writes its results to MIGRATION.PARITY_RESULTS. Company 00700 differs, by exactly a factor of 100; every other company matches |
| 01:36 | Data Workers | Reads the reconciliation results in Snowflake, marks the wave 3 net sales check failed for company 00700 and keeps the completion gate closed, with the failing check named |
| 01:42 | Data Workers | diagnose_incident works the evidence: keys match, only the yen company is off, and by a factor of 100. It compares the PowerCenter mapping from a repository export with the converted mapping the migration owner exports from IDMC: lookup on one side, fixed divide on the other. trace_cross_platform_lineage and blast_radius_analysis find two dbt models, the Japan daily sales report in Power BI (refresh at 06:00) and Friday's sign-off at risk; get_incident_history finds no earlier fix |
| 01:50 | ServiceNow and Slack | Data Workers opens a ServiceNow ticket with the diagnosis and sends the approval request to the migration lead in Slack, with the integration owner and the BI owner copied |
| 05:40 | Spellbook | The migration lead reviews one plan: hold the 06:00 refresh; restore the currency lookup in the converted mapping; reload Wednesday for company 00700; rebuild the marts; add a per-currency net amount check to waves 3 to 6; keep the gate closed for three clean nights. She approves |
| 05:45 | Power BI | The BI owner pauses the scheduled refresh |
| 07:30 | IDMC Cloud Data Integration | The integration owner restores the lookup, publishes the mapping and reruns the taskflow for Wednesday's business date, which replaces that day's rows as it does every night |
| 08:05 | dbt Cloud | Data Workers queues the approved sales_nightly job; the marts rebuild and the tests pass |
| 08:20 | Snowflake | The migration team reruns the reconciliation: company 00700 reads ¥186.4M on both sides |
| 08:30 | Data Workers | Verifies: the rerun reconciliation passes for every company, run_quality_check finds volume on SALES.SALES_DETAIL inside baseline, the load-lag metric the team records is back on its baseline, and yen net sales per day becomes a metric the team records with monitor_metrics. It writes the receipt |
| 08:40 | Power BI and ServiceNow | The BI owner refreshes the report; Data Workers updates the ticket summary with the receipt link and the service desk resolves it |
| Mon 10:00 | Spellbook | After three clean nights the migration lead signs off wave 3 and the gate opens; the integration owner schedules the retirement of the PowerCenter workflow |
Everyone did their job. PowerCenter loaded the yen correctly. The converted taskflow succeeded, the September test cases passed because no yen existed yet, and the row count check passed because no row was missing. The only signal was one number in one company. Data Workers had put the per-company check in the wave plan, kept the gate closed when the team's reconciliation failed, found the cause in two mapping definitions and routed each step to its owner. Without that, wave 3 is signed off Friday, the Teradata path is retired, and the yen error becomes the only version of the truth.
| Job | What PowerCenter and IDMC do | What Data Workers does |
|---|---|---|
| Running the loads | PowerCenter workflows and sessions run the nightly ETL; converted taskflows run in Cloud Data Integration | Watches what every load lands in Snowflake and what it does to the models and reports built on it |
| Converting a wave | The PC2CDI Modernization Service converts mappings, sessions and workflows and repoints them to cloud targets | Plans each wave with its dependencies, owners and parity checks, and translates hand-written warehouse SQL into Snowflake |
| Proving parity | Cloud Data Validation and your reconciliation queries compare old and new data; that is the parity evidence | Tracks every result every night and holds the completion gate for the wave owner's sign-off |
| Detecting a break | Workflow Monitor shows status and row counts per session | Catches a wrong number when the session is green, and says which company, currency or column moved |
| Root cause | The repository and IDMC each show one side's mapping | Reads both sides, traces through dbt and BI and names the step that changed |
| The fix | The integration owner edits the mapping and reruns the load | Proposes one plan with each step routed to its owner, queues the dbt Cloud rebuild and verifies the result |
| The record | Session logs and run history in each product | A receipt for every fix and every sign-off: cause, change, approver, checks passed and the undo |
Why doesn't PowerCenter just do this itself?
Because PowerCenter was built to run ETL faithfully, and it does. A mapping does exactly what it says, every night, and a session that moves every row is a success. That is the right design for loading the warehouse on time. Whether the number is right after another team rebuilt the mapping in another product is a question PowerCenter was never asked to answer.
Informatica's answer for the move is strong. Cloud Data Integration for PowerCenter runs PowerCenter workloads without metadata or business logic migration, the PC2CDI Modernization Service converts assets with pattern recognition, and Cloud Data Validation finds missing, unmatched or extra records. Inside IDMC, CLAIRE agents "discover data, build pipelines and proactively fix data quality issues", and through Jan 31, 2027 eligible customers can use CLAIRE copilots and agents at design time at no additional IPU cost. For converting and validating Informatica assets, Informatica is deep.
The Thursday fix needed more. The reports at risk lived in dbt Cloud and Power BI, the ticket in ServiceNow, and the sign-off belonged to a migration lead, not a tool. A data integration vendor that paused another team's BI refresh or declared a wave done would take on liability for systems and decisions it does not own. Acting across them takes blast-radius scoping, a named approver, an undo written first, verification against the business number and a receipt. That is a different product, and it is the product Data Workers is.
There is also focus. Informatica's 2026 direction is trusted data for AI agents across Salesforce's Data 360 and Agentforce, and its modernization offer is about moving to IDMC. Keeping every number right across both warehouses and everything downstream, in every vendor's tools, is the job we chose.
Every tool owns a slice. Data Workers covers the whole lifecycle
PowerCenter goes deepest on moving data, and Informatica's modernization tooling scores well on migration. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | PowerCenter | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | The PowerCenter repository holds every mapping, session and workflow, and that metadata is what modernization tools read. Data Workers joins it to lineage, tests, owners and usage across the estate in one governed graph. |
| Analytics & Insights | 8 | 2 | PowerCenter loads the warehouse that reports read; it does not answer questions. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 5 | Data quality sits in separate Informatica products. Data Workers runs null, uniqueness and volume checks after each load, tracks lateness against a baseline your team records and fixes the cause when one fails. |
| Observability & Incidents | 8.5 | 4 | Workflow Monitor shows each session's status and row counts. Data Workers diagnoses across systems when a session succeeds and the number is still wrong. |
| Pipelines & Ingestion | 8.5 | 9 | PowerCenter's home stage: mappings, sessions and workflows that have run the enterprise's nightly loads for years, with PowerExchange for CDC and mainframe sources. Data Workers watches what each load does downstream and proposes changes for the integration owner. |
| Schema & Migration | 8 | 7 | Informatica's modernization path converts mappings, sessions and workflows to Cloud Data Integration and validates data side by side. Data Workers plans each wave with its parity checks, tracks them and holds the completion gate for the owner's sign-off. |
| Governance & Access | 8.5 | 5 | Repository permissions govern who edits a mapping. Data Workers dry-runs warehouse access requests and proposes time-bound grants for the owner. |
| Security & Privacy | 8 | 5 | Connections and credentials are managed in the domain. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 3 | Licensing and servers are the cost lens, not warehouse spend. Data Workers reads Snowflake spend down to the dbt model and drafts setting changes for their owner. |
| MLOps & Models | 7.5 | 1 | PowerCenter feeds data that models train on but has no model features. Data Workers keeps the data under your models fresh and correct. |
For the governance and quality side of the same vendor, see you're on Informatica and you're on Informatica Data Quality.
How PowerCenter and Data Workers work together
Spellbook Data Catalog (in preview) is where the migration lead and data owners look: every wave's checks and status, each proposed change, its approver and its rollback. Behind it, Data Context Wizard keeps one governed context graph across both warehouses and everything downstream; the Data-Agents Swarm does the work with 20+ specialist agents, including the migration agent that plans waves; the Autonomous Data-Conductor runs each fix end to end; and per-domain guardrails hold approvals, receipts and rollback.
PowerCenter and IDMC to Data Workers. PowerCenter and IDMC connect over their APIs today: the migration owner exports mappings, sessions and workflows from the repository and converted taskflows from IDMC, and Data Workers compares them and checks the tables both sides load. It reads Snowflake, dbt Cloud, ServiceNow and Slack natively and reaches Teradata, JD Edwards and Power BI over their APIs; the full list is on Data Workers integrations. For each wave, the migration agent maps dependencies and downstream consumers, translates hand-written Teradata or Oracle SQL into Snowflake for review, writes the parity checks into the wave plan and holds the completion gate. The checks themselves run in Cloud Data Validation or your reconciliation queries; Data Workers tracks their results. The gate fails closed: an object without a passing check keeps the wave open, and the gate names it. When a check fails, diagnose_incident and get_root_cause work the evidence, trace_cross_platform_lineage follows lineage through dbt to BI, blast_radius_analysis maps what is at risk, explain_table pulls each table's definition, lineage and documentation, and get_incident_history checks for repeats. Verification uses run_quality_check, get_quality_score and the metrics the team records with monitor_metrics, and every step lands in get_audit_trail.
Data Workers back to PowerCenter and IDMC. Nothing in a mapping, session, workflow or taskflow changes without the integration owner. Data Workers proposes the change as a diff with the evidence attached, the owner applies it and runs the load, and Data Workers queues the downstream rebuild through dbt Cloud or your orchestrator and verifies. Data cleanups and reloads are proposed for the owner to approve and run.
Side by side in one client. Engineers can ask about a load, a wave or a parity result from Claude Code, Cursor or any MCP client. Add one start-agent.sh entry per agent, as the client setup guide documents. Example for Claude Code's .mcp.json:
{
"mcpServers": {
"dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
"dw-context-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
"dw-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] }
}
}Ask "why does company 00700 fail parity, and what reads fct_sales_by_entity?" and the client returns the diagnosis and the blast radius. A shared Data Workers endpoint takes an API key or OAuth tokens from your identity provider, such as Okta or Entra ID, verified through JWKS.
One yen decimal, L0 to L4. The same incident at each level, set per domain.
- •L0 manual. Wave 3 is signed off Friday on matching row counts; the error surfaces after the Teradata path is gone.
- •L1 observe. Data Workers posts the failed check, the diagnosis and the blast radius at 01:42. Nothing changes; the gate stays closed.
- •L2 propose. Data Workers proposes the full plan; nothing runs until the migration lead approves in Spellbook.
- •L3 act reversibly. For proven change classes, such as rebuilding the marts after an owner's reload, Data Workers queues the step, verifies it and records the receipt.
- •L4 autonomous. In a scoped domain with a clean record, Data Workers runs the repeatable steps end to end. Mappings, taskflows, reloads and sign-off stay with their owners.
On safety, see is it safe to let AI agents change production data, how approvals work, autonomy levels, rollback and where your data goes.
What changes for your team
- •Migrations. Each wave is planned with its parity checks, tracked every night and gated on the wave owner's sign-off.
- •Incidents. A green session with a wrong number gets a cross-system diagnosis and one plan before anyone opens the report.
- •Data quality. Checks run after every load into Snowflake, and a failed one becomes a fixed cause.
- •Cloud spend. Snowflake spend is read down to the dbt model through query tags, with setting changes drafted for their owner.
- •Access. Snowflake roles for users moving off Teradata are dry-run and proposed as time-boxed grants for the data owner.
- •Audits. Every fix and every wave sign-off carries a receipt: cause, approver, checks passed and the undo.
The migration lead changes most: sign-off becomes a gate with every check named. See who owns the agents and the legacy ETL modernization guide.
Keep PowerCenter, or consolidate?
Keep PowerCenter if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most PowerCenter estates keep it running until the last wave signs off, and many keep Informatica afterwards in IDMC. What teams consolidate is the work around the move: the parity spreadsheet, the second lineage tool and the email thread that is the only record of why a wave slipped. Some estates move parts of the logic to dbt on Snowflake instead; Data Workers plans and gates those waves the same way. Building that layer yourself? Read build it ourselves with Claude Code and MCP servers: reading a repository export is easy; the context graph, the gate, approvals and rollback are the work.
For the rest of this stack, see you're on Teradata, you're on Talend, you're on Control-M and what is an agentic data platform. For tooling options, see automating Teradata and Informatica migrations and using AI agents to modernize legacy ETL to dbt.
The case for your CFO
The outcome: a modernization that finishes with numbers nobody has to defend. Every wave ships on planned, tracked, signed-off parity, and every production load is checked where it lands.
The risk story: autonomy is set per domain. At L1 Data Workers only reads; at L2 it changes nothing until a named person approves; at L3 it applies changes it can undo. Mappings, reloads and wave sign-off stay with their owners. An unanswered request expires and escalates, never auto-grants, and no agent can promote its own work. Every change carries a receipt: cause, change, approver, verification and undo. An org-wide stop halts all autonomous dispatch. Zero migration: every system stays where it is.
Why now: the parallel run is the cheapest moment to catch a wrong number, because both versions still exist. The first win is read-only: every wave's parity results in one place and every failed check diagnosed before the sign-off meeting. What stays the same: your Informatica contract, mappings, schedules and integration team. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "PowerCenter and IDMC move our data; Data Workers makes sure every number is right before we switch anything off, with an approval and a receipt."
Getting started
Start with a pilot. Pick the next wave, connect Data Workers to PowerCenter, IDMC, Snowflake, dbt and your BI, and run at L1: the wave gets its plan, its parity checks and a gate that names anything unproven. Then turn on a first write class at L2, such as dbt Cloud rebuilds after an owner's reload. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
When does PowerCenter support end? Informatica publishes support dates in its Product Lifecycle statements, and they vary by version and contract, so check those and your agreement. Informatica's own pages this month show PowerCenter 10.5.11 released in August 2026 and the product page renamed "PowerCenter to Cloud Modernization", steering customers to IDMC.
Is Informatica part of Salesforce now? Yes. Salesforce completed its acquisition of Informatica on Nov 18, 2025, and the site reads "Informatica from Salesforce". PowerCenter, IDMC and the modernization offers continue.
We already use Cloud Data Validation. Why add Data Workers? Keep it: it, or your reconciliation queries, produces the parity evidence. Data Workers plans which checks each wave needs, tracks every result through the parallel run, holds the completion gate for the owner's sign-off and, when a check fails, diagnoses the cause across PowerCenter, IDMC, dbt and BI and routes the fix to its owners.
Does Data Workers run our PowerCenter workflows or IDMC taskflows? No. Workflows, taskflows and reloads stay with your integration owner. Data Workers proposes changes with evidence, queues downstream rebuilds and verifies.
Does Data Workers convert our mappings? Informatica's PC2CDI Modernization Service converts PowerCenter assets to Cloud Data Integration. Data Workers plans the waves, maps dependencies and translates hand-written Teradata or Oracle SQL into Snowflake for review.
What about CLAIRE agents? CLAIRE agents work inside IDMC and help build and fix pipelines there. Data Workers works across every system the data reaches under one approval flow.
Where does our data go? The agents run in your infrastructure and hold the warehouse credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only.
Sources
- •Informatica, "PowerCenter to Cloud Modernization" ("Modernize PowerCenter to Intelligent Data Management Cloud"; "Informatica from Salesforce"), https://www.informatica.com/products/data-integration/powercenter.html (checked Oct 3, 2026)
- •Informatica, PowerCenter Cloud Edition data sheet (2023 edition, linked from the live page: Cloud Data Integration for PowerCenter, PC2CDI Modernization Service, Cloud Data Validation), https://www.informatica.com/content/dam/informatica-com/en/collateral/data-sheet/cloud-data-integration-for-powercenter_data-sheet_4622en.pdf (linked from the PowerCenter page; checked Oct 3, 2026)
- •Informatica Documentation, PowerCenter 10.5.11 ("Released: August 2026 | Updated: September 2026"), https://docs.informatica.com/data-integration/powercenter/10-5-11.html (checked Oct 3, 2026)
- •Informatica, CLAIRE AI (CLAIRE agents; IPU offer through Jan 31, 2027), https://www.informatica.com/platform/claire-ai.html (checked Oct 3, 2026)
- •Salesforce, "Salesforce Completes Acquisition of Informatica" (Nov 18, 2025), https://www.salesforce.com/news/press-releases/2025/11/18/salesforce-completes-acquisition-of-informatica/ (checked Oct 3, 2026)
- •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)