Migrate Informatica PowerCenter workflows to Apache Airflow

How to migrate Informatica PowerCenter workflows to Apache Airflow

Apache Airflow takes over scheduling, dependencies and alerting for your PowerCenter estate while Apache Hop runs the mappings, and most of the work is inventory, dependency mapping and parallel running. If you operate PowerCenter 10.4 or 10.5, the workflows, worklets, session schedules and failure notifications often outlive the mappings they call, so the orchestration layer is the part you can move first. Platform and data engineers usually own this work, with an implementation partner supplying scheduling design and cutover support. Start by exporting every workflow and worklet with pmrep ObjectExport and listing, for each one, its trigger, upstream dependencies, downstream consumers, parameter files and alert recipients. Effort depends on how many workflows chain across folders and how many depend on file arrivals or database flags, and the reader should ask for a count of those cross-dependencies before agreeing on a scope.

Model each PowerCenter workflow as a DAG in Airflow, with each session replaced by a task that calls a Hop pipeline or workflow through the Hop GUI export or a Hop Server submission. Hop Server does not schedule anything itself, so Airflow must submit the work, and the Hop manual describes deploying projects as Docker images, exported ZIP resources or from a Git checkout. Decide early whether tasks run on the LocalExecutor, the CeleryExecutor or the KubernetesExecutor, because Airflow 3.3.2 supports Python 3.10 to 3.14, PostgreSQL 14 to 18 and Kubernetes 1.30 to 1.35, and the hybrid CeleryKubernetesExecutor is no longer supported from Airflow 3.0.0. Use a PostgreSQL metadata database rather than the default SQLite, which the production guide says can lose data, and plan a fresh Airflow 3 install instead of an in-place upgrade of any existing Airflow 2 instance, which reached end of life on April 22, 2026.

Run both schedulers in parallel for at least one full business cycle, comparing run status, row counts and alert delivery between PowerCenter and Airflow before disabling any PowerCenter schedule. Airflow supports multiple schedulers using database row-level locks, so you can run more than one for resiliency during the overlap. Keep alert routing from the PowerCenter workflows, including recipients and escalation paths, as an explicit checklist item, since no conversion tool carries it over. Treat the cutover as a set of reversible steps: disable schedules one folder at a time, keep the PowerCenter definitions read-only, and record the owner who signs off each workflow. Ask your implementation partner to state in writing which workflows are in scope, what counts as a passed parallel run, and who is responsible for alert rules and credentials.

Which PowerCenter scheduling capabilities map cleanly to Airflow

This table compares PowerCenter workflow scheduling features with their closest Airflow equivalents and labels each as clean, needs rework or gap. Airflow is an orchestrator, so it sequences and triggers work but does not convert mapping logic, which stays in Apache Hop pipelines. Read a clean row as a direct mapping, and a rework or gap row as a design task for your team.

Capability	Airflow equivalent	Fit
Workflow dependencies	Task dependencies within a DAG	Clean. Confirm each link against the exported workflow graph.
Session ordering	Task order set by dependencies, with no session object	Needs rework. Each session becomes a task that calls a Hop job, and ordering is rebuilt by hand.
Worklets	Task groups or parameterized sub-DAGs	Needs rework. Reusable blocks must be re-expressed and tested as shared task groups.
Schedules	Cron expressions or timetables on the DAG	Clean. Check time zone, start date and catchup settings for each schedule.
Parameter files	Params, Variables and DAG run configuration	Needs rework. Values must be moved by hand into Variables, Connections or Hop metadata.
Reruns and recovery	Clearing task instances and manual DAG runs	Needs rework. Restart works at task level, so mapping-level checkpoints must be designed.
Retries	Retry count, retry delay and failure callbacks per task	Clean. Set retry values per task and confirm them against current PowerCenter behavior.
Notifications	Callbacks and notifier operators for email or chat	Needs rework. Alert rules must be rebuilt and tested, since nothing is copied from PowerCenter.
Environment promotion	Variables, Connections per environment and DAGs deployed from Git	Gap. Airflow has no built-in promotion model, so teams must design the pipeline and secrets handling.

What the pmrep exports carry and what they do not

The PowerCenter XML exports give you the structure of your orchestration, which is the starting point for every Airflow DAG. Everything that determines how a run actually behaves sits outside those files and has to be gathered from the live environment before cutover.

Workflow and worklet structure

The export records workflows, worklets, sessions and task definitions along with their links and dependencies. Use it to build a dependency map that becomes the task graph in each Airflow DAG. Check that every worklet reference resolves, because a worklet reused across workflows is easy to miss when you count jobs by hand. Mark sessions that run in parallel or conditionally so the DAG keeps the same branching.

