Which fits: Pentaho Data Integration or Apache Hop for your ETL estate
Pentaho Data Integration fits teams that want a vendor-supported paid edition and are willing to accept its licensing terms. Apache Hop fits teams that want Apache License 2.0 terms, servers they run themselves and several run targets, including Spark, Beam, Flink, Dataflow and Databricks. This page is written for the team that already runs Kettle transformations (.ktr) and jobs (.kjb) in production and now faces a license, edition or data residency question. Start by confirming how the estate is used today. Pentaho lists its free Developer Edition, formerly Community Edition, for non-production use, so a production workload on that edition is a licensing question before it is a technical one. Check the current terms with Pentaho directly, and ask for the Starter or Enterprise scope in writing if those routes are under consideration.
The decision turns on four things. First, whether you need a vendor to answer for the platform in a contractual sense, with defined support terms and an escalation path, or whether your own engineers and a partner can carry that responsibility. Second, whether your target is still a single server or a cluster that should run on Spark or Beam, since Hop selects these as runtime configurations on the same pipelines rather than requiring a rewrite. Third, what your team can operate: Hop Server is a long-lived process that does not schedule its own work, so you will need an external scheduler or orchestrator, and deployment as Docker images, exported ZIP resources or Git checkouts needs an owner. Fourth, how much of your PDI estate uses steps and connections that the importer converts cleanly. Run the importer on a representative sample and compare outputs against PDI before you commit to a timeline. Your answers to these four questions decide the fit more than feature lists do.
Which option fits which situation
This table matches common Pentaho Data Integration situations with the option that fits better, and the reason. Read each row against your own licensing terms, network rules and run targets, since the Developer Edition restriction and Hop's run options decide most of the answers.
| Situation | Better fit | Reason |
|---|---|---|
| Running the free Developer Edition in production | Apache Hop or a paid Pentaho edition | Pentaho lists the Developer Edition, formerly Community Edition, for non-production use only, so production work needs a different licensing route. Confirm current terms with Pentaho before deciding. |
| Needing a vendor support contract | Paid Pentaho edition, or Apache Hop with a commercial support provider | Apache Hop is Apache-2.0 licensed and maintained by the Apache Software Foundation, which does not offer a support contract. Support must come from a provider you engage, so ask for written scope and response terms. |
| Moving transformations to Spark or Beam | Apache Hop | Hop pipelines can run on Apache Spark natively or through Apache Beam, and on Apache Flink and Google Dataflow through Beam, selected as a runtime configuration. Test converted pipelines on each target before relying on them. |
| Git-based project deployment | Apache Hop | Hop projects can be deployed as Docker images, exported ZIP resources or from a Git checkout, which fits pipeline-as-code workflows. Confirm your CI tooling and secrets handling for each deployment method. |
| Short-lived batch runs in containers | Apache Hop Docker image | The apache/hop image suits short-lived runs, while a long-lived Hop Server can run pipelines on a remote host. Hop Server is not a scheduler, so an external orchestrator must submit the work. |
| Browser-based design for analysts | Apache Hop Web (apache/hop-web image) | The separate hop-web image provides a browser-based Hop Web GUI. Confirm whether the features your developers use are available there before standardizing on it. |
| Running in an air-gapped network | Apache Hop, with images or packages mirrored internally | Hop is installed from artifacts you control, with no license server to reach. Plan an internal mirror for the Java 21 runtime and any database drivers your pipelines need. |
| Keeping existing .ktr and .kjb files | Apache Hop with the Kettle importer | The importer converts .ktr to .hpl and .kjb to .hwf, so existing logic can move without a full rewrite. Expect manual review of same-named connections and metastore content. |
How Hop handles projects, environments and metadata
In Apache Hop, the organizing unit is a Hop project: a folder that holds pipelines (.hpl), workflows (.hwf) and the metadata they reference, and that can be versioned as a Git checkout or packaged as a Docker image or exported ZIP resource. Hop's Kettle importer maps your existing PDI assets into that structure: transformations (.ktr) become pipelines (.hpl), jobs (.kjb) become workflows (.hwf), and kettle.properties and shared database connections become Hop metadata. The practical shift is that connection definitions and variables stop being a shared, per-user file that PDI reads from a home directory and become objects inside a project that travel with the code. Before you rely on the import, open each imported project in the Hop GUI and check that every pipeline resolves its connections and variables without manual edits.
Environment handling is where most PDI estates will need deliberate design. A PDI setup often uses kettle.properties values that differ between development and production servers, with the same transformation pointed at different hosts by changing a file. In Hop, environments are defined separately from projects, so the same project can be run against different sets of variables and connections. The importer also has documented limits you must plan around: it keeps only one copy of same-named database connections, so if your PDI shared connections use one name for two different hosts, you will need to rename or split them before you trust the result. It does not import the PDI metastore either, so any metastore-backed content has to be recreated as Hop metadata.
Confirm metadata behavior in your own setup rather than assuming the import is complete. Test that credentials are supplied through your secret handling and not copied into project files, that a pipeline run on the Hop Server picks up the environment you expect, and that a Docker image built from the project carries the same metadata as your development checkout. Record the decisions in the project documentation, because the import tool does not make them for you. Your data engineers should review each project and environment with the people who own the source and target systems before any scheduled job is moved.
Where Hop pipelines can run and what each target means
The native Hop engine runs a pipeline inside the process that launches it, on a developer workstation or a single server. Nothing else needs to be installed beyond Java 21, which the Apache Hop download page lists as the requirement for Hop 2.19.0. This target suits development, unit-level testing of converted pipelines, and smaller batch loads where a single machine has enough memory and disk for the data.
- Best fit: development, verification of converted Kettle transformations, and small batch jobs.
- Scheduling: the launching process or an external job runner starts it, since Hop itself does not schedule runs.
- Limits: throughput is bounded by one machine, so large volumes usually move to a cluster target.
- Operations: patching the JVM and the Hop installation falls to whoever runs the host.
- Cost: the license is free under Apache-2.0, so the cost is the host and the staff time to run it.
Before you rely on this target for production, confirm with your own test data that memory and runtime meet your service window.
Hop Server is a long-lived process that executes pipelines and workflows on a host other than the designer's workstation. The Hop manual describes deploying projects as Docker images, as exported ZIP resources, or from a Git checkout. It is the closest match to how many PDI teams run Carte-style servers today, but it is not a scheduler. An external scheduler or orchestrator must submit work to it.
- Best fit: shared execution for several teams, or jobs that must run on a host with specific network access.
- Scheduling: cron, a CI/CD pipeline, or an orchestrator such as Airflow or a commercial scheduler has to call it.
- Deployment: the Docker image for a long-lived server and the Git or ZIP options control what version runs where.
- Operations: you own availability monitoring, restarts and log retention.
- Migration note: PDI schedules do not move automatically, so map each one to an external trigger.
Confirm your scheduler's ability to call Hop Server and how your security team wants its access controlled before you choose this target.
Hop pipelines can run on Apache Spark natively or through Apache Beam. This is the target to evaluate when data volume outgrows one machine or when the organization already operates Spark clusters. Hop treats the choice as a runtime configuration on the same pipeline rather than a rewrite, which lowers the cost of trying it, but transform support can differ between engines, so test each pipeline on the target you plan to use.
- Best fit: large batch volumes and teams with existing Spark investment.
- Engine choice: native Spark execution or Beam, selected per pipeline configuration.
- Compatibility: not every Hop transform behaves the same on every engine, so run regression tests on each.
- Operations: cluster administration, capacity and upgrades stay with the platform team or the cluster provider.
- Cost driver: cluster size and hours, which recur for as long as the pipelines run.
Ask your platform team whether the cluster can accept Hop's submitted jobs under your network and identity policies.
Flink and Google Dataflow are reached through Apache Beam. Flink suits teams that already operate streaming infrastructure and want the same Hop pipeline model for continuous work. Dataflow suits organizations standardized on Google Cloud that prefer a managed runner. Both are useful when the workload is streaming or when the cloud footprint is already set, but they add a runner layer that must be tested against each Hop transform you use.
- Flink: a fit where a Flink cluster is already run and operated.
- Dataflow: a managed Google Cloud runner, billed by the service's own usage model.
- Beam dependency: behavior depends on the Beam version and runner, so pin and test them together.
- Migration impact: PDI transformations built for batch often need redesign before they run well as streaming jobs.
- Cost driver: runner usage and data movement, which recur with volume.
Confirm with Google Cloud and your Flink operator the current pricing and support terms for your region and workload, since this page does not publish them.
Hop can also run pipelines on Databricks, selected as a runtime configuration. This target matters when the lakehouse already sits on Databricks, when governance and compute are managed there, and when teams want Hop's visual design with the platform's cluster and storage controls. Databricks is a commercial service, so the platform cost is separate from Hop's Apache-2.0 license, and that cost recurs with compute use.
- Best fit: organizations with Databricks already contracted for analytics and storage.
- Governance: access to data and clusters follows the Databricks workspace controls.
- Cost split: Hop is free, while Databricks compute and storage are billed by the vendor.
- Portability: pipelines tied to Databricks runtime settings are less portable to other targets.
- Verification: test each transform against the Databricks runtime version you run.
Ask Databricks for a quote based on your expected compute hours and storage, and confirm with your Hop team which transforms you depend on.
What the license means for production use
Pentaho's free Developer Edition and its paid routes carry different terms, while Apache Hop ships under a permissive open-source license with a newer runtime requirement. The cards below cover what each option allows, what it requires, and what to confirm before you commit a production workload.
Developer Edition is non-production only
Pentaho lists its free Developer Edition, formerly Community Edition, for non-production use only. Teams that have quietly run transformations on it for scheduled loads are outside those terms. Confirm the current Developer Edition terms in writing before deciding whether any existing job stays where it is. Keep a dated copy of the terms you rely on.
Paid Starter and Enterprise routes
Production use of PDI means buying a paid edition, either Starter or Enterprise. Pentaho does not publish prices on the pages we reviewed, so the cost is set by quote. Ask which edition covers your deployment model, how many servers or users the license counts, whether support and updates are included, and how renewals are priced.
Apache-2.0 terms for Apache Hop
Apache Hop is licensed under the Apache License 2.0, which permits commercial production use, modification and redistribution under its terms. Your legal team should still review the license text and any third-party components in your build. The license does not cover the databases, cloud services or Spark and Beam clusters your pipelines connect to.
Java 21 for Hop 2.19.0
Apache Hop 2.19.0 requires Java 21. Confirm that your hosts, container base images and JVM patch policy support it, and check whether any existing Kettle jobs call Java steps or libraries that need changes. Older Java versions in your estate may need an upgrade plan before the Hop server can be deployed.
No per-seat fees for self-hosting
Apache Hop has no license fee per developer, user or server. Your recurring costs move to the infrastructure that runs Hop Server, the people who maintain pipelines, and any support contract you choose to buy. Model these as separate line items so that a later growth in pipeline count does not look like a licensing event.
Get the edition terms in writing
Before you migrate, ask Pentaho for written confirmation of the terms that apply to your current edition, deployment and usage. Ask your procurement team to record the answer alongside your contract. This keeps the migration decision grounded in the terms you actually hold, not in a summary of them.
Data location, hosting and compliance implications
Apache Hop runs wherever you deploy it, so the data location question becomes a deployment decision rather than a licensing one. Hop pipelines can run on a local Hop GUI, on a Hop Server you operate, or on a Spark, Beam, Flink or Databricks target you already control. Projects can reach those runtimes as Docker images, as exported ZIP resources or from a Git checkout. If you choose on-premises or private cloud runs with connections to databases inside your network, rows read from source systems stay inside your network boundary. Confirm that the Hop Server, the Hop Web GUI and any metadata repository sit in the same zone as the sources they read, and that your Git host and container registry are also in scope for your assessment.
Pentaho's own hosting and support options are a different question, and you should confirm them with Pentaho directly rather than assume them from the Developer Edition documentation. Ask whether the paid Starter or Enterprise routes can be installed on your servers, whether any component phones home to a vendor service, what telemetry or license checks are performed, and which support channels handle data that may appear in tickets or logs. Get the answers in writing and record them in your third-party risk file, because they determine whether PDI is currently a data flow to a vendor or only software on your hosts. The same questions apply to any managed or cloud-hosted option Pentaho offers.
DeployOpen can help you prepare the controls and evidence an assessor will ask for during a migration, such as network diagrams for each Hop runtime, access reviews for the Hop Server, configuration baselines for the Docker images, and logs showing where converted pipelines read and write. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree with your assessor early which evidence they need and which frameworks apply to your environment.
Cost components on each side, one-time and recurring
Pentaho's cost sits mostly in license and support fees, which recur, while Apache Hop's license is free and its costs fall into infrastructure, conversion and staff time. Both sides need the same underlying work: running servers, scheduling jobs, and proving the converted output matches what PDI produced.
Pentaho license and support fees
Pentaho publishes no prices for its paid Starter and Enterprise editions, so the figure you need comes from a written quote. Ask whether fees are charged per server, per core, per user or per subscription term, whether support is bundled, and how renewal increases are capped. These fees recur for as long as you run the paid editions, and they are the main cost you can remove by moving to Apache Hop.
Apache Hop license and project
Apache Hop carries no license fee. It is Apache-2.0 licensed, so the cost of the software itself is zero, but you still pay for the Java 21 runtime, the platform hosting it and the people who maintain it. Confirm which Hop release your standards require, since Apache Hop 2.19.0 requires Java 21, and plan upgrades as part of routine operations.
Servers and Hop Server capacity
Hop pipelines run locally or on a long-lived Hop Server, and capacity depends on job count, data volume and how many environments you keep, such as development, test and production. Recurring infrastructure costs grow with the number of Hop Server instances and the compute they need, while Spark, Beam or Databricks run targets add cluster costs. Ask your team to size these from a load profile of your actual jobs.
Scheduler and orchestration
Hop Server is not a scheduler, so an external scheduler or orchestrator must submit work. Pentaho's scheduling may already run inside its server, so the replacement is a one-time design and build effort plus a recurring tool to operate. Check whether you already run an enterprise scheduler you can reuse before you buy or staff a new one.
Conversion and testing effort
The importer converts .ktr and .kjb files, kettle.properties and shared database connections, but it leaves manual work. The importer keeps only one copy of same-named database connections, does not import the metastore, and steps without a Hop equivalent need rebuilding. This is a one-time cost, and it scales with job count and the number of custom steps. Testing converted pipelines against PDI output is part of the same one-time effort and should be budgeted together with conversion.
Staff time and external support
Your own engineers carry the recurring work of operating, patching and upgrading Hop, while external support is an optional recurring spend. Support can be a fixed-scope conversion project, a one-time migration with handover, or a retainer for ongoing upgrades and fixes. Ask any partner for a written scope with deliverables and timelines, and ask what happens to your runbooks and tests when the engagement ends.
What a move from Pentaho involves at a high level
The sequence turns Pentaho jobs, transformations and connections into Apache Hop projects that run on a tested, scheduled and deployed footing, with PDI kept alive until the outputs match. Each step closes with a check so the cutover decision rests on evidence rather than on the import tool's output alone.
Inventory transformations, jobs, connections and schedules
The Pentaho owner or platform engineer lists every .ktr transformation, .kjb job, shared connection, kettle.properties entry and the scheduler that triggers each job, noting which ones feed downstream systems. Record who consumes each output and how often it runs. The inventory is complete when every production job maps to a named owner, a schedule and a target dataset, and the team agrees the list with the business owners.
Import with hop-import or the GUI
A Hop developer runs the importer from the Hop GUI through File, then Import from Kettle/PDI, or from the hop-import command-line tool, against a copy of the PDI project rather than the live repository. The import produces workflows (.hwf), pipelines (.hpl) and Hop metadata from the Kettle files. The step is done when every source file has either a converted Hop counterpart or an entry on the exception list.
Review duplicate connections and metastore gaps
The developer checks the import log for same-named database connections, because the importer keeps only one copy, and confirms which connection each pipeline should use. Any objects that lived in the Pentaho metastore rather than in project files are inventoried separately and recreated by hand in Hop metadata. The review closes when each connection has one documented definition and each metastore object has a Hop equivalent or a documented replacement.
Replace steps without a Hop equivalent
For every transformation step or job entry that the importer cannot convert, the team selects a Hop transform or action, writes a small custom plugin, or moves the logic into a script or another tool in the pipeline. Owners sign off on each replacement because behavior differences often sit in null handling, date formats and error routing. The step is complete when the exception list is empty or each remaining item has an approved workaround.
Test converted pipelines against PDI output
Testers run each converted pipeline on the same input data used by the PDI job, then compare row counts, column values and error outputs with the stored PDI results. They repeat the comparison with representative edge cases such as empty files and malformed records. The step closes with a signed comparison report for each job, showing the accepted differences, and the data owner approves the results before any production run uses Hop.
Deploy Hop Server or Docker images
The platform team packages the tested projects as the apache/hop Docker image for short-lived runs, or deploys a long-lived Hop Server, and can also deliver the project as an exported ZIP or from a Git checkout. Hop Web is available as a separate image if authors need a browser-based GUI. The deployment is confirmed when a test run from the target environment completes and its logs reach the team's monitoring stack.
Move schedules to an external orchestrator
Because Hop Server does not schedule work, the team recreates each Pentaho schedule in an external scheduler or orchestrator that submits the workflow or pipeline to Hop Server. Owners confirm the trigger times, retry rules, alerting and dependencies between jobs match the inventory from the first step. The move is verified when the orchestrator's run history matches the expected schedule for a full cycle of the business calendar.
Run in parallel before cutover
PDI and Hop run side by side for a agreed period, with Hop outputs written to a staging location and compared to PDI outputs on each run. Discrepancies are logged, fixed and retested. Cutover happens only after the data owners accept the parallel results, and PDI is kept available for rollback until the owners agree it can be retired. The cutover is complete when all production consumers read from Hop outputs and the retirement decision is recorded.
Questions buyers ask before switching from Pentaho
What does it cost to switch from Pentaho Data Integration to Apache Hop?
The Apache Hop license is free under the Apache License 2.0, so the cost is the work around it. Plan for four components: the conversion and rework of existing jobs and transformations, the servers or cloud capacity that run Hop Server or containers, the people who test and operate the new pipelines, and any support contract you choose to buy. Conversion and testing are one-time costs. Servers, scheduling infrastructure and support recur. The biggest drivers are how many PDI jobs use steps without a direct Hop equivalent and how many database connections need cleanup. Ask any vendor for a written scope that lists these items separately. For a line-by-line comparison, see the Pentaho Enterprise Edition cost vs self-hosted Apache Hop breakdown in the sibling cost page.
How long does a Pentaho to Apache Hop migration take?
No duration is fixed by the platforms themselves, so the timeline depends on the estate you are moving. The main variables are the number of transformations and jobs, how many use steps you must replace, how many duplicate database connections need review, how many schedules must be rebuilt outside Hop, and how much test coverage exists to compare outputs against the original PDI results. Hop's importer converts .ktr and .kjb files in one pass, but converted artifacts still need functional testing before cutover. Ask for a fixed-scope plan with milestones for inventory, conversion, parallel runs and schedule cutover before agreeing dates. The sibling migration page walks through the steps in order.
Can our team migrate from Pentaho to Apache Hop without outside help?
Yes, many teams do it in-house, especially where PDI developers already understand their pipelines and have a test harness. The work is manageable when the estate is small and the job logic is well documented. Outside help becomes more valuable when you have many production jobs, undocumented transformations, custom plugins, or tight audit requirements for proving that outputs match. Be realistic about skills: the team needs Java 21 familiarity for the runtime, comfort with Git and containers for deployment, and someone who owns scheduling after cutover. DeployOpen plans, implements and documents this kind of migration under a written scope, if you prefer to hand off part of the work.
Does Apache Hop support all the steps Pentaho Data Integration uses?
Hop covers most common ETL patterns, but not every PDI step has a one-to-one equivalent, and the importer does not carry over every element. Hop lists more than 250 pipeline transforms, 80+ workflow actions and 40+ database dialects, which covers much of typical PDI work. Some steps, custom Java plugins and metastore-dependent logic will need manual redesign. Inventory every step type used across your .ktr and .kjb files before committing to a timeline, then mark each one as converted, replaced or rebuilt. The Hop manual's Kettle import documentation lists the known limitations, including duplicate connection names and the absence of metastore import.
Do we need Apache Spark or Apache Beam to run Hop pipelines?
No. Hop pipelines run on the native Hop engine, locally or on a remote Hop Server, and that covers many workloads. Spark, Beam, Flink, Google Dataflow and Databricks are runtime options you select through configuration when data volumes or cluster processing justify them. Changing the run target does not require rewriting the pipeline. Decide based on your current PDI throughput and where the data lives. If your PDI jobs already run comfortably on a single server, start with the native engine and add a distributed runtime only when a measured need appears. Confirm the chosen runtime's operational requirements with your platform team before design freeze.
What support options exist for Apache Hop in production?
Apache Hop is a community-maintained Apache Software Foundation project, so there is no vendor contract included in the license. Your support options are community channels and documentation, internal staff who maintain the platform, and external services you buy under a written scope. Ask any provider which parts of the stack they cover: the Hop project, the Java runtime, the container images, the scheduler that submits work to Hop Server, and the databases behind your pipelines. Support recurs as an ongoing cost, while the initial migration is one-time. DeployOpen offers implementation, hardening, backup, upgrades, documentation and retainer-based support for self-hosted platforms in your own infrastructure.
Can we keep using the Pentaho Developer Edition in production?
Pentaho lists its free Developer Edition, formerly Community Edition, for non-production use only, so running it in production would conflict with that stated scope. Confirm the current terms directly with Pentaho before deciding, because licensing details can change. Production teams generally choose between a paid Pentaho route and a migration to Apache Hop under the Apache License 2.0. The sibling page on Developer Edition production use covers the paid Starter and Enterprise routes and what a move to Hop involves. Whichever you choose, document the decision and its basis for your compliance records.
How do we deploy and schedule Hop pipelines once they are converted?
Hop Server runs pipelines and workflows, but it is not a scheduler, so an external scheduler or orchestrator must submit the work. Plan that component early. Hop projects can be deployed as Docker images, as exported ZIP resources or from a Git checkout, and Hop publishes the apache/hop image for short-lived runs or a long-lived server, plus apache/hop-web for the browser-based GUI. Decide which scheduler your teams will use, how credentials and environment settings are injected, and how logs and failures are monitored. Test these paths in a non-production environment before moving any scheduled job, and confirm the deployment model against the Hop deployment documentation.
How DeployOpen helps evaluate, implement or migrate Apache Hop
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Apache Hop. For a Pentaho Data Integration exit, that work usually starts with an inventory of the existing .ktr and .kjb files, the shared.xml and kettle.properties files, and the schedules that call them, so the team can see which items the Hop importer converts cleanly and which need manual rework. The result is a scoped plan, not a guess about effort. Whether the target is a single Hop Server, Hop Web on Docker, or a Spark or Beam run target, the decision should rest on the inventory.
Most engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and that document covers the items in the inventory, the environments to build (for example development, test and production), the metadata and connection rules, the test approach for comparing converted pipelines with PDI output, and who signs off each stage. Because Hop Server does not schedule work, the written scope should also name the external scheduler or orchestrator that will submit jobs and who owns it after handover. Ongoing support, upgrades and continuous testing are available as retainers, which suits teams that will keep Hop current through releases such as the 2.19.0 line. DeployOpen does not publish a price list. A quote follows from the written scope, so the most useful thing to bring to a first call is the inventory and a list of the outcomes you need.
DeployOpen does not hold partner, reseller or certified status with the Apache Software Foundation or Pentaho, and it does not issue audit reports or certifications. Where your organization needs compliance evidence for the new pipeline platform, DeployOpen can prepare the configuration, access controls and records that an independent assessor would review, while the assessor provides the opinion. Ask any provider, including DeployOpen, to state in the written scope which tasks they perform, which the client performs, and which the client's own auditors or licensing advisers must confirm.
