NiFi 2 removed components: Hive, HBase, Kudu, Cassandra and Solr

Which removed components affect your flows and what to do

This table lists the component families from NiFi's deprecation list that do not appear in the NiFi 2.12.0 components index, with the release in which each was deprecated, what it means for a flow, and the action to plan. Absence from the 2.12.0 components index is the basis for treating these components as removed, so confirm each one in your own flows before you plan the cutover.

How to find every removed component in your flows

This sequence produces a complete, dated inventory of every flow element that uses a Hive, HBase, Kudu, Cassandra, Couchbase, Solr, ORC or Atlas component, so you know which flows must be replaced or retired before a NiFi 2 move. It covers the flow files, the version control history, the controller and reporting layers, and the parameter contexts that can hide references.

1. Confirm the removed component list first

   Before searching, build the list of component type names to look for. Use the NiFi deprecated components page, which lists the Hive 3 processors deprecated in 1.26.0, PutKudu from 1.28.0, the HBase components from 1.29.0, the Cassandra processors and ORC writer from 1.26.0, the Couchbase components from 1.27.0 and ReportLineageToAtlas from 1.26.0. Then check each name against the NiFi components index for 2.12.0, where none of these components appear. Record the exact class names and the version each was deprecated in, so the inventory can be reused in later upgrade planning. Done when you have a written list of type names that an engineer on the team has reviewed.

2. Export every process group and template

   A platform engineer with read access to the 1.x instance exports each top-level process group as JSON and collects any XML templates still stored on the instance, keeping them in a single read-only folder with the date of export. Include disabled and stopped process groups, because they are still part of what must be migrated. Also export the current flow.xml.gz from each node or from the cluster's primary node, and note the NiFi version and cluster name in the folder. Done when every process group on the canvas has a file in the folder and the count matches what the canvas shows.

3. Search exported definitions for component type names

   Run a text search across the exported JSON files and the decompressed flow.xml.gz for each type name from your list, such as PutHive3QL, PutHBaseRecord, PutKudu, PutCassandraRecord, QueryCassandra, PutORC and ReportLineageToAtlas, plus the Couchbase and Solr class names. Search for both the short name and the fully qualified class name, since the exported form can differ. Record the file, the process group path and the component name for every hit. Done when each search term has a result or a recorded zero count, and you have a hit list with group paths.

4. Check nested process groups and parameter contexts

   Search results can miss components inside nested process groups, so confirm that each exported file covers the full hierarchy, including child groups that appear only when expanded in the UI. Then review the parameter contexts attached to the groups. Hive connection strings, HBase configuration paths, Cassandra contact points and Kudu master addresses are often stored as parameters, and a processor may show only a parameter reference. Record each parameter that points to one of these systems so the reference can be traced back to the processor that uses it. Done when every hit is traced to a group path and every parameter linked to a removed system is listed.

5. Review Registry-versioned flows and controller services

   Flows under version control can differ from what is running on the canvas. Compare each versioned process group with its registry version, and identify any local changes that have not been committed. Include controller services in the search, since services such as Hive connection pools or Cassandra session services can exist without a processor on the canvas and still need replacement. Confirm which registry or repository holds each versioned flow, because that decides where the replacement must be committed. Done when every versioned group is marked as in sync or out of sync, and every controller service linked to a removed system is listed.

6. Check reporting tasks for Atlas lineage

   Reporting tasks run outside the flow canvas, so they are easy to miss. Open the controller settings and list every reporting task, whether running, stopped or disabled. Look specifically for ReportLineageToAtlas and any other reporting task that sends data to a removed system. Note the Atlas endpoint and the owning team for each task, because stopping an Atlas task on the 1.x instance changes what lineage is captured. Done when every reporting task has a line in the inventory, and each Atlas task is identified with its owner.

7. Include disabled and unused flows in the count

   Do not exclude a flow because it is disabled, stopped, seasonal or believed to be unused. A dormant process group can be restarted during a migration, and a disabled reporting task can be re-enabled by mistake. Mark each such item with its status and the last recorded run time from the provenance or log history where available. Ask the owning team to confirm whether each one should be migrated, replaced or retired. Done when every item in the hit list has a status and an owner decision field, even if the decision is still open.

