informatica-to-pyspark-migration

Provide the PowerCenter XML export and the Skill parses it into a component inventory, resolves the dataflow, and emits one pure Python function per mapping with the signature run_<mapping>(spark, params, table_map, dry_run). Each transformation is annotated with its original Informatica instance name for review.

Sessions become Lakeflow Job tasks and workflows become multi-task jobs with depends_on edges, or Declarative Pipelines for straight table-build chains. Link conditions map to run_if or condition_task, parameter files split into job parameters and a table_map, and file-watch events become file arrival triggers.

Yes, but both are flagged as high risk rather than silently approximated. Unconnected lookups become joins after verifying key uniqueness, and Sequence Generators map to Delta IDENTITY columns, window offsets, or a control-table allocator depending on whether contiguous values are required.

Stored Procedure, SQL, Java, Custom, and External Procedure transformations execute code outside the mapping export, so their source must be obtained and ported by hand. VSAM/COBOL Normalizers and dynamic lookup caches also require deliberate design decisions rather than direct translation.

The Skill produces a four-gate procedure: static review, synthetic-data equivalence tests, a differential run on production snapshots, and a parallel run across a business cycle. It includes a reconciliation harness using null-safe joins, numeric tolerance, and duplicate-key checks.

Common causes are DECODE matching NULL to NULL, the || operator treating NULL as empty string, DATE_DIFF returning fractional values, and the session's Enable High Precision flag controlling Decimal versus Double behavior. The expression function map documents each of these differences with the correct Spark equivalent.