Schedules and triggers

Schedule definitions in the export show intended timing, but the scheduler that actually fired jobs may have been an external tool, a shell wrapper or an operator's calendar. Confirm which trigger produced each run, including file arrival, event or manual starts. Record time zones and any blackout windows, since they often live outside the repository. Each trigger becomes a schedule, sensor or API call in Airflow, and an omitted one means a job that silently stops running.

Connection secrets and credentials

Connection objects reference database and file system targets, but the passwords and key material are not carried in the XML. Obtain them from your secrets owner and load them into a secrets backend that Airflow reads, rather than into DAG files. Confirm which service accounts each connection uses, since a rebuilt DAG that runs under a different identity will fail authorization checks. Plan rotation so credentials are never copied into version control.

Runtime parameter values

Parameter and variable files supply values at run time, and many workflows read different values per environment, date or source system. The export usually names parameters without their values, so collect the parameter files from each environment and record which ones are in active use. Dates, file paths and batch identifiers often differ between development and production. Map each parameter to an Airflow variable, template field or run configuration.

Environment-specific settings

Hosts, ports, directory paths, server grid assignments, session pool sizes and memory limits describe the PowerCenter environment, not the workflow logic. None of these map directly onto an Airflow deployment, so do not copy them across. Ask your platform team to document the target Airflow environment, including executor type, worker resources and network paths, and check each DAG against that target. These settings are often the source of failures that appear only after cutover.

Run history and operational behavior

Restartability, recovery from failed sessions, error handling and the historical run log are runtime behavior, not definitions. Pull recent run history from the PowerCenter repository and operations tooling to see which jobs fail often, which need manual restarts and which depend on partial reruns. Those patterns show where the DAG needs retries, idempotent steps or alerting that the original workflow did not express. The export itself is a specification to read and check against this history, not a file Airflow imports.

The migration sequence from inventory to decommission

This sequence moves PowerCenter scheduling into Airflow one workflow chain at a time, while mappings are rebuilt in Apache Hop, so each cutover is backed by a comparison of outputs rather than by assumption. Every step closes with a written artifact that the next step depends on.

Build the inventory from pmrep exports
Export the repository objects with pmrep ObjectExport or Repository Manager XML exports, then list every workflow, worklet, session, mapping and schedule in a single inventory sheet. Record the folder, the repository, the parameter file each session reads and the schedule that triggers it. Ask a PowerCenter administrator to confirm that the export covers every folder in use, because objects left out of the export will be missed later. The step is done when the inventory matches the repository object count reported by the administrator and each row has an owner.
Map dependencies into a dependency register
Trace which workflows call worklets, which sessions depend on upstream loads, and which jobs read files or tables written by another workflow. Capture external triggers such as file arrivals, database flags and calls from other schedulers, since these are the links most often lost during a move. Write the result as a dependency register that names each edge, its type and its owner. The step is done when a business owner has reviewed the register for each workflow group and confirmed that no dependency is undocumented.
Build and sign off a pilot DAG set
Choose one workflow chain that is representative but low risk, and rebuild its orchestration as Airflow DAGs with task dependencies that mirror the register. Mappings in the pilot are rebuilt as Apache Hop pipelines and run from the DAG, using a Hop Server or the apache/hop container image, so the team tests the full path. Run the pilot in a non-production environment with the same connections and a copy of the data. The output is a pilot sign-off document that records the DAG version, the Hop project version, the run history and the open defects, approved by the data owner.
Run both schedulers in parallel
For each workflow group, let PowerCenter and Airflow execute the same inputs on the same schedule while only the PowerCenter outputs feed production consumers. Compare row counts, checksums, reject files, error logs and load timings for every target table or file, and log each difference with its root cause. Airflow supports running more than one scheduler against the same metadata database, so confirm the production database setup before the parallel period starts. The step is done when a reconciliation log shows zero unexplained differences for a full cycle of the group's schedule, signed by the data owner.
Cut over one workflow group at a time
Move each group to Airflow as the sole scheduler for its jobs, starting with groups that have the fewest downstream consumers and no external triggers. Disable the matching PowerCenter schedules only after the Airflow DAG has run successfully on its live schedule, and keep the PowerCenter schedule in a disabled state so it can be restored. Record the cutover time, the owner who approved it and the rollback steps in the change log. The group is complete when its reconciliation log remains clean for the agreed period after cutover and no consumer reports a missing load.
Retire PowerCenter schedules and archive evidence
After every group has run on Airflow, remove the remaining PowerCenter schedules, stop the integration services that no longer run any job and archive the repository backup with its exports. Keep the pmrep exports, the dependency register, the reconciliation logs and the change records in a retention location that your audit and records policies name. Confirm with your compliance team which records they need to keep and for how long, since that retention period is set by your organization, not by this guide. The step is done when no production job depends on PowerCenter and the archive has been checked by someone other than the migration team.
Decommission PowerCenter and close the project
Once the archive is verified, shut down the PowerCenter domain and repository services according to the license and support terms in your Informatica agreement, and confirm with Informatica how the license is ended. Remove network access, database accounts and service credentials used only by PowerCenter, and update the runbooks, monitoring and on-call rotation to point at Airflow. Hand over the DAG repository, Hop project and operating procedures to the team that will run them. The step is done when the decommission checklist is signed by the platform owner and no PowerCenter components remain in production.

