Migration Best Practices: Informatica to Azure¶

Lessons learned, common pitfalls, and proven patterns for successful Informatica-to-Azure migrations.

Pre-migration assessment checklist¶

Before committing to a migration, complete this assessment to scope the effort accurately and identify risks early.

Informatica inventory¶

• Mappings: Count and categorize by complexity (simple, medium, complex)
• Workflows: Count, document dependencies, schedule frequency
• Sessions: Map each session to its mapping and workflow
• Connections: List all source and target connections with database types
• Reusable components: Inventory all shared mapplets, mapping templates, and parameter files
• Transformations: Count by type (Expression, Lookup, Joiner, Router, Custom Java, etc.)
• IDQ rules: Count and categorize data quality rules by complexity
• IDQ profiles: List all active profiles and their source tables
• IDQ scorecards: Document all scorecard reports and their consumers
• MDM entities: List all mastered entities (customer, product, vendor, etc.)
• MDM match rules: Document all match/merge rules and thresholds
• MDM hierarchies: Map all hierarchy types and their management processes
• EDC catalogs: List all cataloged data sources and lineage coverage
• B2B/EDI: Inventory EDI trading partner integrations
• License cost: Document current annual license + maintenance + infrastructure cost
• Team skills: Assess team SQL proficiency, cloud experience, and willingness to adopt code-first
• Downstream consumers: Map all reports, APIs, and applications that consume pipeline outputs

Complexity scoring¶

Score each mapping on a 1-5 scale for each dimension:

Total score interpretation:

Risk register template¶

Conversion priority strategy¶

Principle: Simple first, complex last¶

Migrate in order of complexity, not business importance. This builds team confidence and establishes patterns before tackling hard problems.

graph LR
    A[Tier A: Simple mappings] --> B[Tier B: Medium mappings]
    B --> C[Tier C: Complex mappings + DQ]
    C --> D[MDM replacement]

    style A fill:#90EE90
    style B fill:#FFFF99
    style C fill:#FFB347
    style D fill:#FF6B6B

Wave planning by business domain¶

Within each tier, organize by business domain for atomic cutovers:

What to migrate first within each wave¶

1. Reference data pipelines -- lookups, dimension loads (lowest risk, highest reuse)
2. Simple fact loads -- extract, transform, load (establish the pattern)
3. Incremental loads -- establish watermark and incremental patterns
4. Complex transformations -- multi-source joins, SCD, business logic
5. DQ rules -- after data flows are migrated, apply quality checks
6. MDM workflows -- last, after all source pipelines are stable

IICS vs PowerCenter: migration differences¶

Key differences in migration approach¶

IICS-specific considerations¶

1. IPU analysis first. Analyze actual IPU consumption to right-size Azure resources
2. Connector mapping. IICS premium connectors may have free ADF equivalents
3. CLAIRE AI features. Some IICS-specific AI recommendations have no direct equivalent; document which you rely on
4. Application Integration. IICS CAI -> Logic Apps requires architecture redesign, not just mapping
5. Data Integration Elastic. Elastic mappings on Spark may need Databricks, not just dbt

Parallel-run validation¶

Why parallel run is mandatory¶

Parallel run is the highest-confidence validation strategy. Both platforms run the same logic; you compare outputs.

Parallel-run setup¶

graph TB
    Source[(Source Data)] --> PC[PowerCenter Pipeline]
    Source --> ADF[ADF + dbt Pipeline]
    PC --> PC_Target[(PowerCenter Output)]
    ADF --> ADF_Target[(dbt Output)]
    PC_Target --> Reconcile{Reconciliation Report}
    ADF_Target --> Reconcile
    Reconcile --> Match[Match: Continue migration]
    Reconcile --> Mismatch[Mismatch: Investigate and fix]

Reconciliation checks¶

Automated reconciliation dbt test¶

-- tests/reconciliation/assert_daily_sales_matches.sql
WITH pc AS (
    SELECT
        order_date,
        COUNT(*) AS row_count,
        SUM(order_amount) AS total_amount
    FROM {{ source('powercenter', 'fact_daily_sales_pc') }}
    GROUP BY order_date
),

dbt_output AS (
    SELECT
        order_date,
        COUNT(*) AS row_count,
        SUM(order_amount) AS total_amount
    FROM {{ ref('fct_daily_sales') }}
    GROUP BY order_date
)

SELECT
    COALESCE(pc.order_date, d.order_date) AS order_date,
    pc.row_count AS pc_rows,
    d.row_count AS dbt_rows,
    pc.total_amount AS pc_amount,
    d.total_amount AS dbt_amount,
    ABS(COALESCE(pc.total_amount, 0) - COALESCE(d.total_amount, 0)) AS amount_diff
