Skip to main content
Informatica migrations start from exported metadata—XML for PowerCenter repository objects or cloud exports for Intelligent Cloud Services (IICS). The importer maps sources, targets, transformations, and dataflow links into Planasonix nodes; complex expressions and procedural steps often need manual follow-up.
Review Import and convert for wizard flow and how to read conversion warnings at scale.

​
XML and export formats

1

PowerCenter export

Export mappings, mapplets, sessions, and workflows as XML using repository manager or pmrep/repoutil workflows your organization approves. Include shortcut dependencies or resolve them before export.
2

IICS export

For IICS, export tasks, mappings, and taskflows using the Asset Management or CLI patterns Informatica documents for your edition. Bundle dependent connections and parameter files as instructed by Planasonix.
3

Upload and select scope

Upload the archive to Planasonix, choose PowerCenter or IICS profile, and limit scope to a folder or project to keep reports readable.
Prefer small, vertical slices (one subject area) per import batch. Informatica graphs can be enormous; slicing reduces merge conflict risk on the canvas.

​
Transformation mapping

Informatica constructPlanasonix direction
Source Qualifier / Application Source QualifierSQL source or API source with inferred filters
Expression, Filter, RouterColumn transforms, predicates, and branches
Joiner, Union, LookupJoin, union, and lookup-style transforms (verify caching semantics)
Aggregator, SorterAggregation and sort nodes
Update StrategyMerge/upsert or delete handling—validate warehouse-specific behavior
Custom transformations, External Procedure, and Java transforms become manual tasks in the conversion report. Replace them with SQL, Python, or supported native nodes.
XML, JSON, or Unstructured readers may map partially. Expect to rebuild parsers using Planasonix parser nodes or external staging.

​
Session and workflow conversion

PowerCenter sessions and workflows provide parallelism, dependencies, and recovery configuration.
  • Session pre-SQL and post-SQL may map to pre/post hooks or explicit SQL nodes—confirm execution order.
  • Workflow links and conditions map to control-flow edges; time-based waits become schedule or delay patterns.
  • Checkpoints and recovery semantics differ from Planasonix orchestration—revalidate restart behavior for long-running loads.
Parameter files and session-level overrides are easy to miss. Cross-check Informatica $PM variables and session parameters against Planasonix variables before production runs.

​
Connections and loaders

Rebind Informatica connections to Planasonix connections. Native bulk loaders (Teradata TPT, Snowflake COPY patterns, etc.) may translate to destination node options or require you to pick an equivalent load strategy.
Row-based commit intervals and transaction boundaries in Informatica do not always have direct analogs. Test failure mid-batch behavior explicitly.

Joins and unions

Rebuild and validate join logic after import.

Orchestration overview

Schedules, triggers, and chaining compared to workflows.