How the Airflow platform should be deployed for production

The first production decision is the metadata database. Airflow's default SQLite backend is for testing only, and running it in production can lead to data loss, so plan for PostgreSQL or MySQL from day one. MariaDB is not supported as the metadata database, which matters for teams whose database standard is MariaDB. For Airflow 3.3.2, the prerequisites list PostgreSQL 14 to 18 and MySQL 8.0, 8.4 and Innovation releases, along with Python 3.10 to 3.14 and Kubernetes 1.30 to 1.35 if you run on a cluster. Check these against your own base images and database support contracts before you pin versions, because the migration will also depend on the Hop engine and Java 21 runtime sitting alongside it.

The executor is the second decision, and it drives how much infrastructure you own. LocalExecutor suits a single host with modest parallelism, CeleryExecutor distributes tasks to worker pools that you size and monitor, and KubernetesExecutor starts a pod per task, which fits teams that already run Kubernetes. Since Airflow 2.10.0 several executors can run in one deployment, which helps during cutover. Note that the hybrid CeleryKubernetesExecutor and LocalKubernetesExecutor are no longer supported as of Airflow 3.0.0, so any design that relied on them from a Airflow 2 pilot needs to be redesigned. Size RAM from the recommended minimum of 4 GB for the scheduler host, then load test with a sample of your heaviest PowerCenter workflows.

Running more than one scheduler is supported and improves resiliency, because schedulers coordinate through database row-level locks. Test this during the parallel run period, not after go-live. Confirm that the metadata database is sized for scheduler heartbeats and task state writes, and that failover behaves as expected when one scheduler stops. Keep the production deployment guide and the executor documentation in the runbook, and record which version, database and executor each environment uses, since these choices determine what your upgrade path looks like when Airflow 2 reaches end of life on April 22, 2026.

How the migration differs by estate size and starting point

A small PowerCenter estate with a few workflows, a handful of schedules and one team usually moves in a single wave. The inventory is short enough that one engineer can read every workflow export, and the same people who rebuild mappings in Apache Hop can write the Airflow DAGs. The main risk is skipping the inventory because the estate feels simple, so the export step still matters even when the count is low.

Sequencing: Migrate workflows in the order their upstream dependencies require, and rebuild each DAG only after its Hop pipelines pass a test run.
Parallel run: Keep the PowerCenter scheduler live for one full business cycle of each critical workflow, then switch it off in a single change.
Team roles: One or two engineers own the DAGs, and an application owner signs off on output tables and load times.
Infrastructure: A single Airflow deployment with PostgreSQL as the metadata database is usually enough, and it should not run on SQLite outside testing.
Documentation: Keep a short runbook per DAG covering schedule, retries, owners and the PowerCenter workflow it replaces.

Before committing to a single wave, confirm with your own inventory that no workflow depends on a PowerCenter-only session behavior that Hop must reproduce.

What drives cost and duration in a PowerCenter to Airflow move

This table lists the factors that most change the effort of moving PowerCenter scheduling to Airflow while mappings are rebuilt in Apache Hop. Read each row as a lever: the driver, why it changes the work, and how to keep it contained before you ask a partner for a quote.

