Informatica conversion · AI-accelerated · parity-proven

Every Informatica product in your estate has an exit. The converter only knows about one of them.

PowerCenter is the part everyone talks about. The B2B, EDI, managed-file-transfer and Data Exchange estates sitting beside it are not in the conversion utility’s scope at all — and on a real estate they are the third of the work nobody costed. We convert all of it: AI reads and drafts, a named senior engineer reviews every artifact, and row-level tests prove the replacement produces the same rows as the thing it replaced.

Book an exit assessment How we work

Two things get called “moving to the cloud”. They are not the same thing.

A buyer who has been quoted for one and thinks they bought the other finds out eighteen months later. This is the first distinction we draw in any conversation, before any number is discussed.

CDI-PC — re-host

Your PowerCenter binaries re-hosted. The domain registers to IDMC and the workflows run as they are, under a Secure Agent.

What you get: The same mappings, running.
What it costs you: Nothing modernizes. The objects largely cannot be edited in the cloud, so the estate is now somewhere new and just as frozen.
When it is the right answer: Buying time past end of support with no rewrite. A legitimate answer — as long as everyone says out loud that it is what is being bought.

PC2CDI — convert

Metadata converted into native cloud assets: mappings, mapplets, mapping tasks and taskflows.

What you get: A real IDMC estate you can develop against.
What it costs you: The conversion residue is real work, and it is where this engagement lives.
When it is the right answer: Actual modernization. This is the one we are usually hired for, and the one the rest of this page describes.

The conversion engine lives inside CDI-PC as an agent application, which is why the two get sold as one thing. They are not one thing.

Everything in the estate, and what happens to it

Conversion tools are sold against the first group. The second group is not in their scope at all — which is why an estate scoped on an asset count is routinely scoped short.

The PowerCenter estate

What the conversion utility addresses — and the six places it stops short.

Mappings, mapplets, sessions, workflows and worklets

Where it goes: Native cloud mappings, mapping tasks and taskflows on IDMC — or Azure-native, where you are leaving Informatica rather than following it.
What no tool does for you: The cloud has no Source Qualifier, no Custom transformation, no XML Parser or Generator and no External Procedure. XML and hierarchy work moves to Hierarchy Parser, Builder and Processor or to Structure Parser. Each of those is a rebuild, not a conversion, and each is priced as one.

On the record: Three enterprise PowerCenter-to-IDMC programmes led — Toyota North America, Intertape Polymer Group, F&G Annuities & Life. Led by a founder, in a lead role on the client’s own programme, before this company existed.

SQL overrides and stored-procedure calls

Where it goes: The target platform’s dialect, or pushed down to the database where it does the work better than a mapping can.
What no tool does for you: The utility does not translate these. It extracts the SQL to a spreadsheet and waits for a human to type the target dialect into a column. It is invisible in an asset count and it is a named line item in our estimate, because that is the honest place for it.

Parameter files and parameterisation

Where it goes: Cloud parameter files and pipeline parameters, with credentials moved into a secret store instead of a text file on a share.
What no tool does for you: A separate conversion task with its own input mapping and its own path requirements on the agent. Parameter scopes get re-prefixed with the project name, so every downstream reference has to be walked. Estates fail their first cloud run on this more often than on any transformation.

Workflow commands, pmcmd calls and shell scripts

Where it goes: Explicit orchestration in the target, where the step is visible instead of buried in a command task.
What no tool does for you: The most under-estimated line item in every migration we have seen. These are the steps somebody added at 2am in 2014 — an archive, a trigger file, a call into another system — and they are frequently the only surviving documentation of what the estate really does.

Scheduler dependencies — Control-M and its neighbours

Where it goes: The scheduler’s own cloud service, or the target platform’s scheduling, with the dependency graph rebuilt rather than re-typed.
What no tool does for you: The dependencies live in the scheduler, not in Informatica. Converting workflows without converting the graph between them is how a clean cutover becomes a bad quarter-end.

On the record: A Control-M on-premise-to-cloud scheduler migration delivered alongside the PowerCenter-to-IDMC conversion at F&G Annuities & Life, by a founder on the client’s own programme.

PowerExchange CDC and legacy connectivity

