Move off PowerCenter with proof the numbers match.
Standard support for Informatica PowerCenter 10.5 ended on March 31, 2026, and paid extended support ends in March 2027. The pipelines still run the business, and the people who understood them are retiring.
We migrate PowerCenter estates to open engines and prove that every migrated pipeline produces the same rows as the original. The proof is the deliverable. The translation is how we get there.
The fourth option.
Data platform owners at insurers, banks, healthcare payers, public agencies and retailers who run hundreds to thousands of PowerCenter mappings, and have three options on the table: pay Informatica to move onto its cloud, pay a systems integrator to convert by hand over eighteen months, or run unsupported software in production.
Assess, migrate, run.
- 01
Assessment
You send us a repository export: the XML that describes the mappings, not your data. Within two weeks we return:
- An inventory of every mapping and pipeline, with the transformation types, functions, parameters and variables in use.
- Which pipelines our compiler converts automatically and which it refuses, with the written reason for every refusal. We publish the reasons, not a percentage.
- The assumptions each pipeline depends on, such as a row order the mapping leaves undefined, listed pipeline by pipeline.
- A verified pilot: a slice of your estate compiled to SQL on Apache DataFusion and checked cell by cell against an independent reference implementation on generated adversarial data. You read the reconciliation report.
- A cost model for the full migration, by pipeline class.
- 02
Migration
Pipelines are converted in batches, in your environment. Each batch runs beside the original PowerCenter job on your data and your schedule, and ships only when the reconciliation report is clean. Mappings the compiler refuses are handled by engineers, with the same report at the end. Every semantic choice in the generated code cites the Informatica reference it came from.
- 03
Run
The migrated estate runs on open engines in your cloud account: readable SQL and Python your team owns, in your repositories. No new platform licence replaces the old one.
A reconciliation report for every pipeline.
- Row counts in and out, every output column compared.
- NULL and conversion semantics as PowerCenter defines them:
IS_NUMBER(NULL)is NULL,TO_DECIMALof a string that starts with a non-numeric character is 0, andTO_INTEGERrounds unless told to truncate. Each rule is traced to the Transformation Language Reference. - Mapping parameters and variables bound and recorded.
- Nondeterministic columns, such as session timestamps and sequences, verified structurally, with the policy stated.
- Every refusal named with its reason, and every assumption the pipeline depends on, with the choice we made.
A tool that converts 95% of an estate and cannot tell you which 5% it got wrong has converted nothing you can ship. Ours tells you.
Row order, named per pipeline.
Some PowerCenter results depend on the order rows arrive in, and the mapping does not always define that order: variable ports that read the previous row's value, aggregator ports that return the last row received, sorts with ties. PowerCenter's own output there depends on what the source database returns.
We compile these over a stated order, list the assumption against each pipeline, and check it against your real runs. Dynamic lookup caches are named in the assessment and estimated separately. This is where migrations stall when nobody names it.
The export, not your data.
The assessment needs only the repository export from the PowerCenter repository manager. It contains mapping logic and schemas, not data. It is handled under NDA, in an isolated environment, and deleted at the end of the engagement unless you ask us to keep it for the migration.
Verification against your production data happens inside your environment, by engineers you have cleared, on the same terms as any embedded engineering work we do.
We build the engines.
Bearing's engineers contribute to Apache Arrow, Apache DataFusion, Apache Spark and pandas, the open projects the migrated estate lands on. The migration compiler is a compiler: a parser for the PowerCenter export format, a typed intermediate representation, two independent back ends and a differential tester. Its function semantics are checked against Informatica's published Transformation Language Reference, and the checks are tests in the codebase.
On a public federal payroll estate of 108 mappings and 133 pipelines, it compiled every pipeline. 131 produced identical rows from both back ends on generated data, 2 produced no rows on that data and are reported as such, and 26 depend on an assumption that the report lists.
Also: DataStage and Ab Initio estates, with the same method, assessed on request; SQL-only warehouse moves (Teradata, Netezza) as part of a wider estate.
Start with the assessment.
Tell us the size of the estate and the deadline you are working to.
Get in touch →