FROM pc
FULL OUTER JOIN dbt_output d ON pc.order_date = d.order_date
WHERE pc.row_count != d.row_count
   OR ABS(COALESCE(pc.total_amount, 0) - COALESCE(d.total_amount, 0)) > 0.01

Parallel-run duration guidelines¶

Team retraining: from GUI to code-first¶

The skill transition¶

Training program structure¶

Common retraining challenges¶

Success metrics for retraining¶

Common pitfalls and how to avoid them¶

1. Trying to recreate PowerCenter's visual UX in dbt¶

Problem: Teams spend weeks trying to build visual mapping tools on top of dbt or using ADF Mapping Data Flows for everything.

Solution: Accept the paradigm shift. dbt is code-first. The visual UX is dbt docs generate (for documentation) and ADF pipeline designer (for orchestration). Use Mapping Data Flows only for flows that require a visual interface (analyst-built, non-production).

2. Migrating everything at once (big bang)¶

Problem: Attempting to migrate the entire Informatica estate in one release. Massive risk, long stabilization period, overwhelmed team.

Solution: Wave-based migration by business domain. Each wave has its own parallel run, cutover, and stabilization. Never more than one wave in flight.

3. Leaving DQ rules unimplemented¶

Problem: PowerCenter mappings are migrated but IDQ rules are deferred. Data quality issues surface in production weeks later.

Solution: For every mapping migrated, migrate its associated DQ rules at the same time. Use dbt tests as the primary mechanism. Never cut over a pipeline without its DQ tests in place.

4. Underestimating MDM replacement¶

Problem: MDM is treated as "just another migration" and scoped at 4-6 weeks. It invariably takes 4-6 months.

Solution: Scope MDM as a separate workstream with its own timeline. Consider Profisee as a purpose-built replacement. Assess whether full MDM is actually needed (often it is not).

5. Not training PowerCenter developers¶

Problem: PowerCenter developers are expected to write dbt models without training. They struggle, become frustrated, and resist the migration.

Solution: Invest 2-4 weeks in structured training before starting conversion work. Pair experienced dbt developers with PowerCenter developers. Budget 15-20% of migration cost for training.

6. Sequencing by mapping count instead of business domain¶

Problem: Team migrates the "easiest" mappings first regardless of business domain. This means no domain can fully cut over until all domains' easiest mappings are done.

Solution: Sequence by business domain. Migrate ALL of Finance (simple through complex) before starting Sales. This enables atomic domain cutover.

7. Forgetting B2B/EDI¶

Problem: B2B Data Exchange and EDI integrations are discovered late in the migration and require separate architecture (Logic Apps + APIM).

Solution: Inventory B2B/EDI in the assessment phase. Plan Logic Apps + APIM replacement explicitly. B2B is often a separate team and a separate workstream.

8. Not planning for license termination¶

Problem: Migration completes but Informatica license auto-renews because no one sent the termination notice (typically 90-day notice required).

Solution: Review Informatica contract terms during assessment. Send termination notice at the start of the last wave, timed to expire after parallel run completes.

9. Ignoring the repository metadata¶

Problem: PowerCenter repository metadata (lineage, mapping history, session statistics) is deleted when servers are decommissioned. Historical lineage is lost.

Solution: Export PowerCenter repository metadata to Purview before decommission. Use Purview's custom lineage API to preserve historical data flow documentation.

10. Over-engineering the target architecture¶

Problem: Team designs a complex multi-service architecture (ADF + Databricks + Synapse + Fabric + dbt) when a simpler stack would suffice.

Solution: Start with ADF + dbt + Azure SQL. Add Databricks only for Spark workloads. Add Synapse only for very large analytical queries. Add Fabric only for specific Fabric features (Direct Lake, mirroring). Keep it simple.

Team structure recommendations¶

Core migration team (mid-sized engagement)¶

Timeline estimation guidelines¶

Multiply by 1.2x for federal/government deployments (compliance overhead).

Success criteria¶

Define clear, measurable success criteria before starting:

Related resources¶

• PowerCenter Migration Guide -- Detailed PowerCenter-specific guidance
• IICS Migration Guide -- IICS-specific migration
• Data Quality Migration Guide -- IDQ replacement patterns
• MDM Migration Guide -- MDM replacement architecture
• Benchmarks -- Performance comparisons
• Migration Playbook -- End-to-end migration guide

Last updated: 2026-04-30 Maintainers: CSA-in-a-Box core team Related: Migration Playbook | Tutorials | Benchmarks