Where it goes: Cloud change-data-capture and native change feeds, with mainframe, AS/400 and legacy sources reconnected.
What no tool does for you: The assessment’s connection report lists supported and unsupported connections. Read the second half first: an unsupported source is a new build wearing a conversion’s clothes.

On the record: PowerExchange change-data-capture delivered at Toyota North America, CoreLogic, Canada Life and Sabre, by a founder on each client’s own programme.

The exchange estate — B2B, EDI, MFT, DX

Where the conversion utility’s scope ends. It addresses the PowerCenter repository and integration services; these re-platform separately, by hand, and they are routinely a third of an estate.

B2B Data Transformation

Where it goes: Transformation maps on the target integration platform — Integration Account maps and Liquid transforms paired with Logic Apps on Azure, or the equivalent B2B services on IDMC.
What no tool does for you: Nothing automated touches these. A parser written in the Studio’s own scripting environment is a program, and it gets read, understood and rewritten by an engineer who can read both ends. Both founders have retired B2B estates onto IDMC and Azure — one of those records is documented and carries the figure below; the other is not yet on file, so nothing is attached to it.

On the record: 2,184 B2B translation mapping documents assessed from repository exports on the Azure programme at Intertape Polymer Group, by a founder on the client’s own programme.

EDI and X12 trading partners

Where it goes: Trading-partner agreements, schemas and X12 transforms rebuilt on Azure Integration Account, with envelope settings and acknowledgements re-established per partner.
What no tool does for you: Partner migration is not a conversion problem, it is a re-certification problem. Every partner needs its agreement, its envelopes and its acknowledgements tested end to end against the live counterparty before the old link can be switched off — and the counterparty has their own change calendar. Plan it as a partner-by-partner schedule, never as a cutover weekend.

On the record: Trading-partner transport rebuilt for 22 partners across 16 live agreements at Intertape Polymer Group, by a founder on the client’s own programme.

Managed file transfer

Where it goes: Logic Apps, Service Bus and Key Vault, with SFTP endpoints, partner credentials and PGP keys rebuilt rather than copied.
What no tool does for you: The file movement is the easy half. The hard half is the credentials, the key rotation, the retry and late-file behaviour and the alerting — none of which is written down anywhere, all of which somebody notices the first night it does not happen.

On the record: 123 managed-file-transfer partner projects assessed from repository exports on the same programme at Intertape Polymer Group.

Data Exchange (DX) processes

Where it goes: Event-driven integration on the target platform, with the partner-facing endpoints and the operational visibility rebuilt alongside them.
What no tool does for you: Out of the utility’s scope as well. The migration risk here is operational rather than technical: whoever watches the DX console every morning needs the same view on day one in the new platform, or they will not sign the cutover.

Data quality and profiling

Rules move as specifications, not as objects.

Data quality rules and profiles

Where it goes: Re-expressed in the target platform, with the profiling re-run against real data so you can see which rules were actually firing.
What no tool does for you: Data quality objects are outside the conversion utility as well. That is not entirely bad news: a rule set that has drifted for a decade benefits from being read out loud, and this is the only moment in the programme when somebody has a reason to.

On the record: Data quality delivered on the Toyota North America programme, by a founder in a lead role on the client’s own programme.

What we will not convert

An Informatica MDM hub migration. On the Azure programme a founder is leading now, master data sits on Dataverse behind Dynamics 365 — but that is a rebuild of where master data lives, not an MDM hub migration, and we will not sell it as one. If your exit depends on moving a hub, say so early and we will tell you who should do it.

What the AI actually does, in order

Four things, each of which we can describe to your architect at whiteboard depth. If a firm cannot tell you which of these four they mean, they mean the second one and they are not reviewing the output.

