Replacing Tableau Prep Builder without losing your data prep flows
Tableau Prep Builder ships only with the Creator license, so teams with Viewer, Explorer or Display seats have no supported way to build Prep flows on the Tableau side. KNIME Analytics Platform, the free desktop application, and Apache Hop, an Apache-2.0 licensed pipeline tool, both cover the core Prep work: cleaning, joins, pivots and writing output. Where they differ is scheduling, and that difference is where the cost decision sits. This section sets expectations for the rest of the page: how the two tools compare on flow building, what scheduled runs cost in each, and where the prepared data should land so that Superset or Metabase can read it.
Start by inventorying your existing Prep flows. Each .tfl or .tflx file records input connections, cleaning steps, joins, pivots and output destinations, so list every flow, its owner, its refresh frequency and the downstream dashboards that depend on its output. Flows that run on a schedule through Tableau Server or Tableau Cloud need a clear replacement path, while flows a single analyst runs by hand may only need a documented rebuild. Confirm with your Tableau administrator which flows are scheduled, since that list determines whether you need a scheduler at all. Test a few representative flows on both candidate tools against the same source data before you choose one.
Plan the landing zone before you rebuild anything. Prepared data should go to a governed database table or schema that Superset or Metabase connects to directly, such as PostgreSQL, rather than to local files on analysts' laptops. Decide who owns each output table, how its refresh is recorded and what happens when a flow fails. Ask your implementation partner or internal platform team to confirm how the chosen runtime authenticates to the database and where its credentials are stored, because that choice affects both security review and the recurring operating effort.
Which Prep capabilities map to KNIME and Apache Hop
This table maps common Tableau Prep Builder steps to the closest KNIME Analytics Platform nodes and Apache Hop transforms or workflow actions. Read the middle column as a starting point for a test rebuild, not as proof of feature parity, and check the right-hand column for steps that need confirmation in your own environment. The main takeaway is that Prep's per-step preview has no exact equivalent, and scheduling is a separate cost decision in each option.
| Prep capability | KNIME Analytics Platform | Apache Hop | Confirm before assuming |
|---|---|---|---|
| Input connectors | Database, file and web reader nodes; more than 300 connectors to data sources and integrations | Table input and file input transforms across 40+ database dialects, including PostgreSQL, Snowflake, BigQuery and Kafka | Confirm that each source your Prep flows read from has a supported connector or driver in the chosen tool |
| Cleaning steps (rename, filter, change type, replace values) | Column rename, row filter, string manipulation and type conversion nodes | Select values, filter rows, replace in string and value mapper transforms | Confirm the exact behavior of null handling and type coercion against sample output |
| Joins | Joiner node with inner, left, right and outer join modes | Merge join and stream lookup transforms | Confirm how duplicate key matches and column name collisions are handled in both tools |
| Unions | Concatenate node for stacking tables with matching schemas | Append streams transform for combining row streams | Confirm schema alignment rules when column order or names differ |
| Pivots and aggregations | GroupBy and Pivoting nodes for summaries and cross-tab reshaping | Group by and row denormaliser transforms | Confirm that complex Prep pivot layouts can be reproduced step for step |
| Calculated fields | Math formula and column expression nodes, plus Python, R or JavaScript scripting | Calculator transform for row-level formulas | Confirm the function library your Prep calculations use, since names and syntax differ |
| Per-step sample preview | Node-by-node output tables after each execution, with no Prep-style visual preview on each step | Preview data from the GUI for a selected transform, with a different workflow from Prep | Gap: plan extra validation time for teams that rely on visual preview while authoring |
| Scheduled output and flow publishing | Scheduled runs and shared data apps are sold through KNIME Hub plans, not the free desktop tool | Hop Server does not schedule work, so an external scheduler or orchestrator must submit runs | Confirm the scheduler, hosting and credential handling you will run before committing to either option |
KNIME or Apache Hop: when each fits
Both tools replace Prep flows with open-source pipelines, but they fit different teams. KNIME suits analysts who build and share workflows on a desktop, while Apache Hop suits engineers who need to run the same pipeline on different engines. The cards below set out the trade-offs to check before you commit.
KNIME's license and node model
KNIME Analytics Platform is licensed under GPL version 3, with additional permissions for plug-in folders. Nodes that extend KNIME through its standard APIs are independent programs, so node authors may choose their own license terms. Before adopting a node that a Prep replacement depends on, check its license in its own metadata, since it may not be GPL. Ask your legal team to review the combined terms for any nodes you distribute internally.
KNIME's visual ecosystem and sharing
KNIME's strength is its ecosystem: more than 300 connectors, optional Python, R and JavaScript scripting, and a Community Hub with more than 14,000 shared solutions. Analysts who already have Prep flows will find the node-based canvas familiar enough to start quickly. Sharing and scheduled runs for a team sit behind KNIME Hub plans, so the desktop tool is free but team operation is a paid service. Confirm which of those features your team needs before you plan the budget.
Hop's Apache-2.0 license
Apache Hop is licensed under Apache-2.0 and maintained by the Apache Software Foundation. Its Hop GUI lets you design pipelines and workflows on a visual canvas, and the same project files can run without a KNIME-style hub subscription. Scheduling is not built in, so you must provide an external scheduler or orchestrator to submit work to Hop Server. Plan that orchestration component as part of the total cost.
Runtime flexibility in Hop
Hop pipelines run on the native engine locally or on a remote Hop Server, on Spark, Flink or Google Dataflow through Apache Beam, or on Databricks. You select the runtime as configuration rather than rewriting the pipeline. This matters when Prep volumes grow beyond a single desktop or when data sits in a warehouse. Confirm that each target engine and connector you need is supported in the release you deploy.
Kettle import and migration effort
Hop started from Pentaho Data Integration, so its importer converts Kettle jobs and transformations, along with kettle.properties and shared database connections. The importer runs from the GUI or the hop-import command-line tool. Documented limits include keeping only one copy of same-named database connections and no metastore import. Test converted pipelines against your Prep output before retiring the original flows.
Java 21 and operating skills
Apache Hop 2.19.0, released on August 17, 2026, requires Java 21, so your servers and developer workstations need a supported JDK before rollout. KNIME runs on its own bundled runtime on the desktop, which lowers the local setup burden for analysts. Engineering teams will need to own Hop projects in Git and manage Docker images for Hop Server, which adds operational work. Choose based on who will maintain the pipelines after go-live.
What scheduling costs in each option
KNIME Analytics Platform is free to download and use, and it is the tool your analysts use to design and test workflows on a desktop. Building, running and editing flows interactively carries no licensing charge under the GNU GPL version 3 terms. What it does not give you is unattended scheduling, shared team spaces or browser-based data apps. Those features are sold through KNIME Hub plans, so the desktop build is a cost-free starting point for development but not for a production timer.
- Build and test cost: Analysts can design, debug and rehearse flows on the free desktop application.
- No scheduler included: A workflow run on a laptop depends on that machine being on and logged in, which is rarely acceptable for regulated data feeds.
- Node licensing: Nodes built on KNIME's standard APIs are independent programs, so their own license terms apply to them, and you should check each third-party node before depending on it.
- Upgrade trigger: Move to a Hub plan when you need unattended runs, shared spaces or version-controlled team work.
Before relying on the desktop build for any recurring output, confirm which features your analysts need to run unattended and which Hub plan includes them.
KNIME's Team Plan is the Hub tier that adds scheduled workflow runs, private team spaces with version control and publishing of workflows as browser-based data apps. According to KNIME's Team Plan page, the plan starts at 99 euros per month and includes 3 seats and 120 workflow execution credits. Each further credit costs 0.025 euros per started minute, and executors from 2 vCores and 8 GB RAM consume 2 credits per minute. Scheduling frequency ranges from every minute to monthly. A free first month with 1,000 execution credits is also offered.
- Fixed monthly base: The 99 euro starting price recurs every month, whether or not you use the included credits.
- Seats: The Team Plan includes 3 seats, and KNIME's Hub pricing page describes capacity-based pricing with no per-seat licensing, so ask how seat and capacity limits apply to your team size.
- Run frequency: Every-minute schedules consume credits far faster than monthly ones, so the frequency you choose is the largest variable.
- Executor size: A larger executor costs more credits per minute, so a flow that needs more memory raises the run cost.
- Plan tier: Pro, Team and KNIME Business Hub plans differ, and the Business Hub tier is the route to self-managed deployment.
Ask KNIME for a quote built from your planned schedules, executor size and monthly run minutes, using the figures published on its pricing pages.
Apache Hop is licensed under Apache-2.0 and has no paid edition. The Hop GUI, the native engine, and Hop Server are free to run on your own servers, so the software line of the bill is zero. Scheduling is the gap: Hop Server is a long-lived process that executes pipelines and workflows but is not a scheduler, so an external scheduler or orchestrator must submit the work. You therefore pay for that component separately, whether it is an existing enterprise scheduler, a cron host or an orchestrator your data team already runs.
- Engine cost: Hop pipelines can run locally, on a remote Hop Server, on Spark, Flink, Google Dataflow or Databricks, with no licence fee for the engine itself.
- Scheduler component: Cron, an enterprise job scheduler or an orchestrator must be installed, patched and monitored.
- Hosting: Hop Server, the scheduler and any Spark or Databricks compute are infrastructure costs that recur monthly.
- Operations labour: Someone must own the deployment, Java 21 runtime upgrades and failure alerting, which is usually the largest recurring item.
- Deployment packaging: Projects can be shipped as Docker images, exported ZIP resources or from a Git checkout, and the choice affects release effort.
When you request a quote from a partner or internal team, ask for the scheduler component, the compute runtime and the people hours to operate them, separately from any build work.
Across both tools, scheduling cost is a function of how often flows run, how much compute each run needs and who keeps the schedule alive. Two options with the same flows can produce very different annual totals depending on whether a vendor-hosted plan or a self-operated scheduler carries the load. The figures below are illustrative only, since your own run profile determines the actual numbers.
- Run frequency: Hourly feeds and every-minute schedules multiply both KNIME credit consumption and Hop compute hours.
- Data volume and executor size: Larger inputs need bigger executors, which raise KNIME credits per minute or Hop server resources.
- Failure handling: Retries, alerting and reruns add labour and compute that a simple timer does not show.
- Who operates the scheduler: A hosted plan shifts scheduling operations to the vendor, while Hop shifts them to your team.
- Environment count: Development, test and production copies of each schedule multiply run costs unless you size them down.
Build a one-page run profile listing each flow, its frequency, executor size and owner, and use it to compare both options on the same basis.
Where prepared data should land so Superset or Metabase can read it
Prepared output should land in a PostgreSQL or MySQL-backed warehouse table that Superset or Metabase queries directly. Superset connects to any SQL datastore that has a Python DB-API driver and a SQLAlchemy dialect, so the target can be a dedicated analytics database separate from the Superset metadata database. Keep the two apart. Superset's metadata database holds users, dashboards and charts, and Superset's documentation tests only PostgreSQL and MySQL for that role, so loading business data into it mixes operational and analytical load. Confirm the exact driver and dialect for your target engine against the Superset documentation before you commit to a platform.
Design a staging schema that the flows write to and a published schema that the BI tool reads. Flows write to staging tables, validate row counts and key uniqueness, and then swap or append into published tables that dashboards reference. This keeps a half-finished Prep or KNIME run from changing a number on a live dashboard. Set refresh timing from the dashboard needs: a daily batch is usually enough for finance reporting, while operational views need a shorter cycle. The scheduler that triggers the pipeline is separate from the BI tool, so align the two schedules and record the last successful load time in a table the dashboards display.
Alerts and reports, async queries and dashboard thumbnails depend on Superset's caching layer and Celery worker and beat processes, according to the architecture documentation. A pipeline that only lands tables does not need them, but any team that wants scheduled email alerts on prepared data must budget for Redis and workers as recurring infrastructure. Plan this before cutover, because it adds components to patch and monitor. Metabase handles scheduled delivery differently, so check its plan limits on the Metabase pricing page before you assume the same features exist in the open-source edition.
Running prep and BI alongside remaining Tableau Server or Tableau Cloud
Prep and dashboards rarely move on the same day. The cards below cover how to keep existing Tableau content running while prepared data is produced by KNIME or Hop, and how to decide ownership and verification before any renewal.
Keep dashboards on extracts during transition
Existing Tableau workbooks can keep reading their current extracts while the new pipelines are built, so business users see no change during the transition. Decide which workbooks depend on Prep output files or flows and which read live database connections. Only the first group needs repointing. Confirm with each workbook owner which data sources feed it before any Prep flow is switched off.
Point Tableau at the new output tables
Once a KNIME or Hop pipeline writes a cleaned table to PostgreSQL or another warehouse, the Tableau data source can be changed to that table. Test the new source against the old extract with the same filters and row counts. Record differences in joins, null handling and date formats, because these are the usual causes of mismatched totals.
Map Prep Creators to pipeline owners
Tableau Prep Builder ships only with the Creator role, so the people who built flows are the natural first owners of pipelines. Assign each flow to a named owner who keeps the workflow file, the schedule and the target table documented. Viewers and Explorers who only consume outputs do not need a replacement tool for preparation, but they still need a clear owner to contact when numbers change.
Schedule runs outside Tableau
Prep scheduling in Tableau runs inside the Tableau Server or Tableau Cloud environment. In KNIME, scheduled runs need a hosted plan, while Hop Server does not schedule work by itself, so an external scheduler must submit pipelines. Decide which scheduler will run each pipeline, who receives failure alerts, and where run logs are kept before the Tableau schedule is disabled.
Verify outputs before any renewal
Tableau term licenses stop working when the subscription lapses, so the time to confirm that prepared data is complete is before the renewal date, not after it. Export the workbooks and extracts while licenses are active, then compare the new pipeline outputs with them for a full reporting cycle. Keep the verification record, since it shows what a short renewal must still cover.
Connect Superset to the prepared tables
Apache Superset reads prepared tables through a SQL database connection and a dataset, so the output tables from KNIME or Hop become the source for dashboards there. Create datasets only for the verified tables, and keep Superset's metadata in PostgreSQL or MySQL rather than the default SQLite. Pilot one dashboard against the new tables while Tableau still serves the rest of the estate.
Migrating Prep flows in phases
This sequence moves each Tableau Prep flow into a KNIME or Hop pipeline that writes to a landing table Superset or Metabase can read, with checks at each stage so no flow is retired before its output is proven. Prep flow files are not converted automatically, so each flow is confirmed individually before work starts.
Inventory Prep flows and schedules
The Tableau administrator lists every Prep flow on the site, its owner, its last successful run and any Tableau Server or Tableau Cloud schedule attached to it. Include flows that individual analysts run on their desktops, since those do not appear in server schedules. The step is done when each flow has a named owner, a business purpose and a recorded run frequency, or a note that it runs only by hand.
Document inputs and outputs per flow
For each flow, record every input source, such as file uploads, database tables or published data sources, and every output, such as published extracts, CSV files or database writes. Note the cleaning steps, joins, pivots and calculated columns in plain language, because these are the logic the pipeline must reproduce. The step is done when a reviewer can read the record and name the source and target of every flow without opening Prep.
Rebuild flows as KNIME or Hop pipelines
The data engineering team rebuilds each documented flow as a KNIME Analytics Platform workflow or an Apache Hop pipeline, choosing the tool per flow based on the team's skills and the connectors each flow needs. Confirm the Prep flow file contents with the vendor or your own export before assuming any logic carries over, because Prep files are not converted automatically. The step is done when each rebuilt workflow runs end to end on a test copy of the inputs.
Validate outputs against Prep results
Run the old Prep flow and the new pipeline on the same input snapshot, then compare row counts, column names, data types and a sample of rows for each output. Investigate every difference, since differences often trace to null handling, join types or sort order rather than to the pipeline itself. The step is done when a signed-off comparison exists for each flow, with any accepted differences written down.
Set up scheduling and alerting
Schedule each validated pipeline with the scheduler your team already runs or with an orchestrator, because Hop Server executes work but does not schedule it, and KNIME scheduled runs need a KNIME Hub plan. Configure failure alerts that reach a named owner and log each run's status. The step is done when a test failure triggers the alert and a successful run writes the expected timestamp to the landing table.
Switch consumers to landing tables
Point each Superset dataset or Metabase model at the new landing table, then compare the dashboards' figures with those from the Prep output for the same period. Keep the previous source available until the comparison matches, so the change can be reversed. The step is done when every dashboard that used a Prep output reads from the landing table and the owners have confirmed the figures.
Retire Prep flows and archive records
Disable the Prep schedules, remove the flows from the production project and keep an archived copy of each flow file, its inventory record and its validation report. Confirm with the business owners that no remaining report depends on a retired output. The step is done when the archive is stored in a location the team can still access and no active Prep flow writes to production data.
Questions buyers ask before replacing Tableau Prep
Is KNIME's desktop tool free for building Prep-style flows?
Yes. The KNIME Analytics Platform is free and open, and building and running workflows on a desktop uses that free software, according to KNIME's own product and pricing pages. Its license is GNU GPL version 3, with additional permissions for nodes built on its standard APIs. The cost question shifts to scheduling and shared execution, which KNIME sells through its Hub plans. Confirm with KNIME which parts of your planned flows, including any community or third-party nodes, need to be checked against the license terms before you rely on them in production.
What do scheduled runs add to the cost, and why?
Scheduling is the main recurring cost difference. KNIME's Team Plan starts at 99 euros per month and includes 3 seats and 120 workflow execution credits, with each further credit at 0.025 euros per started minute, according to KNIME's Team Plan page. Executors from 2 vCores and 8 GB RAM consume 2 credits per minute. The cost rises with how long flows run, how often they are scheduled, and how many executors you need. Apache Hop has no paid scheduler, but Hop Server is not a scheduler either, so you pay in infrastructure and operations instead. Ask any vendor for the credit consumption of your actual flows, run frequency and peak concurrency.
How long does rebuilding Tableau Prep flows take?
The effort depends on the number of flows, how many steps each contains, and how much logic lives in calculated fields, custom joins and pivots. Simple cleaning and filtering flows move quickly. Flows with many joins, custom SQL, or dependencies on other flows take longer because each needs testing against the same output. No supplied figure gives a reliable duration, so ask for an inventory first: flow count, step count, input sources, output destinations and run frequency. A fixed-scope written plan can then state the deliverables and timeline for that inventory.
What skills does the team need to run Hop or KNIME pipelines?
Expect three areas of skill:
- SQL for reshaping, joins and validation, since most prepared data lands in a database that Superset or Metabase reads.
- Java 21 for Apache Hop, which the Hop 2.19.0 release requires, and Docker or Git skills for deploying projects.
- Scheduler operations, because Hop Server executes work but an external scheduler or orchestrator must submit it.
KNIME users need workflow design skills and, for scheduled runs, an account on the Hub plan. Confirm which of these your team already covers before choosing the tool.
Can DeployOpen run the rebuild under a fixed-scope agreement?
Yes. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A rebuild of Prep flows into KNIME or Apache Hop, scheduling on your infrastructure, and loading output into the database that Superset or Metabase reads would fall within that model. Ongoing upkeep is available as a retainer. DeployOpen does not publish a price list, so the quote follows from the written scope.
What should a written quote for this migration include?
Ask for a quote that lists each item separately:
- The flow inventory and which flows are in scope, with the assumptions behind them.
- Target tool and runtime, including whether Hop runs on the local engine, Hop Server, or a Spark or Databricks runtime.
- Scheduler choice and who operates it, plus any KNIME Hub plan or execution credit assumptions.
- Output destination, such as the metadata or analytics database, and access controls for Superset or Metabase.
- Testing, cutover and parallel-run periods, and handover documentation.
- Recurring items: infrastructure, upgrades and support.
Ask how each cost changes if the flow count or run frequency grows.
Does moving Prep flows to Hop mean rewriting Kettle or KNIME work?
Not necessarily. Apache Hop started from Kettle, and its importer converts Kettle transformations (.ktr) to pipelines (.hpl) and Kettle jobs (.kjb) to workflows (.hwf), but Tableau Prep flows are not Kettle files, so they must be rebuilt. Hop's importer is a route for teams that already have Kettle estates. Its documented limits include keeping only one copy of same-named database connections and no metastore import, so review imported objects before relying on them. For Tableau Prep flows, plan a rebuild and validate the output row counts against the existing results.
How DeployOpen scopes and delivers prep migrations
DeployOpen plans, implements, hardens, documents and supports the self-hosted pipeline layer for a Tableau Prep migration, whether that layer is KNIME Analytics Platform or Apache Hop, together with the landing database that Superset or Metabase will read. The work runs inside the client's own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, so the flows in scope, the connectors, the landing schemas, the scheduler choice and the acceptance tests are agreed in writing before any work starts. Ask for that written scope to list each Prep flow by name, its source systems and its output table.
The first decisions in a scope are technical and easy to under-specify. Teams should confirm which runtime each flow needs (a desktop run, a remote Hop Server or KNIME executors), which external scheduler will submit the work, where credentials are held, and who owns the landing database's grants and retention. For Hop, the scope should also say whether Kettle (.ktr and .kjb) files will be imported with the hop-import tool and how the output will be checked against the original Prep results. For KNIME, it should state which Hub plan, if any, supplies scheduling and team spaces, since that cost recurs and is separate from the free desktop tool.
Delivery covers the pipeline repository under version control, the container or service configuration, backups of the landing database and pipeline metadata, and a runbook for failed runs. Retainers cover the ongoing parts: patching the runtime and connectors, reviewing run logs, adjusting flows when source schemas change and testing new platform releases in staging before they reach production. Ask any provider to state in writing which of these items are in the fixed scope, which move to a retainer and what evidence you will receive at handover.
