Keeping ETL on-premises after PowerCenter support ends
If PowerCenter has to stay on your own servers, Informatica's main forward path leads to its cloud service, Intelligent Data Management Cloud (IDMC). A self-hosted stack built on Apache Hop for batch ETL and Apache NiFi for continuous data flows can meet that on-premises constraint, and both projects are licensed under Apache-2.0 with no vendor license fee. The move is a rebuild rather than a conversion, so the decision in front of you is which workloads go to which tool and in what order. Informatica announced that PowerCenter 10.4 support ended March 31, 2024, after which that version moved to fee-based Extended Support. The options Informatica named were modernizing to IDMC, buying Extended Support, or upgrading to PowerCenter 10.5. Only the cloud path is a modernization in the vendor's own framing, so if your constraint is that data and processing stay on your servers, confirm with Informatica in writing whether 10.5 and any Extended Support terms cover your version, your support period and your deployment model before you commit budget to either. Before you pick a target, inventory the PowerCenter estate with your team: mappings, workflows, schedulers, connections and the systems they touch. Check which items are batch transformations, which are file or API ingestion, and which depend on PowerCenter-specific behavior. Plan a phased cutover in which the old and new schedulers run side by side for each workload until outputs reconcile. Ask any implementation partner to price the inventory and the rebuild as a fixed scope with written deliverables, because that work, not the software, sets the timeline.
What an on-premises ETL platform must satisfy
Once PowerCenter leaves support, the replacement has to run jobs inside your network without a vendor-hosted control plane, on a runtime your security team can patch. The four requirements below connect runtime choice, identity, clustering and job execution, and each one is a decision to settle before the first pipeline is rebuilt.
No vendor-hosted control plane
Confirm that scheduling, job submission and execution can run entirely on servers you control, with no outbound dependency on a vendor SaaS service to start or monitor a job. Apache Hop's Hop Server executes pipelines and workflows but is not a scheduler, so you must choose and host an external scheduler or orchestrator that submits work. Write down where job definitions, metadata and run logs are stored, and who can read them.
A supported Java 21 runtime
Java 21 is the minimum runtime for Apache Hop 2.19.0, released on August 17, 2026, and for the NiFi 2.x line, which the NiFi administration guide lists as its minimum. Plan the JDK, its patch cadence and your vulnerability scanning around that baseline before any installation. NiFi 1.x is out of maintenance because its Jetty, Spring and AngularJS dependencies cannot be upgraded, so it should not be the target.
Authentication that fits your directory
NiFi supports single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication, while its Kerberos provider is deprecated. Hop Web and Hop Server need their own access controls, so decide how operators, developers and service accounts authenticate to each component. Confirm which method your identity provider supports, and test group mapping before go-live.
Secure binding and network exposure
When NiFi has no security configuration, it binds to 127.0.0.1, so the UI is reachable only from the local host. Any move to a shared server therefore requires explicit TLS, authentication and listener configuration before users can reach it. Review which ports are open between the ETL nodes, source systems, warehouse and the scheduler, and document each flow.
Clustering that matches your network
NiFi clusters coordinate through ZooKeeper, either embedded or external, or on Kubernetes through ConfigMaps or Leases for state and leader election. Choose the model your operations team can run and monitor, and confirm that cluster traffic can stay on your internal network. Hop scales differently, through remote Hop Servers and Spark, Flink or Beam execution, so the topology should be drawn before hardware is requested.
Where PowerCenter and IDMC meet the constraint
PowerCenter runs on your own servers, but whether you can keep it there depends on what your vendor agreement supports. Informatica announced that PowerCenter 10.4 support ended March 31, 2024, after which customers moved to fee-based Extended Support. The options Informatica named were modernizing to its cloud Intelligent Data Management Cloud (IDMC), buying Extended Support, or upgrading to PowerCenter 10.5. Only the 10.5 path keeps the existing installation on premises, so it deserves the closest review before any cloud decision is made. The Informatica announcement is the starting point for that review.
IDMC is a cloud service, so it moves processing and the control plane out of your data center. That is a separate question from whether your existing mappings can keep running where they run today. Before you commit budget to either path, get written answers from Informatica on what 10.5.x support covers, the end date for that support, whether security fixes and patches are included, what Extended Support costs, and whether it applies to 10.5 at all. Ask whether any on-premises deployment option remains for IDMC components, because the documentation you read will likely lead with cloud. Do not plan around a support date that is not in writing.
Turn the vendor answers into an internal decision record. List every PowerCenter component in use, including the repository, integration services, nodes and grids, database and application connections, the scheduler that starts workflows, and the operating systems and databases beneath them. Note which team owns each mapping and how often it runs. This inventory decides the phase plan: an extended support agreement or upgrade buys time to rebuild, while a self-hosted Apache Hop and Apache NiFi stack needs the inventory to show which workloads can move first. Record the decision date and the vendor's written support statement so the next renewal starts from that document.
Apache Hop, Apache NiFi or both: which option fits which workload
Apache Hop fits batch ETL, where mappings read from databases or files, transform the data and write to a target on a schedule. Pipelines and workflows are designed on the Hop GUI canvas and run on the native Hop engine locally or on a remote Hop Server. For larger volumes, the same pipelines can run on Apache Spark, Apache Flink, Google Dataflow through Apache Beam, or Databricks, selected as a runtime configuration.
- Execution engines: The native engine covers most batch work. Spark, Flink, Beam and Databricks are runtime choices, so you test the same pipeline on each before committing.
- Kettle importer: Hop imports Kettle jobs and transformations (.kjb, .ktr) and shared connections. It does not import PowerCenter, so PowerCenter mappings must be rebuilt by hand.
- Hop Server is not a scheduler: It executes work that something else submits. Plan an external scheduler or orchestrator for every batch window.
- Java 21 baseline: Hop 2.19.0 requires Java 21, which affects server images and JVM patching.
Confirm with your team which PowerCenter mappings are batch and which are event-driven before assigning them to Hop. Confirm the Hop version and Java build against your security baseline.
Apache NiFi fits continuous flows: file and API ingestion, routing, enrichment and delivery to downstream systems, often with back pressure and per-flow provenance. It is a poor fit for heavy batch transformation that PowerCenter currently performs in large joins and aggregations. Flows are configured in the browser, and NiFi 2.12.0 was released on September 13, 2026.
- 1.x end of support: NiFi 1.28.1 reached end of support on December 8, 2024. The project states that 1.x cannot be maintained further because of Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8.
- 2.x migration path: Upgrade to NiFi 1.27.0 first, then to 2.0.0, and convert
flow.xml.gztoflow.json.gz. The variable registry scope and distributed map cache components changed in 2.0. - Runtime: Java 21 is the minimum. Python processors need Python 3.10, 3.11 or 3.12 and are a beta feature, so avoid them for production flows until you have tested them.
- Authentication: Single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 are supported. Kerberos is deprecated.
Confirm which of your flows depend on Python processors and which identity provider you will federate with before you choose the authentication method.
Many PowerCenter estates contain both batch mappings and file or API feeds. A combined stack assigns each workload to the tool built for it: NiFi moves and routes data as it arrives, and Hop transforms it in scheduled pipelines. The boundary between them is a landing zone, a queue or a database table, and that boundary needs its own ownership and monitoring.
- Clear handoff contract: Define the file format, the landing path or topic, and the completion signal before either tool is built.
- Two runtimes to operate: NiFi clusters and Hop Servers each need patching, backups and capacity planning, which adds recurring operations effort.
- Shared orchestration: An external scheduler such as Apache Airflow can trigger Hop workflows and monitor NiFi flows from one place, if your team already runs one.
- Skills split: Hop favors developers comfortable with metadata-driven pipelines, while NiFi favors operators comfortable with flow tuning. Staff accordingly.
- Gaps in both: Neither includes the data quality, catalog or managed cloud services that PowerCenter's surrounding Informatica products provide.
Ask for a written inventory that maps every PowerCenter workflow to one tool before any build starts, and confirm who owns each boundary.
How each option meets the constraint, and its trade-offs
This table compares Apache Hop, Apache NiFi and a combined stack against the constraint of keeping ETL on your own servers after PowerCenter support ends. Read each row as a question to answer in your own environment, since several cells name what you must confirm before committing. The main takeaway is that both projects run on-premises under Apache-2.0, but scheduling, lineage and enterprise authentication setup fall to your team.
| Requirement | Apache Hop | Apache NiFi | Combined stack (Hop plus NiFi) |
|---|---|---|---|
| On-premises execution | Runs on the native Hop engine locally or on a remote Hop Server on your hosts | Runs as a self-managed cluster on your servers, with ZooKeeper or Kubernetes for coordination | Hop handles batch transforms on your hosts, NiFi handles continuous ingestion on your hosts |
| Runtime requirements | Java 21 for Hop 2.19.0; Docker images available for Hop Server | Java 21 minimum; Python 3.10 to 3.12 only for optional Python processors | Two Java 21 runtimes to patch and monitor, plus Python if NiFi uses Python processors |
| Version path | Confirm the current release line on the download page before pinning | Start on NiFi 2.x; NiFi 1.x is end of support, so confirm the 1.27.0 upgrade step if migrating old flows | Pin both projects to their current lines and track their release notes separately |
| Authentication | Depends on how Hop Server or Hop Web is fronted; confirm access controls with your security team | Single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 are supported; Kerberos is deprecated | Use NiFi's identity options for flows and a reverse proxy or gateway for Hop endpoints |
| Default network exposure | Confirm bind addresses and TLS for Hop Server and Hop Web in your configuration | Binds to 127.0.0.1 when no security configuration is provided, so you must configure it deliberately | Both need explicit network policy before any shared access |
| Scheduling | Hop Server is not a scheduler; you must add cron, Airflow or another orchestrator | Scheduling is built into flows, but enterprise job calendars usually still need an external tool | Typically an external orchestrator triggers both, so you must design dependencies and retries yourself |
| Lineage and metadata | Hop metadata and project files are stored in Git or ZIP exports; confirm what lineage your audit needs | Flow definitions and versions can be tracked through Git flow registry clients; field-level lineage is not described in the supplied material, so confirm | Lineage gaps usually sit at the boundary between the two tools and need a documented convention |
| What you must add | Scheduler, secrets handling, monitoring, Kettle import review and a data catalog if required | Monitoring, clustering design, flow registry setup, and any data quality or catalog services | Both sets of operational work plus integration tests across the handoff between tools |
Phasing the move from PowerCenter to self-hosted Hop and NiFi
This sequence moves PowerCenter workloads to self-hosted Apache Hop and Apache NiFi in controlled batches, so each workload runs on the new stack and is verified before PowerCenter is retired.
Inventory PowerCenter objects with pmrep exports
The team lead for PowerCenter, with a repository administrator, exports the folders, mappings, sessions, workflows, worklets and connection definitions using the documented XML exports from Repository Manager or pmrep ObjectExport. Record each object's source and target, schedule, owner and downstream consumer in one register. The step is done when every production folder appears in the register and someone outside the ETL team has reviewed it for missing consumers. Expect the XML to omit runtime behavior and connection secrets, so note those separately.
Classify workloads by pattern and risk
Architects sort the register into groups: batch transformations, file and API ingestion, continuous routing, and workloads tied to regulatory reporting or customer-facing data. Batch transformations usually suit Hop pipelines, while continuous flows and ingestion usually suit NiFi. Mark each group by business criticality and by the data classification rules that apply to it. The step is done when each object has one target platform and one risk tier, and the list of workloads needing parallel running is agreed in writing.
Stand up Hop Server and NiFi 2.x in a test environment
The platform engineering team installs Java 21 on the test hosts, then deploys Hop Server and a NiFi 2.x cluster or standalone node inside the organization's own network. Use NiFi 2.x for new work, since the NiFi project encourages upgrades to version 2 and 1.28 is the last 1.x minor release. Configure authentication with the provider the organization already uses, and confirm NiFi binds to its intended interface rather than the default loopback address. The step is done when a sample pipeline and a sample flow run end to end and the configuration is stored in version control.
Choose and implement the external scheduler
Hop Server does not schedule work, so the team selects an external scheduler or orchestrator to submit pipelines and workflows, and decides whether PowerCenter's existing schedules move to it or are rebuilt. Confirm that the scheduler can reach Hop Server securely and can capture run status and logs for audit. Document which jobs were previously chained by PowerCenter workflows so dependencies carry over. The step is done when every batch job in the first wave has a scheduled trigger and an alert path for failures.
Rebuild the first batch of mappings and run in parallel
ETL developers rebuild a small first batch of mappings as Hop pipelines and workflows, using the register as the specification, and run them alongside the PowerCenter originals against the same inputs. Compare row counts, checksums, reject files and target table contents for each run over a representative set of business cycles. Record every difference and classify it as a defect, an expected change or a source data issue. The step is done when the outputs match or each difference has a signed-off explanation.
Rebuild remaining mappings in batches
The team repeats the rebuild and parallel-run cycle in batches ordered by the classification from earlier, moving NiFi flows for continuous ingestion in the same way. Keep the register updated with status per object, and keep shared connections and reusable transformations in one place under version control. Review each batch with the data owners before it is marked ready. The step is done when every object in the register has a built replacement and a parallel-run result.
Cut over by workload and keep a rollback path
The operations lead switches each validated workload from PowerCenter to its replacement one group at a time, starting with lower-risk jobs. The PowerCenter definition and its schedule remain in place but disabled for the cut-over workload, so the team can reverse the change if a reconciliation fails. Monitor run times, error rates and downstream reports during an agreed observation period. The step is done when each workload has run on the new platform through its observation period with reconciled outputs.
Retire PowerCenter after archive and sign-off
Once no workload depends on PowerCenter, the team archives the repository, exports final object definitions, and stores them under the retention rules the organization applies to ETL records. Confirm with the compliance and security owners that the archive, access logs and lineage evidence are retained as required, then decommission the PowerCenter servers and revoke their credentials. The step is done when the archive is verified, the sign-off record names the owners, and the servers are removed from the inventory.
Questions buyers ask before hiring help for an on-premises ETL move
What drives the cost of moving PowerCenter workloads to self-hosted Apache Hop?
The main drivers are the number of mappings and workflows to rebuild, how many of them are complex, and how many source and target systems they touch. Costs fall into one-time work (inventory, design, rebuilding pipelines, testing, cutover) and recurring work (server infrastructure, patching, Java and Hop upgrades, monitoring, backups and support). Ask any provider to price each of these separately so you can see who is paid for what. Ask for a quote tied to a written inventory, because an estimate made without one usually changes once the mappings are read. Compare that quote with the Extended Support or IDMC consumption you would otherwise keep paying, using your own contract terms.
Can our own engineers move ETL off PowerCenter without outside help?
Often yes, if the team has real ETL experience, a clear inventory and time to do the work alongside production duties. Apache Hop and Apache NiFi are both Apache-2.0 projects with no license fee, so the constraint is skill and capacity rather than purchase. Teams usually struggle with undocumented mappings, business logic that exists only in the code, scheduling dependencies and testing against production-like data. Outside help is most useful for the discovery phase, for a pilot pipeline that sets patterns, and for cutover. Decide this from a skills assessment of your own staff, not from a general assumption.
How long does the migration take and what sets the pace?
The pace is set by the size and complexity of the inventory, the number of dependencies between jobs, the quality of test data and the number of people who can approve changes. Your release calendar, change freezes and the need to run old and new flows in parallel also matter. Timelines should come from a written plan that breaks the work into phases, not from a general rule. Ask any provider to show how they will sequence low-risk batch jobs before critical ones and how they will validate row counts and business results at each step. Confirm the PowerCenter support end date that applies to your version with Informatica before you set the target date.
What does the migration need from our internal staff?
You will need named owners for the business rules behind each data flow, database administrators for source and target access, a Linux or Kubernetes operations team for the new servers, and a security reviewer for authentication and network placement. Someone must also decide which data quality checks must be reproduced and who signs off on reconciliation results. Plan time for these people during discovery, testing and cutover, because their availability often sets the schedule more than the engineering work does. If your staff cannot give this time, the engagement will need more outside support or a longer timeline.
Is there a conversion tool that turns PowerCenter mappings into Hop pipelines?
No automatic PowerCenter importer exists for Apache Hop. Hop's documented importer converts Kettle (Pentaho Data Integration) jobs and transformations, along with kettle.properties and shared database connections, but it does not read PowerCenter repositories. That means PowerCenter mappings, workflows and session settings are normally rebuilt by hand, using the pmrep XML exports as the specification. Ask any provider how they will handle transformations that have no direct Hop equivalent, how they will carry over connection details securely, and how they will confirm that results match the original output.
What does a fixed-scope DeployOpen engagement cover?
A fixed-scope engagement covers the agreed deliverables, such as the inventory, target architecture, a self-hosted Apache Hop or NiFi stack in your infrastructure, rebuilt pipelines for an agreed set of workloads, testing, hardening, backup configuration, documentation and cutover support. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Anything outside the written scope, such as rebuilding every workflow in the estate or ongoing operations, would be a separate agreement. Ongoing support, upgrades and continuous testing are available as retainers.
Who owns the data, credentials and servers after the engagement ends?
The organization owns the data, the pipeline designs, the configuration and the servers, because everything runs inside your own cloud accounts, data centers or air-gapped networks. Credentials should be stored in a secrets manager you control, not in pipeline files, and access should be reviewed before handover. Ask for written documentation, source code in a repository you control, and a runbook for upgrades and backups. Confirm in the contract who holds administrative accounts at handover, and make sure your own staff can operate the platform without the provider.
Evidence auditors and regulators ask for under this constraint
Auditors and regulators do not ask for one document. They ask whether the migration can be traced, configured, operated and reversed. These four evidence sets connect the workload inventory to the running systems. DeployOpen prepares this evidence in your environment, but independent auditors and certification bodies issue any audit report.
Inventory of every PowerCenter workload
Reviewers start with a list of every mapping, workflow, session, schedule and connection, and with the reports or regulatory submissions each one feeds. Export the repository objects with Repository Manager or pmrep ObjectExport, then record each object's owner, sources, targets and business purpose in a register. Give every item a successor flow ID in Apache Hop or NiFi. Confirm that each workload has either a mapped successor or a signed retirement decision before the PowerCenter servers are switched off.
Authentication and access configuration
Reviewers test who can design, run and administer flows, so this is usually the first control they examine. For NiFi, document the configured provider from single-user, LDAP, OpenID Connect, SAML 2.0 or X.509 client certificates. The Kerberos provider is deprecated, so do not choose it for a new deployment. Keep the access configuration under version control, record any change from the loopback default for each environment, and confirm how Hop Server and Hop Web authenticate in your setup.
Deployment and patch records
For each runtime node, keep the exact product version, the Java runtime, any Python version used by optional NiFi processors, and the change ticket that approved the installation. NiFi 1.x can no longer be maintained because its Jetty, Spring and AngularJS dependencies cannot be upgraded in that line, so a 1.x build in production is an open audit finding. Hop 2.19.0 also requires Java 21, so one runtime baseline should cover both tools.
Tested backup and rollback procedures
A backup proves little until someone restores it. Back up the NiFi flow definitions, the flow configuration file, the repositories and the keystores, and record where each copy is stored. Run a restore drill on an isolated host, then compare row counts and checksums with the output of the PowerCenter run. Keep the PowerCenter repository backup and the old schedules intact through the parallel run, so a documented rollback is possible until cutover is signed off.
How DeployOpen deploys Apache Hop and NiFi on your infrastructure
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including data centers and air-gapped networks. For an on-premises PowerCenter replacement, we start from a written scope that names the workloads, servers, connections and controls each phase covers before any build work begins.
How we scope
- Inventory PowerCenter workflows, mappings and schedules using your repository exports, then agree which move to Apache Hop and which go to NiFi.
- Define the target Hop and NiFi topology on your own servers, including Java 21 runtimes, Hop Server hosts and NiFi cluster nodes.
- Record the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope and priced from that document.
How we build
- Rebuild selected mappings as Hop pipelines and workflows, and configure NiFi flows for continuous ingestion and routing.
- Set up authentication for NiFi through your chosen provider, such as LDAP, OpenID Connect or SAML 2.0, and avoid exposing the UI beyond loopback until configured.
- Test each rebuilt job against PowerCenter output on representative data, and record reconciliation results for each batch and flow.
How we hand over
- Deliver runbooks for deploying Hop projects as Docker images, exported ZIP resources or Git checkouts, with the scheduler that submits work documented.
- Document NiFi cluster coordination, whether ZooKeeper or Kubernetes, along with backup, upgrade and credential rotation procedures.
- Provide evidence packs covering access controls, job logs and change records that your internal or external auditors can review.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
- Plan NiFi version upgrades within the 2.x line and confirm the flow.json.gz migration steps against the current project guidance before each change.
- Confirm with your team which Hop and NiFi versions are approved, and agree how security patches and Java updates are tested in your environment.
