Inventory and dependencies from metadata
PowerCenter stores its definitions in a repository, and that repository can be exported or queried. That makes Informatica one of the better-documented legacy platforms, provided the metadata is analysed as a whole rather than mapping by mapping in the Designer.
A normalised inventory covers:
- mappings and mapplets, with their sources, targets and transformations
- sessions, including their overrides of SQL, connections and load behaviour
- workflows and worklets, with task order, conditions and schedules
- reusable transformations and shared objects
- parameter files and mapping variables, including persistent ones
One practical complication: physical object names often carry suffixes for environments, versions or copies, so the same logical table can appear under several names. Resolving those back to logical objects is what makes the lineage graph readable. The graph then shows which mappings feed which, where a single target fans out to many consumers, and which long chains must migrate as one wave.
Classify transformation patterns
Most Informatica estates are built from a limited number of recurring patterns: extract and stage, lookup and enrich, filter and route, aggregate, slowly changing dimension, reject handling. Classifying mappings by pattern lets repeated logic map to a small set of well-tested target patterns instead of being migrated as hundreds of individual pieces of work.
Classification also exposes transformations whose behaviour changes when translated naively:
| Informatica construct | Typical target | What to watch |
|---|---|---|
| Lookup | Join, often a broadcast join | The lookup’s multiple-match policy (first, last, any value or error). A plain SQL join returns every match and duplicates rows. |
| Aggregator | GROUP BY | Ports that are neither grouped nor aggregated return the value from the last row of each group. SQL requires an explicit choice. |
| Joiner | Join | The naming of master outer and detail outer joins is easy to invert. Sorted-input settings can also hide assumptions. |
| Update Strategy | MERGE | Row-level insert, update, delete and reject flags must become explicit merge conditions. |
| Router | Several filtered outputs | Rows can satisfy several groups. The default group catches the rest. |
| Sequence Generator | Identity or key-generation logic | Surrogate keys will differ from legacy values. Validate on business keys. |
| Normalizer | Unpivot or explode | Generated occurrence columns that downstream logic may rely on. |
| Mapping variables | Pipeline parameters, watermark tables | Persistent variables that drive incremental loads must keep their state across the cutover. |
Choose the Fabric target deliberately
A visual Informatica transformation does not need a visual equivalent in Fabric. The target should be chosen for maintainability and fit with the platform:
- Data Factory pipelines for orchestration and data movement, taking over from workflows, worklets and schedules
- Notebooks with Spark for transformation logic, especially where patterns can be implemented once and reused through configuration
- Warehouse and SQL for set-based logic owned by SQL-oriented teams
- Lakehouse Delta tables for staging and integration layers
- dbt, where the organisation wants SQL transformations with version control, tests and documentation built in
Mapplets and reusable transformations are natural candidates for shared functions or macros. A hundred mappings that follow the same staging pattern are better served by one metadata-driven component than by a hundred translated copies.
Preserve operational behaviour
The logic of a mapping is only part of what the estate does. Sessions and workflows also define how it runs: commit intervals, how source rows are treated, reject files, error thresholds, retries, conditional branches, event waits and pre- and post-session SQL. Operators rely on this behaviour even if nobody has documented it.
The target orchestration has to reproduce what matters: dependencies between loads, parameters, failure handling, restartability without duplicating data, and the effect of incremental state. Behaviour that only existed as a workaround can be dropped, but deliberately and with the owners’ agreement.
Validate the outputs
Every migrated target should be compared with the legacy output on business keys, attribute values, aggregates and, for dimensions, history. The lookup, aggregator and router behaviours above are precisely the kind of difference that passes code review and fails a data comparison. See how to prove a migration is correct.
Rationalise before reproducing
Informatica estates that have grown over many years almost always contain the same logic implemented several times, mappings that load tables nobody reads, and staging steps that existed only because of old source-system limits. The dependency graph shows where logic can be consolidated and what can be retired. That should be decided before the build starts, not discovered afterwards.
Questions we are often asked
Can Informatica mappings be converted to Fabric automatically?
Parts of the work can: metadata extraction, pattern classification and translation of common transformations. Behaviour such as lookup match policies, aggregator defaults and update strategies must be checked explicitly, and the result validated against legacy outputs.
Should every Informatica mapping become a Fabric pipeline or notebook?
No. Repeated patterns are better implemented once and driven by configuration. The unit of migration is the business workload, not the individual mapping.
How do you handle Informatica incremental loads during cutover?
Persistent mapping variables and other incremental state are moved into watermark tables or pipeline parameters, and the cutover plan fixes the point from which the new platform takes over, so no data is loaded twice or skipped.