Running Pentaho Developer Edition in production: what the license limits mean
A team running production ETL on the free Developer Edition, formerly Community Edition, must choose between a paid Pentaho route and moving to Apache Hop under the Apache License 2.0. Pentaho lists the Developer Edition for non-production use only, so the license question is who may run these jobs in production, and under what support terms. The paid routes are the Starter and Enterprise editions. Confirm in the order form exactly which production rights, support levels and update entitlements each edition carries, because the answer determines whether the current setup is compliant today. Apache Hop has no license fee, but the organization then carries the cost of servers, conversion, testing and any support it buys or staffs internally.
If the team moves to Hop, the first check is how much of the existing estate converts. Hop's importer reads .ktr transformations, .kjb jobs, kettle.properties and shared database connections, and it runs from the GUI or the hop-import command-line tool. Its documented limits matter for planning: only one copy of same-named database connections is kept, and the metastore is not imported, so those items need manual review. Hop 2.19.0 was released on August 17, 2026 and requires Java 21, which should be confirmed against your hosts. Apache Hop's import guide lists the converted artifacts and their limits.
The trade-off is between recurring license and support fees and internal effort. A paid Pentaho edition buys vendor support and a settled production position, but it recurs each term and the quote should show the edition, support scope and term length. Hop removes the license line but adds scheduling work, because Hop Server executes pipelines and workflows without scheduling them, so an external scheduler must submit the work. Ask Pentaho for a written quote covering production rights, support and renewal terms, and inventory your jobs and schedules before comparing totals.
What production use requires from your ETL platform
Production use turns a development tool into a service with obligations: a license that covers the workload, schedules that run without a person, controlled releases, and someone to call during an incident. The cards below set out what each obligation requires and what to confirm before you migrate.
A licensed route for production
Pentaho's free Developer Edition is for non-production use, so every production pipeline needs a paid route, either Starter or Enterprise. Ask Pentaho in writing which edition covers production servers, how many environments it covers, whether test and disaster recovery copies are included, and what happens to licensed workloads if you later move to another platform. Keep the signed order form with your architecture records. Confirm these terms with Pentaho before you size any migration.
Predictable scheduling and execution
Hop Server runs pipelines and workflows once they are submitted, but it is not a scheduler. A cron job, an enterprise scheduler or an orchestrator must submit each run, so the schedule, retries and alerting live outside Hop. Map every existing PDI schedule to a named owner and a submission method before cutover. Test failure paths, such as a missed run or a stuck job, as carefully as the normal run.
Version control and environment separation
Production projects should come from a reviewed source, not from a developer's workstation. Hop projects can be deployed as Docker images, as exported ZIP resources or from a Git checkout, so choose one method and use it for development, test and production. Keep environment-specific values such as connections and paths in environment configuration. Promote the same artifact through each stage so that what passed testing is what runs in production.
Pinned runtime and container images
Hop 2.19.0 was released on August 17, 2026 and requires Java 21, so the JVM on every server and container must match before you certify a build. The apache/hop image serves short runs or a long-lived Hop Server, and apache/hop-web serves the browser GUI, and both use Alpine Linux with OpenJDK 21. Pin image tags, record the digest of each release, and retest after every base image update.
Incident support path
Apache Hop is an Apache Software Foundation project, so fixes come from the community and no vendor is bound to answer a production incident. Decide who triages failures, who can read the Hop logs, and who joins the incident response outside working hours. If you need a contracted response, ask Pentaho which support tier comes with the licensed edition, or buy support from a third party in writing. Ask each vendor to state response targets in the contract.
Converted assets and shared connections
Hop's Kettle importer converts .ktr and .kjb files along with kettle.properties, but it keeps only one copy of same-named database connections and does not import the metastore. Before production use, reconcile every connection name, identify any metastore entries your jobs rely on, and rerun each converted pipeline against the output of the original PDI pipeline. Record every difference as either accepted or fixed.
How the paid Pentaho Starter and Enterprise routes compare
The Starter route is the smaller paid option in Pentaho's lineup and the first one to evaluate for a team moving PDI jobs into production. Its terms define what you may run, where, and with what help from Pentaho, so the written agreement matters more than the product name. Pentaho publishes no prices for this route, so treat the points below as the questions to put to its sales team.
- Licensed scope: Get the number of installations, environments and users or servers the license covers, and confirm whether test, staging and disaster recovery copies are included.
- Support terms: Ask for support hours, severity levels, response targets and contact channels in writing, along with the products and versions support covers.
- Upgrade rights: Confirm which new major and minor releases are included during the term and what happens to your entitlement if renewal lapses.
- Deployment targets: List every host type you plan to use, such as on-premises servers, cloud virtual machines or containers, and ask Pentaho to confirm each one is licensed.
- Renewal and exit: Ask how the subscription is priced on renewal and what access you keep if you stop paying.
Ask for these terms in one written quote so you can compare the Starter route with the Enterprise route on the same basis.
The Enterprise route is the paid option for organizations that run PDI across more sites, environments or teams. Its value depends on the terms Pentaho writes into the agreement, so do not assume a capability is included because the route carries the name. Ask for each capability you need to appear in the order form or the contract, and ask what changes if your footprint grows during the term.
- Licensed scope: Confirm the number of production and non-production environments, the number of nodes or servers, and whether licensed capacity can be moved between sites.
- High availability and scale: If you need clustered or redundant deployments, ask Pentaho to name the supported configurations and any extra licenses they require.
- Support terms: Compare response targets, escalation paths and named contacts against your own operating hours, and confirm whether support extends to customizations and plugins.
- Upgrade rights: Confirm access to new releases, the process for applying them, and whether upgrade assistance is included.
- Audit and true-up: Ask how usage is measured, how often Pentaho audits it and how overages are charged.
Ask Pentaho to attach its answers to the quote so your security, operations and procurement teams review the same commitments.
The Developer Edition, formerly Community Edition, is free and Pentaho lists it for non-production use only. Staying on it is a valid choice for development, testing and proof-of-concept work, but it is not a production license. Before you decide, define what counts as production in your own environment, because scheduled business loads, customer-facing outputs and regulated data often make a workload production even when it looks small.
- Permitted use: Write down which workloads, if any, remain on the Developer Edition and confirm with Pentaho in writing that they fall within its non-production terms.
- Support coverage: Confirm that the Developer Edition carries no support commitment, so any incident response is your team's responsibility.
- Security patching: Plan your own patch cadence and monitoring for every host running the software, since vendor support will not cover that work.
- Exit path: If production use is planned, estimate the conversion work for existing transformations and jobs before choosing a paid route or moving to Apache Hop.
- Hop comparison: Apache Hop is Apache-2.0 licensed and its manual describes importing Kettle (PDI) projects, which gives you a no-license production option to weigh against the paid routes.
Before you go to production on any route, confirm the written terms that apply to that exact deployment.
Which open-source option meets a production ETL requirement
This table compares Apache Hop, Apache NiFi and Apache Camel for teams that need a production replacement for Pentaho Developer Edition. Hop is the direct successor path because it imports Kettle jobs and transformations, while NiFi and Camel require redesign, so read the rows on migration effort before the rows on runtime fit.
| Option | How it meets the production requirement | Trade-offs |
|---|---|---|
| Apache Hop | Runs pipelines on the native Hop engine locally or on a remote Hop Server, and can switch to Spark, Beam, Flink, Dataflow or Databricks as a runtime setting. | Imports .ktr and .kjb files and shared connections, but Hop Server is not a scheduler and needs an external orchestrator. Confirm which PDI steps lack a Hop equivalent. |
| Hop Server | Long-lived process that executes pipelines and workflows, deployable as a Docker image, exported ZIP or Git checkout. | Scheduling, alerting and high availability sit outside Hop. Plan for the orchestrator and its monitoring as part of the production design. |
| Spark and Beam run targets | Hop can submit pipelines to Apache Spark natively or through Apache Beam, and to Flink or Google Dataflow through Beam. | Suits large volumes, but the cluster becomes a separate operating cost. Test converted pipelines on the chosen engine before cutover. |
| Apache NiFi | Automates data flows between systems with a visual, flow-based model suited to continuous ingestion and routing. | Batch ETL from PDI jobs must be redesigned as flows, not imported. Expect a rebuild of transformation logic and testing. |
| Apache Camel | Implements enterprise integration patterns with more than 350 connectors, written in Java, YAML or XML and deployed on Spring Boot, Quarkus or standalone. | Strong for application integration, but a Java developer model. Kettle transformations have no automatic path into Camel routes. |
How Apache Hop imports PDI jobs and transformations
Hop's Kettle importer converts the file types PDI teams already maintain into Hop equivalents. Kettle jobs (.kjb) become Hop workflows (.hwf), transformations (.ktr) become Hop pipelines (.hpl), and kettle.properties plus shared database connections become Hop metadata. It runs from the Hop GUI through File, Import from Kettle/PDI, or from the hop-import command-line tool, which suits a batch conversion of a large project. Before converting, inventory which jobs call which transformations, which variables come from kettle.properties, and which connections are shared, so you can check each group after import.
The documented limits matter for production planning. Hop keeps only one copy of same-named database connections, so if PDI projects define the same connection name with different hosts or credentials, the converted project may silently point at the wrong database. Hop also does not import the PDI metastore, so any connection, step or variable stored only there must be recreated by hand. Ask your team to list every metastore-dependent artifact and every duplicate connection name, and resolve each one before the first converted pipeline runs.
Hop began as a project derived from Kettle in late 2019, but compatibility with Kettle was never its goal. Treat the importer as a starting point, not a verified copy. Run each converted transformation against a fixed input set and compare row counts, field types, null handling and error output with the PDI results, and do the same for job control flow and scheduling. Confirm the exact step behavior in the Apache Hop import manual against the PDI steps your team actually uses.
How to deploy Apache Hop in production under your own controls
This sequence moves Pentaho Data Integration workloads onto a self-run Apache Hop deployment, from a pinned runtime and version-controlled projects to a long-lived Hop Server, a chosen run target, external scheduling, and logging and secrets handling that you control.
Confirm the Java 21 runtime and target release
Your platform or infrastructure team confirms that every host, container base and build agent can run Java 21, because Apache Hop 2.19.0, released on August 17, 2026, requires it. Check the Apache Hop download page for the current release before you pin a version, and record the chosen version in your change register. You know this step is done when a test host reports Java 21 and the pinned Hop version starts its GUI or command-line tools without errors.
Build or pin the apache/hop image
Your platform team pulls the apache/hop image for short-lived runs or a long-lived Hop Server, and the apache/hop-web image if analysts need the browser-based Hop Web GUI. Both images are built on Alpine Linux with OpenJDK 21, so confirm they meet your image scanning and base-image policies. Pin the image to an exact tag rather than a floating one, and mirror it into your own registry if your network rules require it. You know this step is done when the pinned image runs a sample pipeline in a non-production namespace.
Store projects and metadata in Git
Your data engineering lead moves the converted Hop projects, environments and metadata into a Git repository that your team controls, with review and branch protection enabled. Keep environment-specific values out of the repository, since connection details belong in environment configuration and secrets stores. Hop supports deploying projects from a Git checkout, so the same commit can be promoted from development to production. You know this step is done when a clean checkout of the main branch runs its test pipelines in a non-production environment.
Deploy Hop Server as a long-lived process
Your platform team runs Hop Server as a long-lived process in your own cluster or virtual machines, deploying projects as Docker images, exported ZIP resources or from the Git checkout, as the Hop deployment manual describes. Remember that Hop Server executes pipelines and workflows but is not a scheduler, so it waits for submitted work. Document the host, port, access controls and the owner of each deployed project version. You know this step is done when a pipeline submitted to the server completes and its status is visible to the operations team.
Select the run target for each workload
Your data engineering lead chooses a run target per workload: the native Hop engine locally or on Hop Server, Apache Spark natively or through Apache Beam, Apache Flink or Google Dataflow through Beam, or Databricks. The choice is a runtime configuration, so pipelines do not need rewriting, but each target has its own cluster, networking and sizing requirements that you must confirm with your platform team. You know this step is done when a representative pipeline produces the same row counts and output as the legacy PDI job on the selected target.
Attach an external scheduler
Your operations team connects an external scheduler or orchestrator that you already run, such as your existing enterprise job scheduler or an open-source orchestrator, to submit Hop workflows and pipelines on the times the old PDI schedules used. Record each schedule, its dependencies and its retry and alerting rules, since Hop Server will not trigger them itself. Confirm with your scheduler vendor or team how it authenticates to Hop Server. You know this step is done when every legacy schedule has a documented equivalent and a successful run has been observed.
Set up logging and secrets handling
Your security and platform teams configure where Hop Server and pipeline logs are written, how long they are retained, and who can read them, and confirm that connection passwords are supplied from your secrets manager or environment variables rather than from files committed to Git. Review each converted shared connection, because the importer keeps only one copy of same-named database connections and does not import the Kettle metastore. Ask your compliance lead which logging and access evidence your assessors expect. You know this step is done when a test failure is logged, alerted and traceable, and a scan of the repository finds no stored credentials.
What the migration effort depends on
The effort of moving from Pentaho Data Integration to Apache Hop depends mostly on the size and shape of your inventory, not on the license decision. Start by counting the transformations (.ktr) and jobs (.kjb) in use, separating those that run in production from those kept for reference, and noting which ones depend on kettle.properties variables or shared database connections. Hop's importer converts these files, but each one still needs review. A large number of jobs chained together, or many transformations that call each other, takes more time to verify than the same count of standalone files. Ask whoever owns PDI to export a list of every file and the schedule that triggers it before estimating anything.
The next driver is steps without a direct Hop equivalent and duplicate connection names. Hop's documented limitations include keeping only one copy of same-named database connections and no metastore import, so any connection defined twice in PDI needs a decision about which definition survives. Check each transformation for steps that have no direct Hop transform, and plan a replacement or a redesign for each. Schedules sit outside the converted files: Hop Server is not a scheduler, so cron, an orchestrator or another external tool must submit the work, and that wiring must be rebuilt and tested.
Testing is where most of the effort lands. Run each converted pipeline against the same input data as its PDI original, then compare row counts, column values, null handling, sort order and error output, keeping the PDI results as the reference. Record which pipelines match exactly, which differ and why, and who signed off each difference. The result is a per-pipeline test log that you can reuse in later phases. Before committing to a timeline, ask any migration partner to quote from this inventory and test plan, and confirm the Java 21 requirement for the Hop version you select against your current runtime.
Evidence to keep for a production ETL move
An auditor or internal risk team will want to see the same story told from several angles: what you were licensed to run, what you converted, what you changed and how you recover it. These cards list the records to assemble before cutover, so each one can be traced from the old Pentaho jobs to the new Hop projects.
License position for both platforms
Record which Pentaho edition ran each production workload, the license terms that applied to it, and the date you moved off it. Record the Apache License 2.0 position for Apache Hop and every plugin or connector you add. Ask Pentaho to confirm in writing which edition covers your production use, and ask your legal team to confirm the terms for any third-party component in the Hop build.
Converted pipeline test log
For each converted transformation and job, keep a log that compares Hop output with the PDI output for the same input. Record row counts, checksums on key columns, error handling and run duration. Note every step that had no direct Hop equivalent and how you replaced it. Treat any unexplained difference as an open defect until someone signs it off.
Git change records for Hop projects
Keep Hop projects, environment files and metadata in Git, and retain the commit history, review approvals and tags for each release that reaches production. Link each change to a ticket that states the reason and the tester. Record which commit each Hop Server or Docker image was built from, so you can rebuild any past run.
Scheduler and run logs
Hop Server does not schedule work, so an external scheduler or orchestrator submits every run. Keep the schedule definitions, the submission logs and the Hop run logs together, and check that failed and retried runs are visible. Confirm how long your scheduler and Hop Server retain these logs, and set retention to match your internal policy.
Access control for Hop Server
Document who can submit, read or stop pipelines on Hop Server, and how those roles map to your identity provider. Record the network paths that reach the server, the credentials used by the scheduler, and how database passwords are supplied at runtime rather than stored in project files. Review this list on a fixed cadence and after each staff change.
Backup and restore procedure
Write down what is backed up: Git repositories, Hop metadata, environment files, the scheduler configuration and any output stores. Include a restore test that rebuilds a Hop Server from the backup and reruns a representative pipeline against the test-log baseline. Record the date and result of each restore test, because a backup you have never restored is not yet evidence.
Questions teams ask before moving Pentaho to Apache Hop
Can our team migrate from Pentaho to Apache Hop without outside help?
Yes, a team with strong Pentaho and Java skills can often do it in house, but the first step is a scoped inventory. Apache Hop ships an importer that converts Kettle jobs (.kjb) to workflows (.hwf), transformations (.ktr) to pipelines (.hpl), and kettle.properties and shared database connections to Hop metadata. The importer covers the mechanical work, while the judgment calls remain: same-named database connections keep only one copy, and the metastore is not imported. Ask whether your staff have time to test converted pipelines against PDI output, replace steps that have no direct Hop equivalent, and set up scheduling. If any of those are missing, a fixed-scope engagement with DeployOpen can cover the planning, conversion, testing and documentation in writing before work starts.
What drives the effort of a Pentaho to Hop migration?
The main drivers are the number of transformations and jobs, how many use steps without a Hop equivalent, how many database connections and environment properties are shared, and how your schedules are triggered. Each of these changes the testing workload. Pipelines that run only simple reads and writes against PostgreSQL or Snowflake usually convert with less rework than those relying on custom Java steps or scripted logic. Ask for an inventory that lists each artifact, its target databases, its schedule and its owner, so the effort can be sized from the inventory rather than from guesses.
How long does a migration from Pentaho to Apache Hop take?
No duration has been established for this migration, so treat any number you hear as unverified. The timeline depends on the inventory, the number of artifacts that need manual rework, the test coverage you require, and how quickly your team can review results. The practical first step is a scoped inventory that counts transformations, jobs, connections, schedules and unsupported steps. Once that inventory exists, ask any vendor or partner to commit to a timeline in the written scope, with deliverables and milestones listed separately.
What skills and staff time does the migration need from our side?
Plan for three groups of people. Data engineers who know the existing pipelines must confirm business logic and validate outputs. A platform or DevOps engineer must run Hop Server or the Docker images, set up the environment properties and handle the scheduler. A data owner must sign off that results match what the business expects. Hop 2.19.0 requires Java 21, so confirm that your runtime images and hosts meet that requirement early. Ask your partner to name who will review each converted artifact and how long that review is expected to take.
Is Apache Hop free to use, and what support costs remain?
Apache Hop is licensed under the Apache License 2.0, so the software itself carries no license fee. The costs that remain are the infrastructure to run Hop Server or containers, the engineering time for conversion and testing, the scheduler or orchestrator you choose, and any support contract you buy. Pentaho publishes no prices, so the recurring cost of Pentaho's paid editions can only be compared through a written quote. When you request one, ask what support covers, which versions it applies to, and how upgrades are handled. Apache Hop itself is community maintained, so decide in advance whether your team or a support provider will carry responsibility for fixes.
Should we buy a Pentaho Starter or Enterprise license instead?
Buying a paid Pentaho edition makes sense if you need vendor support and continuity on PDI as it exists today and cannot absorb a conversion project in the near term. Moving to Hop makes sense if you want to remove the licensing constraint, run on Apache Spark, Apache Beam, Flink, Google Dataflow or Databricks as a runtime configuration, and avoid paying for a non-production license in production. Compare both options against the same inventory and the same three-year cost model, including labor. Ask Pentaho for a written quote for the edition you need, and ask a migration partner for a fixed-scope estimate of the conversion.
Which Hop runtime should we choose for production pipelines?
Start with the workload rather than the runtime. Pipelines that run on the native Hop engine can execute locally or on a remote Hop Server, which is a long-lived process that does not schedule itself. Workloads that need distributed processing can run on Apache Spark natively or through Apache Beam, on Apache Flink or Google Dataflow through Beam, or on Databricks, selected as a runtime configuration. Hop Server needs an external scheduler or orchestrator to submit work. Confirm each target in a test environment before choosing, because runtime support differs across transforms.
What a total cost comparison should include
A fair comparison starts with the Pentaho subscription line items, which Pentaho does not publish. Ask for the Starter or Enterprise license fee, the support fee, the term length, and whether renewal pricing is fixed or subject to uplift, all in writing. Then ask what the Developer Edition restrictions mean for your environments, since moving production workloads onto a non-production license is not a cost you can budget around. Most of these items recur annually, so the multi-year total matters more than the first invoice.
On the Apache Hop side, the license cost is zero, but the bill is not. One-time costs include converting .ktr and .kjb files with the importer, reviewing duplicate database connections, replacing steps with no direct Hop equivalent, and testing converted pipelines against current PDI output row by row. Recurring costs include servers or containers for Hop Server, the scheduler that submits work to it, Java 21 patching, and the engineering time to keep pipelines current. Each cost rises with the number of transformations, the number of custom Java steps and the number of environments you run.
Decide early who pays for ongoing operations. If your team already runs Docker or Kubernetes, the marginal server cost may be small, but staff time for upgrades, monitoring and incident response is real. If not, price an external support retainer alongside the Pentaho support quote, and ask for a written scope that covers version upgrades. The detailed line-by-line model, with a worked structure you can adapt, is on the Pentaho Enterprise Edition cost vs self-hosted Apache Hop page, which also lists what to request from Pentaho.
How DeployOpen plans a Pentaho to Apache Hop move
DeployOpen starts with a written scope that lists every Pentaho Developer Edition in production workload, its schedules and its connections, then plans a move to Apache Hop under the Apache License 2.0. Engagements are fixed-scope, so the deliverables and timelines are agreed before any conversion work begins.
How we scope
- Inventory every PDI transformation, job, schedule and shared connection that runs in production today
- Record which runtimes, servers and cron or scheduler jobs trigger Pentaho, and who owns each one
- Agree in writing which pipelines move, which stay on Pentaho and which steps need a replacement
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts
- Confirm with the vendor and your own environment which PDI edition and license terms apply to each workload
How we build
- Run the hop-import tool on the agreed .ktr and .kjb files, then review the converted Hop projects
- Resolve duplicate database connections and kettle.properties values into Hop metadata by hand where needed
- Deploy Hop Server or Hop runtime targets inside your infrastructure, with an external scheduler submitting work
- Replace steps without a Hop equivalent and document each substitution for reviewers
- Test converted pipelines against PDI output on the same sample data before any cutover
How we hand over
- Deliver the converted projects, environment configuration and runbooks for your own operations team
- Document the scheduler integration, Docker image or Git deployment path and the rollback steps
- Provide test evidence comparing row counts and outputs between PDI and Hop for each migrated workload
- Record the decisions, known gaps and open items so auditors and future maintainers can trace them
- Walk your team through the handover before the Pentaho instance is retired
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover Hop version upgrades, such as moving to a later Java 21 compatible release, under a written scope
- Support can extend to security testing of the new pipeline hosts and APIs, if that is in scope
- Confirm response expectations and service levels in the retainer agreement, since DeployOpen does not publish them here
- Compliance readiness work prepares evidence for your assessors, but DeployOpen does not issue audit reports or certifications