Driver	Why it changes cost or effort	How to keep it down
Number of workflows and worklets	Each workflow becomes a DAG with its own tasks, retries, alerts and owners, so inventory size sets the testing and cutover workload.	Use the pmrep export to count objects, retire unused workflows first, and group the rest into waves.
Cross-workflow dependencies	Dependencies between workflows, worklets and shared sessions decide how DAGs must be split or linked, and hidden chains cause the most rework.	Map dependencies from the exports before design, and merge tightly coupled jobs into one DAG where ownership allows.
Event-based and file-triggered schedules	Sensors, file arrival checks and trigger logic need different designs than cron schedules and are harder to test without real inputs.	Count these separately in the inventory, and confirm which upstream systems must emit events or files.
Custom pre- and post-session commands	Shell scripts, FTP steps and inline logic embedded in PowerCenter sessions must be found, reviewed and reimplemented as tasks or operators.	Search exports for command strings, move reusable logic into versioned scripts, and document credentials handling.
Number of environments	Development, test, UAT and production each need connections, variables, secrets and deployment steps for both Airflow and Hop.	Standardize configuration through environment variables or a secrets backend and automate deployments from Git.
Length of the parallel run	Running PowerCenter and Airflow side by side means paying for two schedulers and reconciling outputs for each cycle until sign-off.	Set exit criteria per workflow, such as matched row counts and reconciled outputs, and retire schedules as each one passes.
Rework to build Hop pipelines	PowerCenter mappings have no automatic importer, so each mapping is rebuilt by hand, and transformation logic, data types and error handling need validation.	Prioritize by business criticality, reuse shared transformations as Hop metadata, and confirm which mappings can be retired instead of rebuilt.

What usually goes wrong and how to prevent it

Most failed PowerCenter-to-Airflow cutovers fail on the same few points: logic that lived in the scheduler, two schedulers running at once, and a metadata database that was never meant for production. The cards below pair each risk with the check that catches it before decommission.

Missed scheduler-only dependencies

PowerCenter workflows often chain jobs through scheduler settings, such as a dependent job that starts only after a file lands or a parent completes on a particular status. Those rules rarely appear in the mappings or the XML exports you use as inventory. Before cutover, list every trigger, time window and file-based dependency in the old scheduler and map each one to an explicit Airflow dependency or sensor, then test the failure paths.

Duplicate runs during parallel operation

While both schedulers run, the same source extract can be loaded twice into the same target, which corrupts counts and downstream reports. Airflow supports more than one scheduler at once using database row-level locks, but that does not stop two separate platforms from processing the same input. Assign each job to exactly one scheduler per run window, and make target writes idempotent with partition overwrites or merge keys.

SQLite or undersized metadata databases

Airflow's default SQLite backend is for testing only, and running it in production can lead to data loss. The prerequisites also rule out MariaDB as a metadata database and recommend at least 4 GB of RAM. Put the metadata database on PostgreSQL or MySQL from the start, confirm supported versions against the prerequisites page, and size it for the run history your PowerCenter schedule will generate.

Executors Airflow 3 no longer supports

Teams that planned a hybrid executor layout often assume CeleryKubernetesExecutor or LocalKubernetesExecutor will carry over. Those hybrid executors are no longer supported as of Airflow 3.0.0. Choose from the executors Airflow 3 still ships, such as LocalExecutor, CeleryExecutor or KubernetesExecutor, and use the multi-executor support available since Airflow 2.10.0 if you need separate queues. Confirm the choice with a load test before the first production run.

Secrets copied into DAG code

PowerCenter stores connection details in the repository, and migration scripts or quick rebuilds often paste hostnames, usernames and passwords straight into DAG files. Those values then live in Git history and in every developer's checkout. Move credentials into Airflow connections or a secrets backend your security team already audits, and add a repository scan that fails the build when a DAG contains a literal password or token.

Unfinished reconciliation before decommission

Teams often switch off PowerCenter once the new DAGs run without errors, without proving the outputs match. Row counts, checksums and sampled business totals for each target should agree across a full business cycle, including month-end or other periodic loads. Keep the PowerCenter schedule disabled, not deleted, until reconciliation sign-off is documented, so you can rerun or roll back the old path.

Questions teams ask before moving PowerCenter scheduling to Airflow

What does moving PowerCenter scheduling to Airflow cost?

The cost depends on how many workflows, worklets and schedules you have, how many depend on each other, and how many environments must be rebuilt. Airflow itself has no license fee: it is an Apache-2.0 project and the Apache Software Foundation offers no paid edition. The costs you will actually pay are the infrastructure to run the scheduler, web server, metadata database and workers, the engineering time to write and test DAGs, and the operations work that follows. Infrastructure and staff are mostly recurring, while inventory, DAG design and cutover testing are one-time. Ask any implementation partner for a quote built from a written scope that lists the workflow count, the connections to re-create and the environments in play.