8. Close the inventory with a signed-off hit list

   Combine the search hits, parameter references, controller services, versioned-flow status and reporting tasks into one table with one row per affected component. Each row should name the flow, group path, component, registry status, owner and disposition: replace, retire or keep on a 1.x island. Have a second engineer repeat a sample of the searches to confirm the results match. The output is a complete inventory that the replacement planning can work from. Done when the table is reviewed by the platform and application owners and the count of rows is recorded.

Replacement patterns for Hive, HBase, Kudu, Cassandra and Solr

What to prepare before you replace or isolate these flows

Removed components such as the Hive, HBase, Kudu, Cassandra and Solr processors are usually found late, after a flow has already been moved. The cards below cover the work that makes replacement or isolation predictable, from knowing every flow that touches these systems to getting sign-off from the teams that own the destinations.

When keeping a NiFi 1.x island is a defensible choice

Sequence for replacing removed components on the way to NiFi 2

This sequence moves each flow that depends on Hive, HBase, Kudu, Cassandra, Couchbase, Solr or Atlas onto a tested replacement, so that no data path is switched off before its successor has been reconciled and can be reversed.

1. Inventory every flow that uses removed components

   Export each 1.x flow definition and search it for processors and controller services from the deprecated list, including Hive 3 query and streaming processors, HBase record writers, PutKudu, Cassandra processors, Couchbase components, PutORC, ReportLineageToAtlas and any Solr usage. Record the process group, the destination system, the owning team and whether the component sits on a live path or a dormant one. The owner of each flow signs off the list. Done when every component reference is listed against a flow and an owner, and nothing is left as an unnamed 'other' item.

2. Classify each path and choose a replacement pattern

   For each inventoried path, decide whether the destination is retired, moved to a supported NiFi 2 processor bundle that writes to the same system, or moved to a different target that your data platform team already runs. Note the record format, the write semantics (append, upsert, delete), the schedule and any dependency on Atlas lineage or Solr queries. Paths that cannot be replaced directly are marked for a design decision before build. Done when each path has a named replacement or a retirement decision recorded with its approver.

3. Build replacement flows on a non-production NiFi 2

   Stand up a non-production NiFi 2 instance on Java 21, with the same parameter values as production but with test destinations. Build each replacement flow there, including its error relationships and retry behavior, and version it in your flow registry. Confirm that the 1.x flow definitions were moved to the flow.json.gz format through the 1.27.0 intermediate release before import, since the migration guidance requires both steps. Done when each replacement flow runs end to end against test data and its definition is stored in version control.

4. Run the 1.x and 2.x paths in parallel

   Keep the original 1.x path and the replacement running against the same source for a period you agree in advance, writing to separate staging targets. Compare row counts, key sets, field values and failure counts between the two outputs, and review provenance events for the replacement to confirm that every input reaches a terminal state. Investigate and fix every difference before continuing, and record which differences were expected. Done when the reconciliation report shows no unexplained gaps for an agreed window and the owner accepts it in writing.

5. Set a rollback point before each cutover

   Before switching a destination, take a copy of the 1.x flow definition, the parameter contexts, the controller service configuration, the state of any processors that hold state, and a backup of the target data where the replacement writes to it. Label the copy with the cutover date and the destination name. Confirm that the backup can be restored into a test instance. Done when the restore has been rehearsed and the rollback steps are written down for the on-call team.

6. Cut over one destination at a time

   Move one destination to its replacement in a planned change window. Stop the 1.x path for that destination, start the NiFi 2 replacement, and watch the queues, error counts and destination writes until the owner confirms the output. Do not move a second destination until the first has been stable for an agreed period. Done when the owner signs off the cutover and the change record links to the rollback point.

7. Keep the 1.x flow disabled but recoverable

   After each cutover, disable the original 1.x process group and keep it in place with its configuration and state intact, rather than deleting it. Record in the runbook when the retained copy can be removed and who decides. Confirm that a disabled flow cannot start by accident and that its credentials and sensitive values are still protected. Done when every retired path is marked disabled in the inventory with a named decision date and the retained copy is verified in storage.

What makes removed-component work take longer

This table compares the factors that expand removed-component work, why each one adds effort, and what to confirm before estimating. Read it as a checklist: the more rows that apply to your flows, the more likely the work moves from a component swap to a redesign with a destination owner, testing and a cutover plan.

Questions teams ask before replacing Hive, HBase and Kudu flows