Informatica PowerCenter¶

Informatica PowerCenter is automatically converted to Snowflake. Your exported PowerCenter repository (the mappings, workflows, transformations, and expressions) is read and runnable Snowflake code is produced, so you can migrate data pipelines without rewriting them by hand.

This guide is the translation reference: it explains how each Informatica element maps to Snowflake, what the generated code looks like, and where to review manual follow-ups.

How Informatica concepts map to Snowflake¶

The following table maps each Informatica concept to its Snowflake or dbt counterpart:

Output formats¶

Two output formats are produced. The generated Snowflake code differs by format, so this guide documents each one separately:

Several references are shared across both output formats, because the orchestration and the generated Snowflake expressions are the same regardless of format:

• Workflows and orchestration: how Workflows become Snowflake Task graphs.
• Variables and parameters: the control_variables table, parameter files, and variable scope.
• Expression functions: Informatica functions and their Snowflake equivalents.
• Data types: how PowerCenter data types map to Snowflake types.
• File ingestion: how flat-file sources and lookups land on the stage the generated reads bind to.

Supported components at a glance¶

The tables below list the Informatica components that are recognized and which output formats support them today. Unlisted components generate an EWI code that flags the component for manual conversion.

Mapping transformations (data flow)¶

Workflow elements (control flow)¶

These capabilities apply across the workflow, rather than to a single element:

File ingestion¶

A converted flat-file read doesn’t open the file on your PowerCenter host. It reads one generated stage, public.landing_stage, so every file a Mapping used to open on a filesystem has to arrive there first. The conversion inventories the files it expects and generates disabled Openflow flows that can land them, but it never moves a file and never writes a credential.

Landing is the same for both output formats: the prefixes below are the ones the dbt staging models, the Scripting tmp_sq_ temporary tables, and the static Direct copy loads bind.

1. Find ingestion-manifest.json. There’s one manifest for the whole project, not one per Mapping, so a source definition that several Mappings read appears once. When the conversion writes an artifacts folder, look under artifacts/ingestion/<session timestamp>/ (or artifacts/ingestion/ if that run has no session timestamp). Otherwise the file is at ETL/ingestion-manifest.json.
2. Find the generated landing flows: ETL/openflow/SnowConvert ETL Landing.json for an S3-compatible source bucket, plus ETL/openflow/SnowConvert ETL Landing (Azure).json and ETL/openflow/SnowConvert ETL Landing (GCS).json. All three are generated. The store you stage through doesn’t have to match where the original file sat.
3. Map each original path to your object store. Use the original location recorded for that source to find the file, then upload it under the expected bucket prefix in the same source’s mapping. The original path is diagnostic: the conversion doesn’t infer a bucket from a drive letter or a UNC share.
4. Import a flow while it’s still disabled. Fill in the SnowConvert file landing parameter context for your source store and Snowflake connection, supply your own credentials, then enable the components. Each process group covers one PowerCenter folder (or Shared, for a definition with no folder) and copies listed objects to the matching stage prefix.
5. Confirm the file landed where the generated SQL reads. Source and lookup files land under @public.landing_stage/infpc/sources/<Folder>/<Def>/. For a known filename, that’s a path such as @public.landing_stage/infpc/sources/SalesFolder/SRC_CUSTOMERS/customers.dat.

What gets inventoried¶

Identity is the owning PowerCenter folder plus the source definition, which is what infpc/sources/<Folder>/<Def>/ encodes. The physical path is diagnostic, so two Mappings that read one definition share a single stage prefix, and two same-named definitions in different folders stay separate.

Inventoried today:

• Delimited flat-file Source Definitions and the Source Qualifiers that read them.
• Connected and unconnected flat-file Lookups.

Not inventoried:

• Flat-file Targets. A Target unloads to @public.landing_stage/infpc/targets/<Def>/, which is a file the conversion writes, not one you land.
• Fixed-width flat files. They have no Snowflake FILE_FORMAT equivalent, so they carry SSC-EWI-INF0068 instead of a stage read.

