How to export your data from Informatica PowerCenter: what you can and cannot take out
A team facing PowerCenter support deadlines needs its ETL logic out of the repository before any migration plan can start. Informatica announced that PowerCenter 10.4 support ended March 31, 2024, after which customers could move to fee-based Extended Support, modernize to IDMC, or upgrade to PowerCenter 10.5. Whichever path you choose, the first deliverable is the same: a complete copy of the object definitions. PowerCenter's documented XML exports, produced from Repository Manager or with the pmrep ObjectExport command, provide that copy. They carry the definitions of sources, targets, mappings, transformations, sessions, workflows and worklets. Treat them as the specification for rebuilding pipelines in Apache Hop or Apache NiFi, not as a deployable artifact.
The XML does not carry everything the running system depends on. Runtime history, session statistics and run logs live in the repository database, not in the object definitions. Scheduling state, such as which workflows run on which calendar, and any external scheduler triggers also sit outside the export. Connection objects hold credentials that PowerCenter stores encrypted, so you will need to re-enter passwords or secrets in the target platform, and the source data itself must be moved separately. Confirm in the documentation for your exact PowerCenter version which object types each export includes, and whether connection and parameter values are exported at all. Hop's importer covers Kettle (PDI) projects only, so no PowerCenter file is converted automatically. The Apache Hop project site describes the engine and GUI you will rebuild into.
Start by turning the XML into an inventory: one row per mapping, workflow and session, with its sources, targets, owners, run frequency and downstream consumers. Export the repository database's run history and the scheduler definitions while the system is still running, because they disappear with the decommissioning. Then choose a small set of representative workflows to rebuild first, and agree in writing how each one will be reconciled against PowerCenter output, including row counts, key totals and sample records. Ask your Informatica contact or partner which export options your version supports and whether any licensing terms restrict exporting metadata. Those answers determine how much manual reconstruction the project carries.
Which PowerCenter objects export, by method and format
This table lists the main object types a PowerCenter repository holds and how each one leaves the repository through the documented XML exports from Repository Manager and pmrep ObjectExport. Use it as an inventory checklist, and test a sample export in your own PowerCenter version for every item marked for confirmation. Parameter files and connection credentials often sit outside the repository XML, so plan to collect them separately.
| Object type | Repository Manager | pmrep ObjectExport | Check in your version |
|---|---|---|---|
| Sources and targets | Included as definitions inside exported folders and mappings | Exported with the folder or mapping that uses them | Confirm whether standalone definitions export on their own |
| Mappings | Exported as XML from the folder tree | Exported using the mapping object type | Confirm whether dependent sources, targets and mapplets are included |
| Mapplets | Exported as reusable objects from the folder | Exported as reusable objects | Confirm dependency handling when a mapplet is shared across folders |
| Reusable transformations | Exported when shared within the folder | Exported as reusable transformation objects | Confirm they are included when only a mapping references them |
| Workflows and worklets | Exported from the folder with their tasks | Exported as workflow objects | Check that task links and worklet nesting appear in the file |
| Sessions | Exported with their parent workflow | Exported with the workflow or as session objects | Review session overrides and connection references separately |
| Parameter files | Not part of the repository XML | Not exported by pmrep | Inventory paths and values from the server directly |
| Connection objects | Confirm whether they are included in your export | Confirm support in your pmrep documentation | Credentials usually need re-entry in Hop or NiFi |
Repository Manager XML or pmrep ObjectExport: which path to use
Choose between the two documented export paths first, because the choice decides how repeatable your inventory will be. The Repository Manager GUI lets you select folders, mappings, workflows and sessions and write them to XML in a few steps. For a small repository with one or two folders and a single owner, that is usually the fastest route to a first inventory, and it produces a file you can read without extra tooling. The weakness is that every export depends on someone remembering which objects were selected, so two people exporting the same folder can produce different files. Treat a GUI export as a one-off snapshot, and record which repository, which folders and which PowerCenter version it came from.
Scripted pmrep ObjectExport is the better choice once you have several folders, more than one repository, or a need to repeat the inventory for each release. The command runs from a shell or scheduler, so the same selection logic runs every time and writes the same file names. Before you rely on it, confirm the options for your PowerCenter version in the command reference that ships with that release, including how it expects folder and object selection and how it connects to the repository. Keep repository credentials out of script text, for example in an environment variable or a credential store your platform team controls, and use an account with read-only rights, since an inventory does not need write access.
Whichever path you use, keep the XML in Git so later comparisons show what changed. Create one directory per repository and per folder, use fixed file names based on the object or folder, and commit each export with a message that records the PowerCenter version, the date and the person or job that ran it. A git diff between two exports then shows which mappings, transformations and connection attributes changed between releases, which is the evidence you need when a rebuilt pipeline in Apache Hop must match the original. Expect some noise: re-exports can reorder elements or change timestamp-like attributes, so export an unchanged folder twice first and see which lines differ before you trust a diff. Store the repository privately, since the exports describe your data sources and business logic.
What the XML does not carry over and how to cover each gap
A PowerCenter XML export describes mappings, transformations and workflow structure, but it leaves out much of what makes a production ETL estate run. The cards below cover the gaps that most often surprise teams during a rebuild in Apache Hop or Apache NiFi, and the checks to run before the repository is retired.
Runtime behavior and session tuning
Session-level settings such as commit intervals, buffer and cache sizes, partitioning, error thresholds and pushdown choices shape how a mapping actually performs, and most of them live in session objects rather than the mapping XML. Export the session and workflow properties separately, then record the values that differ from defaults. Confirm each one against a Hop pipeline run on representative data volumes, because the same logic can behave differently on the Hop engine, Spark or Flink.
Connection objects and passwords
Relational and application connections are stored in the repository, and PowerCenter does not export their passwords in clear form. Each mapping references a connection by name, so a rebuilt pipeline fails until someone recreates that name in Hop metadata or NiFi controller services. Keep an inventory of connection names, hosts, drivers and owners, and store the credentials in your secrets manager, not in the flow files.
Scheduler state and run history
Workflow schedules, pending runs, and the history of past successes and failures sit in the repository database rather than in the XML. If your team has read access to that database, query the run tables for the last few months to find jobs that still run, their typical durations and their failure patterns. Without that history, you cannot tell which workflows are business critical, so ask the operations team to confirm the list before cutover.
Data and sequence values
The XML describes how data moves but contains none of the data itself, including the current values of sequence generators, watermark columns used for incremental loads and lookup caches. A rebuilt pipeline that starts from the wrong watermark will either reload history or skip rows. Capture the high-water marks and sequence positions from the target systems, and plan a reconciliation of row counts and control totals for each target table.
Parameter files and parameter values
Mapping and session parameters, parameter files and $PMSessionLogFile-style variables are often kept on the server rather than in the exported objects. Environment-specific values such as file paths, schema names and date ranges frequently break when a pipeline moves. Collect every parameter file from each PowerCenter server, list the values per environment, and map each one to a Hop variable or project configuration that the operations team can review.
Custom and plugin transformations
Custom transformations, external procedures and any logic written in C, Java or stored procedures are referenced by the XML but their code and compiled libraries are not part of it. Hop and NiFi have no direct equivalent for these components, so each one needs a design decision: a native transform, a script, a database procedure or a separate service. Identify every custom component early, because these are the items most likely to extend the project schedule.
Export sequence for a complete PowerCenter inventory
This sequence produces a verified, version-controlled inventory of every PowerCenter folder, mapping, workflow, connection and schedule, so the rebuild in Apache Hop or NiFi starts from evidence instead of memory. Each step ends with a check that the export matches the repository.
Freeze changes in the production repository
Ask the PowerCenter administrators and development leads to stop check-ins, deployments and object edits in every folder in scope, and record the freeze time and the people notified in your migration log. Confirm the freeze with a repository query or a list of recent object modification dates that shows no changes after the recorded time. The step is done when the baseline is written down and the team confirms in writing that no one is changing objects during the export.
Export every folder with Repository Manager and pmrep
Run the XML export from Repository Manager for each folder, and run the same export with pmrep ObjectExport from a script so the two outputs can be compared. Keep the export options consistent, including whether dependent objects are included. The check is that both methods produce one XML file per folder, and that the list of folders matches the folder list shown in Repository Manager. Record any folder that fails to export and rerun it before continuing.
Compare object counts between repository and XML
Count mappings, sessions, workflows, worklets, transformations, sources and targets in the repository, using repository views or Repository Manager reports, and count the same object types in the exported XML with a parser or grep-based script. Investigate every difference, because a mismatch usually means a missing folder, an object with a dependency that was not exported, or a naming collision. The step is done when counts match for each folder or each difference has a documented explanation.
Store exports in version control with a manifest
Commit the XML files to a Git repository with one directory per PowerCenter folder, and add a manifest file that lists each file, its object counts and the export date. Use the same commit for both export methods if you keep them side by side, and tag the commit as the migration baseline. The check is that a fresh clone contains every file listed in the manifest and that the counts in the manifest match the comparison from the previous step.
Inventory connections and parameter files separately
The XML exports do not carry the runtime values behind connections, so list every relational, file, FTP and application connection object and every parameter and variable file used by sessions, with the environment each one serves. Store credentials in a secrets manager, not in the repository, and record only names, hosts, schemas and parameter keys in the inventory. The step is done when every connection referenced in the exported mappings appears in the inventory, which you can confirm by matching connection names against the XML references.
Capture workflow schedules and run logs
Export the schedule definitions for each workflow and record the run history from the PowerCenter repository or session logs for a period your data owners agree on, including start times, durations and failure codes. This history shows which jobs are business-critical and which dependencies run in which order, and it is information the XML does not contain. The check is that every scheduled workflow in the repository appears in the schedule export, and that the run log covers the same workflows.
Build the reconciliation list
Create a spreadsheet or table with one row per mapping, workflow, connection and schedule, and columns for source system, target, owner, business purpose, and the target Hop or NiFi object that will replace it. Mark each row with the check that proves it is covered, such as a row count comparison or a checksum on a sample of output. The list is done when every inventory row has an owner, a target and a verification method, and the migration team signs off that the list is complete.
How to verify the export is complete before the contract ends
The ETL developer owns the question of whether the XML export contains every mapping, session, workflow and reusable transformation the platform depends on. Start by comparing object counts per folder against what the repository reports in Repository Manager, then trace dependencies: every session should point to a mapping, every mapping to its sources, targets and mapplets, and every workflow to its sessions and worklets. Orphaned references are the clearest sign of a gap. The export proves that the definitions were written out and that the references resolve inside the file. It does not prove that the logic runs the same way in Apache Hop or NiFi, and it does not carry connection passwords, environment-specific parameter values or the behavior of custom code.
- Object counts by folder: Compare mappings, sessions, workflows, worklets and mapplets per folder against the repository listing, and record any difference.
- Dependency resolution: Confirm that every session, source and target reference resolves to an object in the same export, and list anything that points outside it.
- Parameter and variable files: Check that every
$$parameter and parameter file used in a session is either exported or recorded in a separate inventory. - Custom transformations and SQL overrides: Flag Java transformations, stored procedure calls and source qualifier SQL overrides, because these need manual review.
- Version and checksum record: Store the export with the repository version and a hash so later re-exports can be compared.
The ETL developer's sign-off should state the object inventory and the unresolved references, not a claim that the pipelines are migrated.
The operations lead owns the question of what the platform actually does in production: which workflows run, when, what they depend on, and whether they succeed. The XML definitions describe what a workflow can do, but they say little about its schedule, its trigger, or the files and queues it reads in practice. Pull the scheduler configuration and the session run history from the PowerCenter monitoring and repository views, then match each active schedule to an exported workflow. Workflows that have not run for a long period may still matter for month-end or regulatory cycles, so review run history over a full business cycle, not only the last few days. These records prove what ran and when. They cannot prove that a future trigger, such as an external file arrival, will behave the same way on a new scheduler.
- Active schedules: List every enabled schedule and the workflow it starts, and note any that are manually triggered.
- Run history window: Pull session logs for a full cycle, including monthly, quarterly or year-end jobs, to find workloads that only run occasionally.
- Failure and restart patterns: Record recurring failures and recovery steps, since these often live in operator knowledge rather than in the XML.
- Dependencies on external systems: Identify file drops, message queues, database jobs and upstream workflows that trigger work, because these must be replaced or rewired.
- Owner and runbook per workflow: Assign a named owner to each production workflow and confirm the runbook covers restart, rerun and escalation.
The operations lead's sign-off should confirm that every production schedule has a matched workflow and a known trigger, and that each trigger has an owner for the cutover.
The compliance owner owns the question of whether the organization can still meet its obligations for data lineage, retention and access after PowerCenter is switched off. The export covers transformation logic, which is the core of lineage, but lineage also depends on source and target registrations, data retention rules, and records of who ran what and where data went. Confirm that each regulated data flow can be traced from source to target in the exported definitions, and that the retention periods for logs, intermediate files and outputs are written down outside the platform. Decide with your auditors which evidence must be retained after the contract ends, including run logs. This check proves that the documentation needed for the obligations exists and is stored. It does not prove that an auditor will accept the reconstructed lineage, and it does not replace independent assessment by the auditor or certification body.
- Lineage coverage for regulated flows: Map each flow that handles regulated data from source to target, and confirm the export contains every step between them.
- Retention schedule for run evidence: Record how long session logs, error files and audit tables must be kept, and where they will be stored after PowerCenter access ends.
- Credential and access records: Document which accounts had access to repository objects and connections, because connection details are not in the XML.
- Data classification of targets: Check that each target and staging area carries its classification, so controls in the new platform can follow it.
- Auditor review of the evidence plan: Agree with the auditor, in writing, which artifacts will be accepted as evidence for the transition.
The compliance owner's sign-off should list the regulated flows, the retained evidence and the open items, and should be reviewed by the people who will answer auditor questions later.
What to plan before the PowerCenter contract or support window ends
The export is only useful if the decisions around it are made in time. The cards below cover the support status of your exact version, whether to buy Extended Support while the rebuild runs, read access to the repository, retention duties, and export tooling after license changes. Confirm current terms with Informatica before you commit to any timeline.
Confirm your exact PowerCenter version
Support status depends on the precise release you run, not the product family. Informatica announced that PowerCenter 10.4 support ended March 31, 2024, and that later moves went to fee-based Extended Support or to PowerCenter 10.5. Record your exact build, the hotfix level and the end-of-support date Informatica gives for it, because the export and the rebuild both depend on a version that still gets fixes. Ask Informatica in writing which dates apply to your build.
Decide on Extended Support during the rebuild
Extended Support is a fee-based bridge, so its cost is recurring for as long as you hold it. Estimate the rebuild duration from your mapping inventory, then compare the total Extended Support fees for that period with the cost of finishing faster. Ask Informatica for the fee schedule, the term length, whether renewals are discounted, and what happens to pricing if you need to extend the term. Do not let the bridge decision be made by default at renewal.
Keep read access to the repository
Once the license lapses or the environment is decommissioned, the repository database may become the only copy of mapping logic, parameter files and run history. Keep a read-only copy of the repository database, or at minimum a full set of XML exports, under your own storage controls. Confirm that the repository backup can be restored without the original license server, and document who holds the database credentials.
Map data retention obligations
Run logs, session and workflow history, and cached target data in PowerCenter may fall under retention rules set by your regulator, your contracts or internal policy. Decide what must be kept, for how long, and in what form before you purge anything. The XML exports contain design logic, not historical data, so they do not satisfy a retention requirement on their own. Involve your records and legal owners before the decommissioning date is set.
Keep export tooling working
The pmrep command line and the Repository Manager export depend on the PowerCenter client and an active repository connection. Test that pmrep ObjectExport still runs against your repository version, and keep a copy of the client installers and the required Java runtime with the export runbook. Ask Informatica whether client components remain available to licensed users after a support change, and store the exported XML under version control so the inventory stays readable without the tool.
Run exports against a frozen repository
Mappings change while the rebuild is underway, so an export taken in month one can differ from production in month six. Freeze a baseline export with a recorded date and object count, then export again at each sprint to capture changes. Tag each export set in your version control system, and reconcile new objects against the Hop or NiFi backlog. Without a frozen baseline, the specification drifts and the parity testing cannot prove what was intended.
Questions teams ask before exporting PowerCenter repositories
How long does a PowerCenter repository export take?
The export itself is usually the shortest part, and the total time depends on repository size, folder count and how quickly your team can answer questions. Export time scales with the number of folders, mappings, workflows, sessions and shared objects, so a repository with many shared folders takes longer to inventory than a single project folder. The larger delay usually comes from people: reviewers who must confirm which objects are still in use, owners who must explain schedules and dependencies, and change windows for working against production repositories. No supplied figure sets a duration for your repository. Ask for a timeline in the written scope, and run a pilot on one folder so the estimate rests on your own object counts.
Can an internal engineer export a PowerCenter repository without outside help?
Yes, if the engineer has the repository privileges and time to work through the export carefully. PowerCenter provides Repository Manager for XML exports and the pmrep ObjectExport command for scripted extraction, so an engineer with PowerCenter administration experience can produce the files without an outside firm. The harder part is judging completeness. The engineer needs to confirm which folders, shared objects, workflows and sessions are in scope, check that dependent objects were exported with their parents, and record what the XML leaves out, such as connection definitions and scheduler settings. Teams that handle this in-house usually assign one owner, keep the export files under version control and log each export run so later rebuild work can trace back to it.
Do we need a consultant to capture connections and schedules?
Not for the XML itself, but someone must document connections and scheduling. The mapping XML describes transformations, sources, targets and workflow structure. It does not carry the database connection objects, credentials or runtime behavior that make those mappings work. Scheduling often lives outside the repository, in an enterprise scheduler or in settings held by operations staff. Ask who owns each database connection, who knows which schedules trigger which workflows, and how connection passwords are stored and rotated. A consultant can speed up this inventory, especially where the people who know it have moved on, but the team that owns each system must verify the list.
Does Apache Hop's Kettle importer convert PowerCenter mappings?
No. Apache Hop's Kettle importer converts Pentaho Data Integration files, not PowerCenter exports. It turns Kettle jobs (.kjb) into workflows (.hwf), transformations (.ktr) into pipelines (.hpl), and carries over kettle.properties and shared database connections as Hop metadata. Its documented limitations include keeping only one copy of same-named database connections and no metastore import. For PowerCenter, the exported XML is your specification. Each mapping, workflow and session is read and rebuilt by hand as Hop pipelines and workflows, then tested against the original outputs. Plan for that effort in the scope and do not expect a file conversion step. The Kettle import guide shows what the importer covers.
What does the export need from our team in people and access?
Plan for four roles and a controlled place to store the files. You need a PowerCenter administrator or developer who can log in to the repository with export rights, a developer who knows the folder structure and the business purpose of each mapping, and a person who owns the source and target databases so connection details can be confirmed. You also need someone who can describe scheduling and name the operations contact for each workflow. Exported XML can contain table names, column logic, server names and comments about business rules, so store it in access-controlled storage, limit who can copy it and record who ran each export. Confirm these roles and access arrangements in writing before work starts.
What does a fixed-scope PowerCenter export engagement usually include?
A fixed-scope engagement covers the work listed in a written scope document, with deliverables and timelines agreed before work starts. DeployOpen plans and implements engagements like this for self-hosted open-source platforms, and it does not publish a price list, so a quote follows from the written scope. Typical items to confirm in that scope include:
- An inventory of the folders, mappings, workflows and sessions in scope, with object counts
- Repeatable export files and the command set used to produce them
- A dependency map and a list of connections and scheduler settings captured outside the XML
- A gap register of what the XML cannot carry, with an owner for each gap
Also confirm who verifies the connection inventory, and whether rebuilding mappings is part of the same engagement or a later phase.
Can the XML export replace testing of migrated mappings?
No. The XML records design: sources, targets, transformations, ports, links and workflow structure. It does not prove that a rebuilt Hop pipeline behaves the same way at runtime. Behavior depends on session settings, commit and error handling, lookup caching, partitioning and the data volumes each run processes, and much of that is not in the design file. Build a comparison plan before rebuilding. Choose representative runs, capture row counts and checksums from the PowerCenter outputs, and compare them with Hop results on the same inputs. Hop can run pipelines on its native engine, Spark, Flink or Databricks through runtime configuration, so test on the engine you intend to use in production, not only on a laptop.
How DeployOpen works on this
DeployOpen plans, implements, documents and hands over self-hosted open-source platforms inside your own infrastructure. For a PowerCenter export, we turn the XML inventory into a written, fixed-scope plan for rebuilding mappings and workflows in Apache Hop or Apache NiFi, with the gaps named before work starts.
How we scope
- Inventory every exported folder, mapping, workflow, session and parameter file, and record which ones are still in use.
- Agree in writing which PowerCenter objects are in scope, which target engine (Hop or NiFi) each one moves to, and what is excluded.
- Name the items the XML does not carry, such as connection credentials, runtime settings and scheduler dependencies, and assign who supplies them.
How we build
- Rebuild a representative set of mappings as Apache Hop pipelines and workflows, then compare row counts and outputs against PowerCenter results.
- Document the mapping-to-pipeline translation, transform equivalents and any logic that needs manual redesign, so reviewers can trace each change.
- Configure Hop metadata, database connections and environment variables in your own environment, with secrets kept out of exported files.
How we hand over
- Deliver the object inventory, translation log, test evidence and an open-items register as written deliverables for your data team.
- Walk your engineers through the Hop project layout, deployment method and run process so they can maintain pipelines after handover.
- Record which PowerCenter behaviors were verified in testing and which still need confirmation in your environment before cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped separately from the export work.
- Support can cover Hop version upgrades and pipeline changes, with each change tested against the agreed reference outputs.
- Ask any provider, including us, to confirm in writing the support hours, response expectations and upgrade responsibilities before signing.
