Pentaho Support Options: Vendor Lifecycle, Extended or Independent

Pentaho support comes from the vendor for Enterprise Edition versions inside their support window, from Pentaho's paid Extended Support for some versions past it, and from independent providers for older versions, Community Edition and the daily running of Pentaho Data Integration. The vendor window is shorter than most teams assume.

How the Pentaho support lifecycle works

Pentaho's product lifecycle overview defines two release types. A Normal release focuses on new features. A Long-Term Support (LTS) release, published every 18 to 24 months, is the one intended for stable production environments. Both are maintained with service packs.

Support then runs in two phases. Active patching produces service packs and critical patches, and lasts until the next release of the same kind ships. Limited support follows and typically lasts six months: existing service packs and documentation stay available and the support team helps with workarounds, but there are no new software corrections or patches. After that the version is unsupported. At the time of writing Pentaho lists end of support as March 2028 or later for 10.2 and July 2029 or later for 11.0, and states that any version not listed is unsupported.

Ownership does not change that arithmetic. Pentaho has moved between parent companies more than once, most visibly through its years under Hitachi Vantara, and the lifecycle page on the Pentaho support portal is the document that governs what is covered, whoever owns the business. Check it rather than relying on a date you were given at purchase.

Pentaho Extended Support

For certain versions past their end of support date, Pentaho sells Extended Support as an add-on. It is limited support for a longer period, meant to cover a legacy environment while you migrate to a newer version. It does not restore patching.

Community Edition has no vendor support

Pentaho Community Edition, including the open-source Pentaho Data Integration that many teams still call Kettle, comes with no support contract from the vendor. Help is community forums and whatever skills you have in-house. A great deal of production ETL still runs on it.

That matters because of what PDI does. It is the ETL and data integration layer: the transformations and jobs that load the warehouse, feed the business intelligence dashboards and move files between systems on a schedule. When a pipeline stops at 2am, the documentation and a forum thread are not a support plan.

Where independent Pentaho support fits

• Versions Pentaho no longer supports. Pentaho 8.x and 9.x estates are common and are outside the vendor window.
• Community Edition in production, where there is no vendor to call.
• Breakage that is not a product defect: a transformation that fails after a Java or operating system patch, JDBC driver mismatches, repository lock contention, Carte clusters that hang, jobs that stop firing after an upgrade.
• The exit. If the honest answer is that Pentaho should be replaced, you want the people supporting it to be able to plan that too, whether the target is Apache Hop, which began as a fork of Kettle, or a modern ELT stack.

AceMQ provides 24/7 Pentaho support for Pentaho Data Integration and Pentaho Server on any version, with a 15-minute emergency SLA. Related work: keeping a legacy Pentaho estate reliable and migrating from Pentaho to a modern ELT stack.

The Pentaho incidents that actually page people

• A job that ran for years and then stopped. Nothing changed in Pentaho. The operating system was patched, the Java runtime moved a version, a TLS setting was tightened on a source database, or a JDBC driver was replaced. Finding which one is diagnosis by elimination.
• Carte servers that hang. Remote execution through Carte stalls under concurrent jobs, leaks memory over weeks, or loses track of a running transformation. Restarts become a scheduled ritual instead of a fix.
• Repository contention. A database repository shared by many developers and schedulers suffers locks and slow saves. File-based repositories in version control are the usual way out.
• Out of memory in a transformation. Sort, group-by and stream lookup steps hold rows in memory. A source table that doubled in size turns a nightly job into a heap error, and the answer is step configuration and row-set sizing as much as a larger heap.
• Scheduler surprises after an upgrade. Schedules, data source definitions and permissions do not always carry over cleanly between server versions, and jobs silently stop firing.

Staying, upgrading or leaving

Pentaho estates tend to be old, large and poorly documented, which is why the decision is rarely simple. Staying on an unsupported version is viable for a while if the jobs are stable and someone is accountable for them. Upgrading to a current Long-Term Support release restores vendor patching for Enterprise Edition customers and means retesting every transformation against new Java and driver versions. Leaving has two common destinations. Apache Hop shares Kettle's heritage and can import existing jobs and transformations, which makes it the lowest-effort move for teams that want to stay open source. A modern ELT stack of an ingestion tool, dbt and a cloud warehouse is a rewrite, and usually the right one where the transformations are mostly SQL in disguise. An honest assessment inventories the jobs first, because a third of them typically no longer need to exist.