Some inventoried sources still need a mapping before a generated flow will land them. A file that already lives in an object store (an s3://, wasbs://, or gs:// location) is one case, and a definition whose driving Sessions name different files is another. The conversion doesn’t fold an object-store URI into the stage prefix, so the prefix stays infpc/sources/<Folder>/<Def>/.

Session paths that resolve at runtime¶

When the Session names the file through PowerCenter parameters rather than a literal, for example $$SourceDirectory and $$SourceFileName, the path stays a runtime binding instead of becoming UNKNOWN_FILE. In the dbt format, the read renders those parameters as var():

SELECT
   $1 :: VARCHAR(10) AS EMPLOYEE_ID,
   $2 :: VARCHAR(100) AS FULL_NAME,
   $3 :: FLOAT AS SALARY
FROM
   @public.landing_stage/infpc/sources/TestFolder/SRC_DIRECT_CSV/{{ var('SourceDirectory') }}/{{ var('SourceFileName') }} (FILE_FORMAT => 'TestFolder_m_DIRECT_LOAD_SRC_DIRECT_CSV')

In the Snowflake Scripting format, the same read is built as a string and run with EXECUTE IMMEDIATE:

LET sourcedirectory VARCHAR := public.GetControlVariableUDF('SourceDirectory', :scope) :: VARCHAR;
LET sourcefilename VARCHAR := public.GetControlVariableUDF('SourceFileName', :scope) :: VARCHAR;
EXECUTE IMMEDIATE 'CREATE OR REPLACE TEMPORARY TABLE tmp_sq_fl AS (SELECT FIELD1, FIELD2 FROM ( SELECT $1 :: VARCHAR(2) AS FIELD1, $2 :: VARCHAR(4) AS FIELD2 FROM @public.landing_stage/infpc/sources/ScriptingCases/fl/' || :sourcedirectory || '/' || :sourcefilename || ' (FILE_FORMAT => ''ScriptingCases_m_FlatFileSource_fl'') ) fl)'

Both formats run once those variables have values. The generated Openflow flows still omit the source until you map those parameter values to stage-relative path fragments, because the conversion never writes the parameter values.

When the filename can’t be resolved¶

The Session, not the Mapping, carries the source filename. When no driving Session supplies one, for example because the Mapping was exported without its Workflow, the read is emitted against @public.landing_stage/infpc/sources/<Folder>/<Def>/UNKNOWN_FILE and carries SSC-EWI-INF0069. Convert the Workflow alongside the Mapping and the same source binds its real filename instead. This is a mapping-only limitation, not the converted Workflow happy path.

Naming and sanitization rules¶

To keep generated dbt model names and ref() calls valid and aligned, Informatica object names are sanitized: any character outside A–Z, a–z, 0–9, and the underscore (_) is replaced with an underscore. Letter case is preserved.

dbt models follow the three-tier naming convention: staging models use the stg_raw__ prefix, intermediate models use the int_ prefix, and mart models take the target table name. See Informatica to dbt for details.

In the Snowflake Scripting format, mapping procedures are named public.m_<Mapping> (the m_ prefix is added only when the Mapping name does not already start with it). Mapplets, reusable shared objects, and unconnected Lookup UDFs are named <Folder>_<Def>_<8-hex SHA256 of identity> so two objects with the same Informatica name in different folders can’t collide. Example mapplet: ScriptingCases_AnActiveMapplet_eeb91c86. Example unconnected Lookup UDF: Lookup_SNOW_3702098_m_Lookup_DisconnUnconn_LKPTRANS_222878c0.

Get started¶

1. Run a conversion with Snowflake AIM Agent for Data Warehouses.
2. Choose your output format: Informatica to dbt (generally available) or Informatica to Snowflake Scripting (preview).
3. Use the shared Expression functions and Data types references as you review the generated code.