Reads an estate nobody has documented since 2016
We point AI tooling at the exported mappings, workflows, parameter files and job definitions and get back a dependency graph, a difficulty classification per object, and documentation for an estate whose authors left years ago. This is the part where even the sceptics agree the saving is real, because the burden being removed is reading volume, not judgement.
Drafts the conversion — and the draft is a draft
AI produces the candidate artifact. A named senior engineer reviews every single one before it moves an inch. We publish no automation percentage, because we have not measured yours, and anyone quoting you one before seeing your estate is quoting you a marketing number.
Writes the tests that prove it, at the same time
The parity suite is generated as part of conversion rather than assembled afterwards by a team that has stopped caring. That ordering is the whole reason the gate below is affordable enough to run on every wave instead of once before go-live.
Improves the artifact, deliberately and reversibly
Where the source object carries fifteen years of accumulated damage, the conversion is the one moment it is cheap to fix. Every improvement is behaviour-preserving and proven by the same parity gate, or it is raised as a change with its own sign-off. It is never both at once and never quiet.

A conversion that only converts hands you 2009 in a new location

A transliterated mapping is a working mapping and a wasted opportunity. These are the improvements we make while the artifact is open, all of them behaviour-preserving, all of them proven by the parity gate rather than asserted.

SQL retyped for the target, not wrapped in it

Overrides become the target dialect, or push down to the database where it outperforms a mapping. Wrapping the old SQL in a new shell is the cheap answer, and it is why some migrated estates run slower than the ones they replaced.

Hardcoded paths and credentials removed

Server names, file paths and passwords that were compiled into objects become parameters and secrets in a vault. This is also the single most common blocker to running the same artifact in three environments, which is what makes everything below it possible.

Dead objects retired instead of migrated

The run history tells you which workflows have not executed in two years. Migrating them costs money twice — once to convert, once to keep supporting. We propose the list; you decide what goes. Nothing is deleted on our judgement alone.

Copy-paste lineage consolidated

Estates accumulate near-identical mappings that diverged slightly, one incident at a time. Where the differences are genuinely parameters, they become parameters. Where they turn out to be real business rules somebody forgot, that is a finding worth more than the consolidation.

Error handling and restartability made consistent

Most estates have three or four generations of error handling in them. The converted estate gets one, so that failure at 3am has a defined behaviour rather than an archaeological answer.

Documentation and runbooks written as it goes

Generated from the estate itself while an engineer has it open and can correct it, rather than retrofitted by somebody reading the same undocumented objects six months later.

Every artifact shipped through versioned pipelines

Deployment across environments through Azure DevOps — versioned, reviewed, reproducible, and rolled back if it misbehaves. Ordinary discipline for application code, still unusual for integration code.

Proving the numbers match

The reason migrations stall in UAT is that nobody can demonstrate the new pipeline produces the same output as the old one. Row counts and checksums are not a gate — aggregates match while hiding exactly the cases that hurt: nulls, type coercion, precision loss, ordering, and rows that are individually wrong in ways that cancel out. An estate signed off on row counts is an estate whose defects surface at quarter-end.

Schema diff
Names and types, both directions. Wide-numeric, time and nested types throw false positives on every platform; we catalogue those once per target instead of re-arguing them every run.
Row-hash diff
A hash per row, no join key required — which makes it the cheapest full-estate sweep that exists and the one we can afford to run continuously.
Keyed value diff
Joined on business keys, compared column by column, with per-column mismatch samples you can read. Sampled during the wave, then a full pass before sign-off.
The edge-case suite
Nulls, type casts, precision, empty string versus null, date boundaries, time zones. This is where the real defects live, and it is the stage a converter vendor does not run.
N clean parallel cycles
Old and new running side by side until N consecutive cycles are green. N is agreed in the statement of work, not negotiated the week you want to decommission.

Nobody has to trust the AI, including us. Here is the test.

Informatica’s own Cloud Data Validation reports missing, unmatched and extra records and is a reasonable component of this where you already own it. The results are yours either way — the gate is not a thing we describe, it is a thing we hand over.

What we ask for in week one

The repository assessment is the only estate-specific, defensible number that exists before anyone signs anything. It buckets every asset automated, partial or manual — and manual means Informatica’s own tooling says there is no direct cloud equivalent. We score complexity from flag frequency, never from asset count.

Manual and partial flag reports: The actual work. Frequency here is the complexity score.
Command list: Workflow commands, pmcmd and shell scripts. The most under-estimated line item there is.
Parameter file inventory: A separate conversion task type with its own failure modes.
SQL and ELT summary: Every override that a human has to retype for the target.
Connection summary: Supported and unsupported connections. The unsupported half sizes the rebuild.
File and XML pre-processing configuration: Flat-file and XML surface area, which is where hierarchy rebuilds hide.

