Migrating templates using a directory with template.xml files as input
Learn how to use the migrate-templates
command to transform
downloaded template.xml files for compatibility with NiFi 2, which no longer supports
templates. This step is required to ensure successful migration to the target version. This
command combines the functionality of migrate-variables
and
migrate-components
, making it equivalent to migrate-all for templates.
While the migrate-templates
command simplifies the migration process, for
larger flows it is often better to run the variable and component migration steps
separately. You may also choose to migrate individual process groups to keep activity logs
and validation efforts manageable.
Example flow for migrating a template
This example uses two template files:
- TCP_Listener_template.xml
This file contains process group TCP Listener (ID: b41940d7-0194-1000-42fc-458834630567)
- Elastic_template.xml
This file contains process group Elastic (ID: b42881c7-0194-1000-3cdf-1bd453a0ed0f)

TCP Listener Process Group
This process group contains the following simple flow:

The process group defines a variable called TCP Listener Port, which is referenced by the ListenTCPRecord processor.

Elastic Process Group
This process group also contains a simple flow:

The process group has a variable, Elasticsearch Index, referenced in the Index property of the PutElasticsearchJson processor.

Your goal is to migrate the templates used in Cloudera Flow Management 2.1.7.2000 powered by NiFi 1 to parameters used in Cloudera Flow Management 4.10.0powered by NiFi 2.
The example guides you through variable migration one process group at a time, simplifying the process and maintaining a clear activity log. While these example templates are simple, the step-by-step approach shows how this method improves clarity for more complex migrations. In real-world scenarios, you have to define a migration strategy based on your flow’s structure.
Copy the TCP_Listener_template.xml and Elastic_template.xml files to the Migration Tool’s input folder (/etc/migration-tool-input).
-
Run Stage 1 template migration using the following command.
bin/migration.sh nifi migrate-templates \ -i /etc/migration-tool-input \ -od /etc/migration-tool-output/templates \ -sco
This generates a sourceVersion folder that contains the output files of the migration.
templates └── sourceVersion ├── Elastic_template_b4175f57-0194-1000-8470-9251a24519b4 │ └── Elastic_template.json ├── TCP_Listener_template_b41940d7-0194-1000-42fc-458834630567 │ └── TCP_Listener_template.json └── activity_log.json
The folder name Elastic_template_b4175f57-0194-1000-8470-9251a24519b4 and TCP_Listener_template_b41940d7-0194-1000-42fc-45883463056 are temporary process groups which were created during the migration process and used to separate the components in the template from other components that may be present during the migration.
- Elastic_template.json
-
-
Flow definition containing the contents of the original template
-
Equivalent to manually converting a template to a flow definition in NiFi 1 by:
- Instantiating the template on the canvas.
- Right-clicking the process group.
- Selecting Download flow definition without external services.
-
Modified by the Migration Tool to ensure compatibility:
- Variables (not supported in NiFi 2) converted into parameters
- Parameter context created to hold the new parameters
- Processors updated to reference parameters instead of variables
-
This is still a NiFi 1 flow definition, so do not load this file directly into NiFi 2. Use an empty NiFi 1 instance to review the modification made by the tool. The flow will appear unchanged, but variables will be replaced with parameters of the same name, which are now referenced by the processor instead.
-
Changes in the syntax: Variables were previously referenced using
${}
, whereas parameters are now referenced using#{}
.- NiFi 1
variables:
${variable_name}
- NiFi 2
parameters:
#{parameter_name}
- NiFi 1
variables:
-
- TCP_Listener_template.json
-
-
A modified flow definition, which is not compatible with NiFi 2 yet.
-
It contains everything the original flow definition did, except the TCP Listener process group now references a parameter instead of the removed variable.
-
This is still a NiFi 1 flow definition, so do not load this file directly into NiFi 2. Use an empty NiFi 1 instance to review the modification made by the tool. The flow definition will appear unchanged, but variables will be replaced with parameters of the same name, which are now referenced by the processor instead.
-
Changes in syntax: Variables were previously referenced using ${}, whereas parameters are now referenced using #{}.
- NiFi 1
variables:
${variable_name}
- NiFi 2
parameters:
#{parameter_name}
- NiFi 1
variables:
-
- activity_log.json
-
-
Log of all actions performed during this stage of the migration.
-
The following were changes made during the template migration:
- A new parameter context was created with a new parameter called TCP Listener Port, which replaces the corresponding variable.
- The TCP Listener Port variable was removed.
- A new parameter context was created with a new parameter called Elasticsearch Index, which replaces the corresponding variable of the same name.
- The new parameter is referenced from the PutElasticsearchJson processor.
- The Elasticsearch Index variable was removed.
-
-
Validate the Stage 1 template migration output for
Elastic_template.json.
-
Check the new flow definition in a NiFi 1 instance to verify that the
flow matches your expectations.
-
Start your NiFi 1 instance.
-
Create a new process group.
-
Load elastic_template.json to NiFi 1.
-
Confirm that variables were correctly converted to parameters.
-
-
Review activity_log.json and address any
manual-validation-requests
ormanual-validation-requests
. -
If there are
manual-change-requests
ormanual-validation-requests
to handle, follow these steps:-
Make the modifications on the NiFi canvas, indicated by the
manual-change-requests
ormanual-validation-requests
in the sourceVersion/activity_log.json. -
Right-click on the Elastic process group.
-
Select Download flow definition without external services.
-
Save the file as Elastic_template.json and overwrite the one in the sourceVersion/<process_group> folder.
-
Proceed to running Stage 1 variable migration on the Elastic_flow_definition.json.
-
- Proceed to running Stage 1 variable migration on the TCP_Listener_template.json.
-
Check the new flow definition in a NiFi 1 instance to verify that the
flow matches your expectations.
-
Validate the Stage 1 template migration output for
TCP_Listener_template.json.
-
Check the new flow definition in a NiFi 1 instance to verify that the
flow matches your expectations.
-
Create a new process group.
-
Load TCP_Listener_template.json to NiFi 1.
-
Confirm that variables were correctly converted to parameters.
-
-
Review activity_log.json and address any
manual-change-requests
ormanual-validation-requests
. -
If there are
manual-change-requests
ormanual-inspection-requests
to handle, follow these steps:-
Make the modifications on the NiFi canvas, indicated by the
manual-change-requests
ormanual-validation-requests
in the sourceVersion/activity_log.json. -
Right-click on the TCP Listener process group.
-
Select Download flow definition without external services.
-
Save file as TCP_Listener_template.json and overwrite the one in the sourceVersion/<process_group> folder.
-
- If none are present, proceed to the next step.
-
Check the new flow definition in a NiFi 1 instance to verify that the
flow matches your expectations.
-
Run full template migration (Stage 1 and 2), using the following command.
bin/migration.sh nifi migrate-templates \ -i /etc/migration-tool-input \ -od /etc/migration-tool-output/templates
The contents of the previously generated sourceVersion folder will be overwritten, but this is not a concern as the tool generates the same sourceVersion output as before. Additionally, a targetVersion directory is created, containing the output files of the Stage 2 part of the migration.
targetVersion ├── Elastic_template_b4175f57-0194-1000-8470-9251a24519b4 │ └── Elastic_template.json ├── TCP_Listener_template_b41940d7-0194-1000-42fc-458834630567 │ └── TCP_Listener_template.json └── activity_log.json
- Elastic_template.json
-
-
NiFi 2-compatible flow definition
-
Contains the contents of the original template converted into an exported process group.
-
This version is compatible with NiFi 2, but no longer supports NiFi 1.
-
- activity_log.json
-
-
List of all actions performed during this stage of the migration.
-
-
Validate the Stage 2 template migration output.
-
Check the new flow definition in a NiFi 2 instance to verify that the
flow matches your expectations.
-
Start your NiFi 2 instance.
-
Create a new process group.
-
Load elastic_template.json into a NiFi 2 instance.
The new process group will be called elastic_template and will contain another process group named elastic, matching the name of the process group that was converted into a template in NiFi 1 before you started the migration.
-
Verify parameter replacements and processor updates.
-
-
Review activity_log.json and address any
manual-change-requests
ormanual-validation-requests
.In this case, you can see the following
manual-change-request
:{ "sequence" : 4, "type" : "manual-change-request", "subject" : "a1468d69-3f30-3f83-a7c1-91dad09890f7", "message" : "New relationship [original] has been added, it has to be connected to a downstream processor or terminated.", "context" : { "rule" : "6501a693-b524-4d1a-b11e-69747c2651e8" }
-
Open the targetVersion/Elastic_template.json file and search for the "subject" ID, a1468d69-3f30-3f83-a7c1-91dad09890f7. This ID refers to the PutElasticsearchJson processor.
-
Go to the NiFi 2 canvas and check the processor. You will find that it has an unbound “original” relationship that needs to be connected to a downstream component.
-
Make the required change manually on the canvas.
-
Once done, export the process group. This exported process group is now a fully NiFi 2-compatible version of the original template.
-
Save the file.
-
- Validate the Stage 2 component migration output for TCP_Listener_template.json.
- Load the targetVersion/TCP_Listener_template.json into a NiFi 2 instance and check the flow.
-
Review the targetVersion/activity_log.json file.
In this example, you can see the following
manual-change-request entry
.{ "sequence" : 6, "type" : "manual-change-request", "subject" : "b41966ad-0194-1000-a08d-a92489457356", "message" : "The component has been deprecated. It is suggested to replace it with a combination of [org.apache.nifi.processors.standard.ListenTCP] and [org.apache.nifi.processors.standard.ConvertRecord] processors", "context" : { "rule" : "36227b60-75f0-40dc-8caf-a2ec577aa54c" }
-
Open the targetVersion/TCP_Listener_template.json file and search for the "subject" ID, b41966ad-0194-1000-a08d-a92489457356. This ID refers to the ListenTCPRecord processor.
-
To identify the processor affected by these changes, search for the identifier value of the “subject” element in NiFi’s search box. It refers to the ListenTCPRecord processor. Open the TCP Listener process group. You can see that the processor is marked with dashed borders and its version number still shows that of the NiFi 1 instance. It means that it is a "ghost processor", not available in NiFi 2. The log message suggests replacing it with a combination of ListenTCP and ConvertRecord processors.
Instantiate and configure the ListenTCP and ConvertRecord processors, connect them appropriately, and then remove the ghost processor.
Besides these changes there are no further
manual-change-requests
ormanual-validation-requests
in the Activity Log.
-
- Download the flow definition and you have the fully NiFi 2 compatible TCP_Listener_flow_definition.json.
-
Check the new flow definition in a NiFi 2 instance to verify that the
flow matches your expectations.
You have finished the template migration process.