Retiring Pentaho (Hitachi Vantara)
Whether you pay Hitachi Vantara for Enterprise Edition or run the Community Edition yourself, a Pentaho to Power BI migration is a rebuild of four artefacts: Mondrian cubes become a star-schema semantic model, PRPT reports and CDE dashboards become Power BI reports and paginated reports, Kettle transformations become Power Query or Dataflows, and every figure is reconciled against its Pentaho original.
Representative dashboard — sample data
Why teams move
Pentaho was adopted by a particular kind of organisation: one that wanted a full BI stack, from ETL through OLAP to reporting, without paying Cognos, BusinessObjects or OBIEE prices. Many started on the open-source Community Edition and some later moved to the commercial Enterprise Edition, which now sits under Hitachi Vantara. The estate that results is unusually broad for its size: a Mondrian schema somebody hand-edited in Schema Workbench, a folder of Kettle transformations and jobs run by Kitchen on a cron schedule, Report Designer files, a handful of CDE dashboards with custom JavaScript, and a group of users who live in Analyzer or Saiku.
What triggers the move is usually a renewal quote, a Community Edition that has fallen behind the commercial release, or the departure of the one person who understood the PDI jobs. What stalls it is treating the job as a report conversion. The Pentaho reports are the visible half. The cube definition and the ETL underneath them carry the business logic, and a rebuild that copies the report list first inherits every ambiguity in that layer with none of the run-time help Mondrian was quietly providing. This page is specifically about the Pentaho path. Teams leaving IBM's stack should read our Cognos to Power BI migration page instead, and spreadsheet-based reporting is covered by the broader migration to Power BI service.
What the rebuild covers
Start with a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. Reading the Mondrian schema and inventorying the Kettle jobs makes a good first task: it tells you the real size of the job before you commit a budget to it.
How we approach it
Mondrian does a lot of work at query time that Power BI expects you to have settled in the model. Naming those behaviours early is what keeps the rebuild predictable instead of surprising you at month-end.
We read the schema XML cube by cube: shared dimensions and their usages, hierarchies and levels, measures and their aggregators, calculated members, named sets, virtual cubes, aggregate tables and roles. That list is the model specification before any visual is drawn.
Each .ktr transformation and .kjb job is listed with its schedule, its inputs and what it feeds. Only then is each one assigned a destination: Power Query, a Dataflow, the existing warehouse left in place, or a Fabric pipeline handled as separate work.
A Report Designer .prpt is a bundle of XML describing data sources, parameters, bands, formulas and subreports, so the report estate can be catalogued systematically rather than by opening every report by hand.
Where Mondrian joined two cubes through a virtual cube on their shared dimensions at query time, Power BI needs those conformed dimension tables to exist in the model. We design that shape deliberately and test it against the old totals.
Schema, cube, hierarchy and member grants are rewritten as row-level security roles with DAX filter expressions, then tested role by role so the same people see the same rows after cutover. Folder permissions from the User Console become workspace roles.
Analyzer and Saiku users get the matrix visual with model hierarchies for drag-and-drill, and Analyze in Excel for the people who want a pivot table on the governed model. Saved views the business depends on are rebuilt as report pages.
Pentaho bundles five things that Power BI splits differently. Pentaho Data Integration (Kettle) loads and shapes data. Mondrian is a relational OLAP engine: it holds no data of its own, but turns an MDX query from Analyzer, Saiku or JPivot into SQL against your warehouse using the cubes, hierarchies and aggregate tables declared in the schema. Report Designer produces banded, parameterised PRPT output. CTools (CDE, CDF and CDA) build dashboards from JavaScript components. The Pentaho Server holds the repository, the scheduler and the folder permissions that tie it together.
On the Power BI side, Power Query and Dataflows take the shaping role, a semantic model holds tables, relationships and DAX measures, reports and paginated reports consume it, and the workspace carries permissions and refresh. So the migration is a model rebuild with a known map, not a file conversion. The practical consequence is where ambiguity gets resolved. Mondrian can carry a hierarchy whose levels do not quite roll up, or a measure whose aggregator hides a grain problem, and still return a plausible number. A tabular model has no equivalent rescue: the grain has to be right in the table, or the measure is wrong everywhere it is used. That is why we read the schema before quoting the reports.
One decision is genuinely new. Because Mondrian queried the warehouse live, Pentaho teams never chose between storing data in the model and querying it in place. Power BI makes that choice explicit, and it shapes refresh, performance and licensing. Our DirectQuery versus Import guide walks through it; in practice most Pentaho cubes translate best to Import with incremental refresh, with DirectQuery reserved for the largest fact tables.
This is the working map the plan is built from. It is deliberately unglamorous: the value of a migration map is that nothing surprising appears in week three, and that every line has an owner who agreed to it.
| Pentaho | Power BI equivalent | What changes in practice |
|---|---|---|
| Mondrian schema (XML) with one or more cubes | Semantic model published to a workspace | The cube definition leaves a hand-edited XML file and becomes a shared, refreshable model |
| Cube fact table and shared dimensions | Fact and dimension tables in a star schema | Dimension usages become relationships; degenerate dimensions become columns on the fact |
| Hierarchy with levels | Model hierarchy on the dimension table | Ragged and parent-child hierarchies (closure tables) are flattened with PATH functions in DAX |
| Measure with an aggregator (sum, count, distinct-count) | A named DAX measure | Aggregation stops being a schema attribute; each definition is written once and reused |
| Calculated member and named set (MDX) | DAX measure, calculation group or calculated table | MDX expressions are rewritten as DAX and reconciled one at a time against Analyzer output |
| Virtual cube across two cubes | Two fact tables filtered by the same conformed dimensions | What Mondrian assembled at query time has to exist in the model before the report is built |
| Aggregate table (AggName / AggPattern) | Power BI aggregations, or Import mode making them unnecessary | Pre-summarised tables are either mapped as aggregations or retired once the model is in memory |
| Mondrian role with schema, cube, hierarchy and member grants | Row-level security role with a DAX filter expression | Row rules move onto the model and are testable with the View as role feature |
| Kettle transformation (.ktr) feeding a report | Power Query steps inside the model | Report-specific shaping moves next to the model that consumes it |
| Kettle job (.kjb) loading the warehouse on a schedule | Dataflow Gen2, or the existing warehouse kept and connected | Shared loads are re-platformed only when the warehouse itself is being retired |
| Report Designer (PRPT) interactive report | Power BI report page with slicers | Parameters become slicers; formulas become measures on the shared model |
| PRPT print output with page breaks and subreports | Paginated report in Power BI Report Builder | Banded layout, repeating headers and every printed row are preserved rather than approximated |
| CDE dashboard (CDF components, CDA queries) | Power BI report page | Charts and selectors are rebuilt natively; custom JavaScript components are scoped individually |
| Analyzer or Saiku ad hoc view | Matrix visual with hierarchies, or Analyze in Excel | Drag-and-drill continues on the governed model instead of on the cube browser |
| Pentaho Metadata model (.xmi) for Interactive Reporting | Display folders, descriptions and synonyms on the semantic model | The business-friendly naming layer is carried into the model rather than kept beside it |
| Pentaho Scheduler and emailed output | Scheduled refresh plus report subscriptions | Delivery moves onto the same platform as the reports themselves |
| User Console folder permissions | Workspace roles and app audiences | Who sees which content becomes a permissions question, not a modelling one |
Two lines in that table carry most of the risk, and both are modelling lines rather than reporting ones. Conformed dimensions across a virtual cube and the treatment of aggregate tables are what stop a multi-cube rebuild from quietly disagreeing with the original, which is why we design against Microsoft's star schema guidance (opens in new tab) from the first cube and explain the reasoning in our own Power BI star schema guide.
This is the question that decides the shape of the project, so we answer it per job rather than for the estate as a whole. Every transformation and job lands in one of three groups. The first group shapes data for one report or one cube and nothing else; those steps move into Power Query inside the semantic model, where they refresh with it. The second group loads the warehouse the cubes read on a schedule. If that warehouse is staying, the jobs stay too, and Power BI connects to the tables they produce. That is the lowest-risk first phase, because nothing upstream changes while the reporting layer is rebuilt and reconciled.
The third group is the one that needs honesty. If the warehouse is being retired along with Pentaho, the shared loads have to be re-platformed, usually as Dataflows Gen2 (opens in new tab) for straightforward loads and as Data Factory pipelines where Kettle was orchestrating many steps, multiple targets or error handling. That is data engineering rather than report migration, and it is scoped separately through our Microsoft Fabric consulting work so the reporting rebuild is not held hostage to it.
Pentaho enforces two different things that get discussed as one. Mondrian roles restrict which members of which hierarchies a user can see, which is row security. Repository folder permissions in the User Console restrict which reports and dashboards they can open at all, which is object security. Those separate cleanly in Power BI, and keeping them separate is what makes the rebuild testable.
Member grants become row-level security (opens in new tab) roles on the semantic model, written as DAX filters and verified role by role before anyone else sees the report. Hierarchy grants that hid whole levels are handled with object-level security or by leaving the column out of the model. Folder visibility becomes workspace roles and app audiences. Where Pentaho roles were mapped from LDAP or Active Directory groups, the same groups are used for Power BI role membership so nobody has to maintain two lists.
Analyzer and Saiku are cube browsers: drag a hierarchy onto rows, a measure onto columns, drill, filter, pivot. Power BI's matrix visual on a model with proper hierarchies covers that for most people, with drill-down, drill-through and Show as table replacing the cube browser's controls. For the finance analysts who used Analyzer as a pivot table, Analyze in Excel connects a real pivot table to the governed model, which is often the feature that ends the resistance. Saved views a team depends on every month are rebuilt as report pages so nobody has to recreate them.
CDE dashboards are a different case. A CDE dashboard is a layout of CDF components fed by CDA queries, and it often carries custom CSS and JavaScript that one developer wrote years ago. Charts, tables and selectors rebuild natively in Power BI without the custom code. Bespoke components that do something a native visual cannot are scoped individually, and the honest answer is sometimes that the behaviour was a workaround for a modelling problem the new model no longer has.
Report Designer produces two kinds of thing that look alike in the repository. Interactive PRPT reports with parameters and drill links become Power BI report pages, with parameters turned into slicers and formulas turned into measures on the shared model. Banded print output, such as statements, invoices, statutory packs and anything with subreports and page breaks, is not a dashboard and should not be forced into one. That output moves to paginated reports (opens in new tab) built in Power BI Report Builder, which control page breaks, repeating headers and printing every row. Confirm the licensing for paginated reports against Microsoft's current documentation before committing to that design, because it depends on your capacity and licence type.
Work runs on prepaid Flex hours that never expire: Starter 20 hours ($2,500), Growth 40 hours ($4,600), or Power 80 hours ($8,000), with hourly work from $100/hour. Reading the Mondrian schema, inventorying the Kettle jobs and cataloguing the PRPT and CDE content for a typical mid-market estate fits inside a Starter block, and it is the task we recommend buying first, because it converts an unknown repository into a list with hours against every line.
After that, cost tracks the shape of the model far more than the number of reports. A single cube feeding twenty PRPT reports is a much smaller job than three cubes joined through a virtual cube, a set of MDX calculated members and a Mondrian role per business unit. You get an estimate in hours per deliverable, approve only what you want built, and unused hours stay banked. See how Flex pricing works.
Individual reports typically ship within 3–5 business days of approval once the model is standing, and a phased migration is a sequence of those tasks rather than one project ending in a big-bang cutover. The model itself is the front-loaded piece: it is worth building and reconciling before the report queue starts, because every report after it gets cheaper. Microsoft's own Power BI migration guidance (opens in new tab) recommends the same phased shape.
Running Pentaho alongside Power BI for one full reporting cycle is worth the overlap, and it is cheap when the Kettle loads keep running in place. Users compare both outputs on live data, and the old server is switched off only once the replacements have been through a real month-end.
Finance, operations and IT teams carrying a Pentaho estate they can no longer maintain comfortably: an Enterprise Edition renewal that has stopped looking like value, a Community Edition install that nobody wants to upgrade, a Schema Workbench file only one person understands, or a folder of Kettle jobs whose author has left. It is a poor fit for anyone wanting a like-for-like screen copy of every CDE dashboard with its custom JavaScript intact, or for teams whose main problem is the ETL layer rather than the reporting; those teams should start with Fabric work and come back to the reports afterwards.
business days per report
not big-bang
own everything
Buy the schema-and-inventory task first and decide the rest once the real scope is visible. Comparing routes off different legacy platforms? The migration to Power BI hub covers them side by side.
How it works
We document the Mondrian schema — cubes, shared dimensions, hierarchies, measures, calculated members, aggregate tables, roles — inventory every Kettle transformation and job with its schedule, and catalogue the PRPT, CDE, Analyzer and Saiku content with owners and run frequency. You approve the list and the hours behind it before work starts.
The cube becomes a star schema with conformed dimensions, aggregations where they earn their place, and named DAX measures. Surviving reports are rebuilt on top of it highest-value first, with banded print output built as paginated reports and ad hoc views handed to the matrix visual and Analyze in Excel.
Each rebuilt report runs beside its Pentaho original on the same parameters and period, differences are explained, then we publish, set refresh, row-level security and permissions, walk your users through it, and stay available on the hours you have left.
Representative perspective
We assumed the reports were the project. Once someone listed the Kettle jobs and wrote down what each cube measure actually did, the arguments about which number was right mostly answered themselves.Finance systems manager, mid-market distributor
Representative perspective
Our worry was the analysts who lived in Analyzer. Giving them a pivot table on the new model through Excel is what turned the migration from a fight into a schedule.IT director, regional healthcare group
Tell us roughly how many cubes, Kettle jobs and reports you have, and which ones month-end depends on. We'll scope the schema read and the job inventory in hours, so you can see the real project before committing to it.
FAQ
No. A Mondrian schema is an XML description of cubes, hierarchies and measures that the engine turns into SQL at query time, and there is no import path into a tabular model. What is systematic is reading the schema cube by cube and rebuilding it as a documented star schema with named DAX measures, then reconciling each measure against Analyzer or Saiku output.
Usually not. Transformations that only shape data for one report move into Power Query inside the model. Scheduled jobs that load the warehouse the cubes read can keep running while Power BI connects to that same warehouse, which is the lowest-risk first phase. Only estates that need the whole ETL layer re-platformed go to a Microsoft Fabric engagement.
It changes the inventory, not the method. Enterprise Edition estates carry Analyzer, Dashboard Designer and Interactive Reporting content that has no file you can export, so it is catalogued from the repository. Community Edition estates lean on Saiku and CDE, whose definitions are readable files. Both sit on the same Mondrian schema and Kettle jobs, which is where the rebuild starts.
The Power BI matrix visual with model hierarchies gives the drag, drill and pivot experience for most users, and Analyze in Excel connects a pivot table straight to the semantic model for people who lived in the cube browser. Saved Analyzer views that a team depends on every month are rebuilt as report pages so nobody has to recreate them.
Every rebuilt report is run beside its Pentaho original on the same parameters and period, and each difference is explained before sign-off. Some differences turn out to be corrections: a rebuild often exposes a calculated member, a hierarchy level or an aggregate table that had been quietly double-counting or dropping rows for years.
This page covers the Pentaho path specifically, because the Mondrian schema, the Kettle jobs and the CTools content set the scope here. If your estate spans several tools, the broader migration to Power BI service handles the Excel and SSRS routes on the same prepaid model. The closest neighbouring rebuilds are Cognos to Power BI migration, where a Framework Manager package plays the part the Mondrian schema plays here, and OBIEE to Power BI migration, where the RPD does the same job and comes with an integrate-rather-than-migrate option. When the Kettle layer is the real project, the ETL re-platforming is scoped as Microsoft Fabric consulting rather than squeezed into the report rebuild. The modelling itself is data modeling and DAX work, and two of our guides cover the decisions that come up on every Pentaho estate: the star schema guide for turning cubes into tables, and DirectQuery versus Import for the storage choice Mondrian never asked you to make. Every task is scoped before work begins from your prepaid block of senior-led hours, and hours are deducted only for work you approve.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.