Why replacing deprecated NiFi processors comes before the upgrade
If your team runs 1.x flows that must reach NiFi 2, swap out deprecated processors such as GetHTTP, PostHTTP, HashContent, HashAttribute, Base64EncodeContent and EncryptContent before you change the platform. These components are the ones that stop flows from loading or behaving the same way once the NiFi 2 runtime is in place, so inventory them while the flows still run on a version you can test against. The swap is easier to validate in the 1.x line, where you can compare outputs on the same data before and after each change.
The sequence is fixed. The NiFi migration guidance requires upgrading to NiFi 1.27.0 before moving to 2.0.0, and it changes the flow configuration file from flow.xml.gz to flow.json.gz. Confirm the exact steps for your starting version against the migration guidance, because the file format change affects how flows are backed up, restored and reviewed during cutover. Plan the processor replacements so that the flows you carry into 1.27.0 already use the replacement components wherever a mapping exists.
The 1.x line cannot be carried forward indefinitely. The NiFi project explains that 1.x depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, and those dependencies cannot be upgraded within that line, so 1.x receives no further maintenance. Staying on 1.x is therefore a security and supportability decision, not a stable holding position. Ask your internal owners to record which flows depend on deprecated components, who signs off each replacement, and the date by which the 1.x estate must be retired.
Which deprecated processors change and what each replacement affects
This table maps each deprecated processor in a NiFi 1.x flow to its NiFi 2 successor, with the behavior change that matters for existing flows and the action to take before upgrading. Read each row against the processors your flows actually use, and treat the GetJMSQueue row as an open item until the migration guide confirms its successor.
| Processor | Impact on flow behavior | Action needed |
|---|---|---|
| GetHTTP | Polling pull replaced by InvokeHTTP, which is triggered by incoming FlowFiles or a scheduled run, so the pull semantics and scheduling must be re-created | Rebuild the fetch as InvokeHTTP, set the URL, headers and timeouts, and test the schedule against the source |
| PostHTTP | Posting logic moves to InvokeHTTP, where method, body source and response handling are set on the processor rather than inherited | Reconfigure as InvokeHTTP with POST, confirm body and content type, and check how responses route on failure |
| HashContent | Content hashing moves to CryptographicHashContent, which may use different algorithm names and output attributes | Map the algorithm setting and the attribute name downstream flows read, then compare hash values on sample data |
| HashAttribute | Attribute hashing is handled by UpdateAttribute using the hash expression function, so the hash is set in an expression rather than a dedicated processor | Rewrite the attribute rule as an UpdateAttribute expression and verify the output matches the old value |
| Base64EncodeContent | Encoding and decoding move to EncodeContent, which selects the direction and encoding mode through its properties | Set EncodeContent to the matching encode or decode mode and confirm downstream consumers receive identical bytes |
| EncryptContent | Deprecated in NiFi 1.24.0. Successors are EncryptContentAge or EncryptContentPGP, which use different key material and file formats | Choose the successor that matches the format existing consumers expect, plan key handling, and re-test decryption of existing files |
| GetJMSQueue | Successor not confirmed in this guide. Confirm the replacement in the NiFi 2 migration guidance before planning this change | Check the migration guide and component documentation for the named successor, then scope the rebuild |
How the mapping differs by flow pattern
GetHTTP fetched a remote resource on a schedule and turned each response into a flowfile. Its replacement, InvokeHTTP, is a general request processor that sends a request and routes the response, so the polling behavior has to be rebuilt from scheduling and flow structure. The change affects the shape of the flow more than the component name suggests.
- Request method and target: Move the target address and method settings from GetHTTP into InvokeHTTP, and compare each value against the migrated example in the migration guide.
- Scheduling: Confirm in the InvokeHTTP component documentation how the processor is triggered. A polling flow needs a clear trigger source to replace the schedule that GetHTTP carried.
- Change detection: If the old flow relied on the source returning new content only, rebuild that check with attributes and routing. Confirm what GetHTTP actually did before assuming parity.
- Response routing: Map every success, failure and retry relationship on InvokeHTTP to a downstream path, because the old flow may not have handled each outcome.
- Credentials and TLS: Move authentication and trust settings into the new processor configuration or its SSL context service, then test them against the real source.
Run the old and new flows side by side in a test environment, using the migration guide, and confirm that every response path reaches the same downstream processors.
PostHTTP sent flowfile content to a remote endpoint. The NiFi 2 mapping points to InvokeHTTP, which you configure to send the POST method with the flowfile content as the request body. The sending logic is the same in intent, but the body, headers and response handling must be set on the new processor explicitly.
- Request body: Confirm which flowfile content or attribute becomes the body, since the old flow may have depended on defaults that the new processor does not share.
- Headers and content type: Set the content type and any custom headers that the receiving system expects, and verify them against a captured request from the old flow.
- Response handling: Check what the old flow did with the status code and response body, then route those outcomes to the same downstream logic.
- Retries and duplicates: Review how failed sends are retried, because a retry against a non-idempotent endpoint can deliver the same record twice.
- Endpoint security: Carry over client certificates, authentication and TLS trust settings, and confirm that the receiving system accepts the new client identity.
Before cutover, send a sample of each message type to a test endpoint and compare the received requests byte for byte with the old flow's output. Confirm the receiving team agrees with the retry and duplicate behavior before production traffic moves.
Three deprecated components in this group change in different ways. HashAttribute moves to UpdateAttribute, which uses the hash expression function to write a hash value into an attribute. HashContent maps to CryptographicHashContent, and Base64EncodeContent maps to EncodeContent. Each replacement writes its output to a different place or under a different configuration model, so downstream consumers can break even when the flow runs.
- Attribute hashing: Rewrite each HashAttribute as an UpdateAttribute setting that calls the hash function on the source attribute, and keep the output attribute name identical to the old one.
- Content hashing: For HashContent, confirm the algorithm and the attribute where CryptographicHashContent writes its result, since downstream routing often reads that attribute by name.
- Encoding direction: Check that EncodeContent is configured to encode, not decode, and that the output matches Base64 output produced by the old processor.
- Hash stability: Compare hashes computed by the old and new flows on the same sample input. Any mismatch will break deduplication or integrity checks that depend on stored values.
- Attribute collisions: New attribute writes can overwrite attributes that other processors read, so review the attribute names used across the flow.
Run identical sample inputs through both flows and compare every output attribute and content byte. Confirm that stored hash values in external systems still match what the migrated flow produces.
EncryptContent was deprecated in NiFi 1.24.0, and the project points to EncryptContentAge or EncryptContentPGP as replacements. These two processors use different encryption formats and key handling, so they are not interchangeable with the old component. The choice depends on the systems that read the encrypted output, not only on the flow itself.
- Format selection: Choose between age and PGP based on what the receiving systems can decrypt, and confirm that choice with the teams that own those systems.
- Key material: Move passphrases, keys and recipient settings into a secure location and confirm how the new processor handles sensitive values in configuration.
- Data already encrypted: Data written by the old processor still needs a decryption path. Plan whether to decrypt it with the old processor on a 1.x instance or to re-encrypt it, and check whether any 1.x island is needed.
- Output compatibility: Output from the new processor will differ from the old format, so downstream decryption must be tested with the new output.
- Audit trail: Confirm that provenance records and logs still show which content was encrypted and which key or recipient was used, without exposing key material.
Round-trip test a set of files from encryption through decryption on the target systems, and keep the old decryption path available until every archived file has a confirmed way to be read.
Preparing flows, backups and a test environment before swapping processors
Replacing deprecated processors is safe only when you know where they are, can restore the original state, and can prove the replacement behaves the same. The four items below set up that baseline before any flow changes. Each one feeds the next: the inventory defines the scope, the backup gives you a rollback point, the test instance gives you a place to compare output, and the code review catches dependencies outside the canvas.
Inventory every deprecated component
Search every flow and process group, including nested groups, reusable process groups and flows held in a registry, for the processors being replaced: GetHTTP, PostHTTP, GetJMSQueue, HashContent, HashAttribute, Base64EncodeContent and EncryptContent. Record the process group path, the processor name, its scheduling and its upstream and downstream connections. Ask your team to confirm whether any flow is inactive or stopped, because those are easy to miss and still break at upgrade time.
Back up the flow definition
Export the flow definition and keep a copy of the flow configuration file, which in 1.x is stored as flow.xml.gz, together with nifi.properties and the sensitive properties key. Store them in version control or an access-controlled backup location. Verify the backup by restoring it to a scratch instance and confirming that the process groups load. Without this copy, rolling back a failed swap means rebuilding flows by hand.
Stand up a NiFi 1.27.0 test instance
Build a non-production NiFi 1.27.0 instance with the same processors, controller services and parameter values as production, using sanitized data. This version is the required stepping stone before 2.0.0, so it is also the instance where you capture baseline output. Run the original and replacement flows side by side and compare FlowFile content, attributes, record counts and error routing. Confirm the test instance is isolated from production endpoints.
Find custom code that calls these components
Search custom processors, NARs, scripted components in ExecuteScript and InvokeScriptedProcessor, and external scripts that reference the deprecated processor names or their property names. Also check any code that reads attributes set by HashAttribute or expects Base64 or encrypted output in a specific format. Record each finding with its owner, because a replacement in the flow can break downstream code that depends on the old output.
The order to replace processors and verify each flow
This sequence moves each flow off deprecated processors in NiFi 1.x while the old behavior is still available to compare against, then carries the flows through the version and configuration changes that NiFi 2 requires. Each step ends with a check and a point you can roll back to.
Inventory deprecated processors across all flows
Before changing anything, list every process group and processor type in use, including flows inside nested groups, reporting tasks and controller services. Compare that list against the deprecated and removed components named in the migration guidance, such as GetHTTP, PostHTTP, GetJMSQueue, HashContent, HashAttribute, Base64EncodeContent and EncryptContent. Record each finding with the flow it sits in and its owner. Done when every hit has a row in the inventory and the team has agreed which flows are in scope for this upgrade.
Replace processors in 1.x where the successor behaves the same
For each finding, swap in the replacement the project publishes: EncodeContent for Base64EncodeContent, InvokeHTTP for GetHTTP and PostHTTP, CryptographicHashContent for HashContent, UpdateAttribute with the hash expression function for HashAttribute, and EncryptContentAge or EncryptContentPGP for EncryptContent. Run the changed flow against the same test input as the original and compare output content, attributes and routing. Replace only where the successor produces the same result, and keep the original flow in a disabled state as a comparison point. Done when each changed flow's output matches the original on the test set.
Export and version the flows
Export each changed process group in its current form and commit it to version control, tagging the commit with the 1.x release it was validated on. Store the exported files alongside the replacement notes so any reviewer can see which processor was swapped and why. Confirm that the export can be re-imported into a clean 1.x instance and produces the same flow. Done when a clean import reproduces each validated flow and the commit history records every swap.
Move the cluster to NiFi 1.27.0
Upgrade the 1.x installation to NiFi 1.27.0, which the migration guidance requires before moving to 2.0.0. Perform the upgrade on the same schedule and procedure your team uses for cluster changes, and keep the previous 1.x installation and flow configuration available for rollback. Run the replaced flows on 1.27.0 and confirm the processors still produce the validated output. Done when all nodes report 1.27.0, the flows run without new errors, and the previous installation remains available for rollback.
Upgrade to NiFi 2.0.0 and convert the flow file
Upgrade from 1.27.0 to 2.0.0 and convert the flow configuration file from flow.xml.gz to flow.json.gz as the migration guidance describes. Keep the original flow.xml.gz file untouched so you can restore 1.27.0 if the conversion must be reversed. Confirm the converted file is picked up at startup and that the process groups appear as they did in 1.x. Done when the instance starts on 2.0.0 with flow.json.gz, the process group count matches the inventory, and the original XML file is preserved.
Validate each flow against its baseline
Run each replaced flow on 2.0.0 with the same test inputs used in 1.x and compare outputs, attributes, routing and error paths against the recorded baseline. Check the logs and bulletins for deprecation or configuration warnings on the new components, and confirm that the sensitive values and variable references still resolve. Record any difference as a defect with an owner and resolve it before the flow is accepted. Done when every flow matches its baseline or has an approved, documented difference, and no open bulletins remain for the replaced components.
Confirm rollback points and sign off each flow
Verify that each step has a working restore path: the 1.x export and tagged commit, the 1.27.0 installation, and the preserved flow.xml.gz. Test one restore on a non-production instance so the team knows the procedure works before production cutover. Obtain sign-off from the flow owner for each validated flow and file the test records with the change. Done when each flow has a named owner's approval, the rollback procedure has been exercised once, and the records are stored with the change.
How to prove the replaced flows produce the same output
Prove parity with the same input on both sides before any production traffic moves. Take a representative set of sample files and messages, run them through the original 1.x flow and the replacement flow on NiFi 2, and compare what comes out. For the hash swap, compare the value written by HashContent or HashAttribute with the value produced by CryptographicHashContent or the hash expression function in UpdateAttribute, using the same algorithm and the same attribute name. For the encoding swap, compare Base64EncodeContent output with EncodeContent output byte for byte, and check that content with non-ASCII characters and empty files behaves identically. For GetHTTP and PostHTTP, compare the status codes, headers and bodies that InvokeHTTP returns, since the old processors' defaults are not guaranteed to match. Confirm each of these against the migration guidance and your own sample data rather than assuming equivalence.
Use provenance and a written acceptance checklist to show the result, not just the intent. Provenance events on both instances should show the same routing relationships, the same content claims for the outputs and the same failure paths for bad input. Record the comparison in a sign-off document that names the flow, the processor pair, the test inputs, the expected attributes and the owner who accepted each result. Include the EncryptContent case separately: if the flow still uses EncryptContent, confirm whether the replacement (EncryptContentAge or EncryptContentPGP) can decrypt files produced by the old processor before you retire the old key handling.
Keep the 1.x instance, its flow file and a verified backup until acceptance is signed. Rollback in this case means starting the 1.x instance again and restoring its flow file, not reverting individual processors on NiFi 2. The flow file format changes in NiFi 2 (from flow.xml.gz to flow.json.gz), so a 2.x flow cannot be read back by 1.x. Store the original flow file, the nifi.properties and the sensitive properties key together, and test that the restore works on a copy of the host. Confirm with your own operations team how long the 1.x environment stays available and who decides when it is decommissioned.
What makes deprecated processor replacement take longer
This table compares the factors that expand a deprecated-processor swap beyond a simple processor-for-processor change, and what to check for each. Read it before estimating scope, because the number of flows and the output dependencies usually matter more than the processor count. The main takeaway is that comparison testing and hash or encoding compatibility, not the swap itself, tend to set the schedule.
| Driver | Why it adds work | What to check |
|---|---|---|
| Number of flows using each processor | Every flow, process group and template that references GetHTTP, PostHTTP, GetJMSQueue, HashContent, HashAttribute, Base64EncodeContent or EncryptContent needs its own review and retest. | Search all flow definitions and registry versions for each processor type, including nested process groups and disabled components. |
| Custom NARs or scripts wrapping these processors | Custom processors or scripted components that call deprecated processors, or copy their behavior, must be rebuilt along with the flows. | Inventory custom NARs and ExecuteScript code for references to the deprecated classes or their property names. |
| EncryptContent key handling and format | EncryptContent was deprecated in NiFi 1.24.0, and its replacements, EncryptContentAge or EncryptContentPGP, use different key material and output formats, so existing ciphertext may not decrypt unchanged. | Confirm the key source, password or key file for each flow, and test decryption of archived ciphertext with the new processor. |
| Sample data volume for comparison testing | Side-by-side runs need representative inputs, including edge cases such as empty files, large files and unusual character encodings, before results can be trusted. | Agree a sample set per flow with data owners, and confirm the storage and time needed to run old and new flows on it. |
| Downstream dependence on exact hash or encoding output | Consumers that compare digests or decode Base64 strictly may fail if the new processor or attribute expression changes case, format or content boundaries. | Ask each downstream owner which hash algorithm, encoding and output field they expect, and compare byte-for-byte outputs on the sample set. |
| Attribute-based versus content-based logic | HashAttribute moves to UpdateAttribute with the hash expression function, so flows that route on hash attributes must be rechecked against the new attribute values. | Trace each route or filter that reads a hash attribute and confirm the expression produces the same values. |
| Migration sequencing with other changes | Processor swaps often overlap with parameter, Java 21 or registry changes, so a single flow may need several edits at once. | Confirm the change order with the upgrade plan and check whether flows also depend on items in sibling upgrade topics. |
Questions teams ask before replacing deprecated NiFi processors
What does replacing deprecated NiFi processors cost, and what drives the quote?
The cost is set by how many flows use deprecated processors, how complex each one is, and how much testing the replacements need. Most of the work is analysis and verification rather than swapping component names. Each flow's processor count, record handling, attribute dependencies and downstream consumers change the effort. The mappings are published: Base64EncodeContent maps to EncodeContent, GetHTTP and PostHTTP map to InvokeHTTP, HashContent maps to CryptographicHashContent, and HashAttribute maps to UpdateAttribute using the hash expression function. Replacing EncryptContent is usually the largest item because it touches stored data. Ask for a quote built from a written inventory of affected flows, the work per flow, test evidence required and whether the price covers one environment or several. Costs are one-time for the migration and recurring only if you keep a retainer for later upgrades.
How long does replacing deprecated processors take?
Duration depends on the number of affected flows, how many of them run in production, and how much functional testing is needed to show that outputs match. Flows that only fetch over HTTP and write files are usually quicker to verify than flows that hash or encrypt content consumed by other systems. Parallel environments, change windows and approval steps can add time even when the technical change is small. No public timeline is supplied for this work, so ask for a schedule in the written scope with milestones for inventory, replacement, testing and cutover. Confirm which dependencies, such as the NiFi 1.27.0 step required before moving to 2.0.0, are already in place in your environment, since they can move the start date.
What must our team provide before the work starts?
The engagement runs faster when your team supplies the inputs that show how flows behave. Typically this includes:
- Flow definition exports for every process group in scope, plus the version of NiFi each runs today
- Read access to the running NiFi instances, and a non-production environment where replacements can be run
- Sample input data and expected outputs for each flow, including hashes or encrypted payloads that other systems depend on
- Named owners for each flow who can confirm business behavior and sign off on tests
- Keys, passphrases or key stores needed to decrypt existing EncryptContent output
- A change calendar and a rollback plan agreed with operations
Confirm access and data handling rules with your security team before sharing production exports, because flow definitions can contain sensitive values.
Can our internal team replace the deprecated processors without a partner?
An internal team can do this if it has NiFi operators who understand the flows, a non-production cluster, and time to test each replacement against known outputs. The mappings the project publishes cover the common cases, and sample flow definitions show the before and after forms. The harder parts are finding every use of a deprecated component across process groups, confirming that replacement processors give identical results for your data, and coordinating cutover across nodes. Decide which of these your team can own and which you want to outsource, and write that split into the scope so accountability is clear. Confirm with your own engineers how much time they can commit before the upgrade date.
How does replacing EncryptContent affect data that is already encrypted?
Existing data encrypted by EncryptContent stays encrypted with its original method, so replacing the processor does not decrypt it. EncryptContent was deprecated in NiFi 1.24.0, and the published replacements are EncryptContentAge and EncryptContentPGP. Those processors use different formats and key handling, so new output will not necessarily be readable by old tools or the reverse. Before cutover, inventory where encrypted content is stored, who decrypts it, and which keys and passphrases are required. Plan a decryption and re-encryption step if archived data must move to the new format, and test that every consumer can read both old and new output during the transition. Confirm the exact compatibility details with the NiFi documentation for your version before you commit to a method.
Do the replacement processors produce the same output as the deprecated ones?
Not always, so output must be tested rather than assumed. Replacements may name attributes differently, handle record formats in a different way, or produce hash and encoding results through a new expression path. The published mappings tell you which component replaces which, but they do not replace comparison testing with your own data. Run old and new flows side by side on the same input, compare content and attributes byte for byte where downstream systems depend on them, and record the results as evidence. Ask any partner to show this test method in the written scope.
Does this work cover audit evidence for compliance reviews?
The work can produce the records a reviewer expects, such as the inventory of changed flows, test results, change approvals and rollback steps. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Independent auditors and certification bodies make that determination. Ask which records will be delivered, how they are stored, and who in your organization approves each change before you rely on them for an assessment.
How DeployOpen works on this
DeployOpen plans and implements the replacement of deprecated NiFi processors inside your own infrastructure, starting from an inventory of the flows that use them. Each replacement is checked against the mappings the project publishes, then tested and documented so your team can run the upgraded flows after handover.
How we scope
- Inventory every flow and process group that uses a removed or deprecated processor, across all node and registry environments
- Map each processor to its published NiFi 2 replacement and record properties that need manual translation
- Agree the written scope, deliverables and timeline in writing before any flow changes begin
How we build
- Rebuild each affected flow in a non-production NiFi 2 environment using the published sample flow definitions as reference
- Compare output content, attributes and error routing between the original and replacement flows using representative test data
- Keep changes in version-controlled process groups so every replacement can be reviewed and reverted
How we hand over
- Deliver a replacement register listing each old processor, its new component, and the changed properties
- Provide test evidence, runbooks for promotion, and notes on flows that need follow-up before the NiFi 2 cutover
- Walk your operations and flow owners through the changes so they can maintain the flows after handover
How we support
- Support the cutover window and fix defects found in replaced flows during the agreed post-handover period
- Offer ongoing support, upgrades and continuous testing for NiFi 2 as a retainer when your team wants continued help
- Confirm with your team which later 2.x upgrade steps, such as removed properties, apply to your environment