How long does a PowerCenter to Airflow scheduler migration take?

Timing is set by the size and complexity of the schedule estate, not by Airflow itself. The main drivers are the number of workflows and worklets with inter-dependencies, how many use custom error handling or session-level recovery, how many external triggers or file watchers feed them, and whether mappings are moving to Apache Hop at the same time. Running both schedulers during cutover adds a parallel-run period that you should plan for explicitly. No duration is fixed by the project, so ask for a timeline in the written scope and confirm each milestone against your own change calendar.

Can an internal team move PowerCenter scheduling to Airflow alone?

A capable internal team can do it, provided it has Python and DAG-authoring experience, someone who knows the PowerCenter repository and its dependencies, and time to run a parallel schedule. Teams that already run Airflow for other work usually move faster. The risks are rarely the DAG syntax. They are missing dependency knowledge, undocumented restart behavior and production-grade database and security setup. Many organizations split the work, keeping inventory and business rules in-house and bringing in outside help for infrastructure hardening, testing or cutover support.

What does the work need from our own staff?

Expect to need the people who own the workflows, the people who run the PowerCenter environment, and someone who can approve production changes. Workflow owners must confirm what each schedule is supposed to do, including reruns, notifications and business calendars. Platform staff must provide the network paths, credentials and secrets handling, and the target database or metadata store. Security and compliance staff should review access roles and audit evidence. Ask the implementation partner to list these roles in the scope so that availability is agreed before work starts.

Is Apache Airflow free to use in production?

Yes, Airflow is released under the Apache License 2.0 (Apache-2.0), and the project itself offers no paid edition. Your costs come from the infrastructure, people and support you choose, not from a license. Before you commit, confirm that your chosen version is supported. Airflow 2 entered limited maintenance on October 22, 2025 and reached end of life on April 22, 2026, after which it receives no fixes. Airflow 3 was first released on April 22, 2025, so new DAG work should target the current major line. Check the Apache version life cycle page for the exact support status of the version you plan to run.

Does the pmrep export convert automatically into Airflow DAGs?

No. There is no automatic converter from PowerCenter workflows and worklets to Airflow DAGs that you can rely on for production. The pmrep export gives you a structured inventory of workflows, sessions, dependencies and schedule attributes, which is the right starting point for a manual or semi-automated rebuild. It does not carry over runtime behavior, connection credentials, environment variables or the logic your team implicitly relies on during failures. Plan to review each DAG against the original workflow and test the restart and alerting paths before cutover.

Do PowerCenter support deadlines force the timing of this move?

Support deadlines set the risk window, but the timing of the scheduler move should follow your engineering capacity and change control. Informatica announced that PowerCenter 10.4 support ended March 31, 2024, after which it moved to fee-based Extended Support, and named IDMC, Extended Support or an upgrade to PowerCenter 10.5 as options. Scheduling is one part of a wider exit, so decide whether you will keep PowerCenter running for a period. Confirm your current support status and contract terms with Informatica before setting a date.

How DeployOpen scopes and runs this migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where the Airflow scheduler, its metadata database and the Hop servers will run. For a PowerCenter exit, that means DeployOpen would work from the inventory of workflows, worklets, schedules and dependencies that your team exports, then agree in writing which DAGs, which Airflow executor and which metadata database (PostgreSQL or MySQL, not SQLite) are in scope, and which PowerCenter jobs are retired rather than rebuilt. Most engagements are fixed-scope, so scope, deliverables and timelines are settled before any work starts.

A quote follows from that written scope, not from a headcount guess. The items that usually move the quote are the number of workflows and worklets that carry real business logic, how many schedules depend on event triggers or file arrivals, whether the parallel-run period in the cutover plan is included, how secrets and connections are migrated, and what the hardening and backup scope covers for the Airflow metadata database and the Hop Server deployment. Ask for each of these to appear as a separate line item with its deliverable and acceptance check, so you can see which parts recur and which are one-time. Confirm with DeployOpen which Airflow version and Python version the fixed scope targets before you sign, because the version support dates affect how long the platform stays patched.

Ongoing support, upgrades and continuous testing are available as retainers, and they matter most after cutover, when the Airflow version moves through its support windows and the Hop, Java and database dependencies need patching. A retainer is recurring and is separate from the fixed-scope build, so decide early who in your organization owns DAG reviews, Airflow upgrades and on-call response once PowerCenter is switched off. DeployOpen can document the runbooks and evidence that your own compliance team needs, but it does not issue audit reports or certifications; those come from independent auditors and certification bodies that you choose.