One practical warning worth having before you schedule it: the assessment run itself is not free. A large repository wants several gigabytes of heap on the agent, and one agent handles one assessment plus two conversion jobs at a time. Ask us for the sizing before you promise your steering committee a date.

The tools this estate actually lives in

Seven surfaces from a working on-premise Informatica estate — four of them the exchange estate no conversion tool touches — each annotated with what a conversion engineer looks for in it and what happens to what they find. If your team recognises these screens, they will recognise whether we know them.

PowerCenter Designer

Mapping DesignerRecreation

The canvas where the business logic actually is. A reviewer reads it left to right and stops on four things: the Source Qualifier, because it has no cloud equivalent and its SQL override does not travel; the unconnected lookups, which do convert but cannot be called from a Joiner or a Java transformation; the Update Strategy, which decides whether this mapping is idempotent when it is re-run; and any expression long enough that nobody has read it since it was written.

In conversion: Most of this converts. The Source Qualifier’s override becomes a line in a spreadsheet waiting for a human, and any Custom, XML Parser or External Procedure transformation becomes a rebuild.

PowerCenter Workflow Manager

Workflow DesignerRecreation

What the estate does around the mappings, and where the undocumented half lives. The command tasks call shell scripts. The link conditions carry logic that exists nowhere else. The event waits are watching for a file that another team’s job produces, and the two teams have never met.

In conversion: The tasks convert. The scripts behind the command tasks do not — they are read, understood and rebuilt as explicit steps, which is also the first time in years anyone will know what they do.

PowerCenter Workflow Monitor

Gantt chart viewRecreation

The most useful screen in the estate and the one nobody thinks to export. Run history is ground truth: it shows the real schedule rather than the documented one, the real dependencies, the jobs that have not run since 2023, and the two-hour window everything has to fit inside on a Sunday night.

In conversion: This is where the wave plan and the decommission list come from, and it is the baseline the parity runs are measured against.

B2B Data Transformation Studio

Parser project · X12 850Recreation

Where the EDI and B2B estate is defined — parsers, serializers and mappers written against transaction sets, anchored to the segments and elements of an X12 document, and run from a Data Processor transformation. This is a program, not configuration, and it has been maintained by whoever was available.

In conversion: Nothing automated converts this. It is read and rewritten as maps and transforms on the target platform, then re-tested against real partner traffic, not against a sample file.

PowerCenter Designer

Transformation Developer · Unstructured Data TransformationRecreation

The join between the two halves of a B2B estate, and the one an asset count always misreads. The transformation sitting in the mapping does almost nothing itself: it has an input buffer, an output buffer, and a Service Name pointing at a parser project that lives somewhere else entirely. Migrate the mapping and you have migrated the call, not the thing being called.

In conversion: The transformation has no cloud equivalent, and neither does what it points at. Both are rebuilds, and they are two separate pieces of work on two different tools — which is why an estate counted in mappings under-reads its B2B exposure every time.

B2B Data Exchange

Operation Console · event listRecreation

Where the exchange estate is watched rather than built. Every document that arrives or leaves is an event with a partner, a document type, a direction and a status, and somebody opens this console before anything else each morning to see what went red overnight. The detail view is the part that decides a cutover: it shows exactly where in the chain a document stopped — received, validated, parsed by a Data Transformation service, routed, delivered — and the error shown here is the classic one, a control number out of sequence.

In conversion: Outside the conversion utility entirely. The processing rebuilds on the target platform; the harder half is this view, because the person who reads it every morning needs the same answer on day one in the new platform or they will not sign the cutover. Control numbers in particular are stateful, and the issuing logic usually lives inside the translator being retired.

Managed File Transfer

Projects and partner accountsRecreation

The estate’s front door to the outside world: projects that move files on a schedule, partner web-user accounts, SFTP and AS2 endpoints, PGP key pairs and the event log that somebody checks each morning. Almost none of it is in the repository, so almost none of it appears in an asset count.

In conversion: Rebuilt on the target integration platform. The transfers are the straightforward part; the credentials, key rotation, retry behaviour and alerting are the part that decides whether cutover night is quiet.

Every screen here is drawn to the real tool — the title and menu bars it actually has, its navigator tree, PowerCenter’s own object colours — so that a team who lives in these products recognises them. A screen marked a recreation is our drawing rather than a captured screenshot, and we label it rather than let you assume. Captures, where we have them, come from a lab estate we run ourselves with generic object names — never a client system.

What buyers ask about this page

Does Informatica’s conversion utility handle our B2B, EDI and MFT estate too?: No. It addresses the PowerCenter repository and integration services. B2B, Data Exchange, managed file transfer, MDM and data quality objects re-platform separately, by hand. This is the single most common surprise in a scoped migration, because the asset count everyone budgeted against never included them. Confirm it against your own tenant before you commit a number to a board — we will do it with you during the assessment rather than asserting it at you now.
We already moved to CDI-PC. Have we migrated?: You have stopped the support clock, which was probably the point, and that is a legitimate thing to have bought. But your PowerCenter objects are now running in the cloud largely uneditable, and nothing has modernized. If the plan was always to convert afterwards, the assessment tells you what that second step costs. If somebody sold it to you as the migration, you should know that it was not one.
How do we know the AI has not quietly changed a value somewhere?: Because silently-wrong output that runs cleanly is the known failure mode of machine translation, and it is what the gate is built to catch. Schema diff, row-hash diff, keyed value diff, an edge-case suite aimed squarely at nulls, casts, precision and time zones, then N clean parallel cycles. You do not have to trust the AI, or us. You have to trust a test you can read and re-run yourself, which is a different and much better proposition.
If you improve the code while converting it, how is that still a like-for-like migration?: Because the two are kept separate on purpose. Behaviour-preserving improvements — parameterising a hardcoded path, unifying error handling, retyping SQL for the target — are proven identical by the same parity gate, and if the gate goes red the improvement is wrong and it comes out. Anything that would genuinely change an output is not made quietly; it is raised as a change with its own decision and its own sign-off. The failure we are designing against is the migration that arrives with improvements nobody asked for and nobody can see.
What automation percentage should we expect?: We will not quote one before seeing your estate. For scale: published figures for automated ETL converters cluster around 70% out of the box, and one converter vendor advertises up to 95% while its own published case study on a real Informatica estate reports 78%. Informatica’s own material variously claims over 90% of assets, up to 100% asset reuse and 8X faster delivery. None of those figures is independently audited and none is about your estate. The assessment produces a number that is.

Book an exit assessment All services in detail

Every Informatica product in your estate has an exit. The converter only knows about one of them.

Two things get called “moving to the cloud”. They are not the same thing.

CDI-PC — re-host

PC2CDI — convert

Everything in the estate, and what happens to it

The PowerCenter estate

Mappings, mapplets, sessions, workflows and worklets

SQL overrides and stored-procedure calls

Parameter files and parameterisation

Workflow commands, pmcmd calls and shell scripts

Scheduler dependencies — Control-M and its neighbours

PowerExchange CDC and legacy connectivity

The exchange estate — B2B, EDI, MFT, DX

B2B Data Transformation

EDI and X12 trading partners

Managed file transfer

Data Exchange (DX) processes

Data quality and profiling

Data quality rules and profiles

What we will not convert

What the AI actually does, in order

Reads an estate nobody has documented since 2016

Drafts the conversion — and the draft is a draft

Writes the tests that prove it, at the same time

Improves the artifact, deliberately and reversibly

A conversion that only converts hands you 2009 in a new location

SQL retyped for the target, not wrapped in it

Hardcoded paths and credentials removed

Dead objects retired instead of migrated

Copy-paste lineage consolidated

Error handling and restartability made consistent

Documentation and runbooks written as it goes

Every artifact shipped through versioned pipelines

Proving the numbers match

Schema diff

Row-hash diff

Keyed value diff

The edge-case suite

N clean parallel cycles

What we ask for in week one

The tools this estate actually lives in

PowerCenter Designer

PowerCenter Workflow Manager

PowerCenter Workflow Monitor

B2B Data Transformation Studio

PowerCenter Designer

B2B Data Exchange

Managed File Transfer

What buyers ask about this page