Apache NiFi cost of ownership and editions

What does Apache NiFi cost of ownership include when the software itself is free?

Apache NiFi has no paid edition from the project, so the cost of running it is the cost of everything around the software. The Apache-2.0 license removes the software line from your budget, but it does not include the cluster hosts, storage, monitoring, staff time or upgrade work that keep a production dataflow running. Those are the costs a commercial NiFi-based product or managed service prices into its quote, so a fair comparison only works when you price the same components on both sides. Most teams reach this question for one of three reasons: a new rollout needs a budget line, NiFi 1.x has reached end of support, or an annual budget review asks why a free tool carries a large operating cost.

Infrastructure and storage usually make up the largest recurring share. A production NiFi cluster runs several nodes, each sized for its flow volume and each needing Java 21 as the minimum runtime. The content, FlowFile and provenance repositories grow with data volume, and provenance retention is often the biggest lever on storage cost. Clustering adds coordination: either an embedded or external ZooKeeper ensemble, or Kubernetes leases for state and leader election, each of which is another component to run, patch and back up. Ask your team to document the node count, the retention period you need for provenance, the storage class for each repository, the backup target and the load balancer in front of the cluster. Each of these items recurs every month, and each one changes when data volume grows.

People and upgrades are the costs most often left out of early estimates. Installation, identity provider integration, replacing single-user access, flow development, custom processor maintenance and on-call rotation all consume engineering time, and most of that time recurs after go-live. The upgrade path also has a fixed cost. NiFi 1.28.1 reached its end-of-support date of December 8, 2024, and the project explains that 1.x cannot be maintained further, so teams still on 1.x face a migration that goes through NiFi 1.27.0 and changes the flow configuration file to flow.json.gz. After that, every minor release needs testing time. NiFi 2.12.0 was released on September 13, 2026, which shows the cadence a platform team should plan to follow. Planned removal of NiFi Registry in NiFi 3.0 is a later cost you should record now.

The in-house or partner question depends on skills and timing. Many teams run NiFi themselves once a platform group owns the cluster, the identity integration and the flow lifecycle. Teams often bring in a partner for the initial design, security setup and a multi-year plan that sets out upgrade windows, staffing and retirement dates for dependencies. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish prices. A quote follows from the written scope, so the most useful input you can give is a clear list of components, environments, years to cover and the internal skills you already have.

What a NiFi cost of ownership study covers and what it delivers

A cost of ownership study turns your current and planned NiFi usage into a multi-year cost picture you can compare against commercial and managed options. Each element below feeds the model, and the deliverables show how the numbers were reached.

Inventory of flows and volumes

We catalog your existing or planned flows, their processors, controller services, throughput, peak bursts, retention needs and the systems they connect. Volume and burst profiles drive cluster size, repository storage and network costs, so the inventory is built from your own metrics and data sources rather than estimates. Ask which flows are in scope and which data was used for each figure.

Target topology decision

The study compares a standalone node, a clustered deployment coordinated by an embedded or external ZooKeeper, and a Kubernetes deployment that uses ConfigMaps or Leases for state and leader election. Each option carries different infrastructure, operations and skills costs. We record the topology chosen and the reasons, so the model reflects a decision you can review.

Multi-year cost model

The model separates one-time costs, such as design, migration and initial security setup, from recurring costs, such as compute, storage for the content, provenance and flowfile repositories, backups, monitoring, staff time and support. It shows how each component changes across the years in scope. Ask for the model in a format your finance team can rerun with changed inputs.

Comparison with commercial and managed options

Apache NiFi is licensed under Apache-2.0 and has no paid edition from the project itself, so the comparison is against commercial NiFi-based products and managed services that you would evaluate on their own terms. We compare the same workload, retention and support levels across options. Confirm each vendor's licensing basis, support terms and data residency directly with them.

Assumptions register

Every input that is not measured, including growth rates, staff rates, hosting prices, support levels and release cadence, is written into a register with its owner, source and the sensitivity of the result to it. Reviewers can see which assumptions change the decision and which ones do not. Ask for the register to be reviewed with your finance and platform leads before the decision memo is written.

Decision memo and handover

The decision memo summarizes the scope, the topology, the cost comparison, the sensitivities and the recommended path, including the migration and version timing that affects cost. The model and register are handed over so your team can update them. The study is a planning document and does not produce an audit report, attestation or certification.

Which factors raise or lower NiFi ownership costs

This table lists the drivers that move the cost of running Apache NiFi yourself, why each one changes cost or effort, and how to keep it under control. Read each row against your own flow inventory and environment plan, because most drivers multiply with each other. The main takeaway is that the NiFi line you choose and the number of environments and flows usually matter more to long-term cost than the software itself, which is free under Apache License 2.0.

Driver	Why it changes cost	How to keep it down
Throughput and flow count	Higher event volume and more flows need larger nodes, more heap and disk I/O, and more time to tune back-pressure and monitoring.	Measure throughput per flow before sizing. Group low-volume flows, set back-pressure thresholds deliberately and retire flows that no longer run.
Number of environments	Each environment (dev, test, staging, production, disaster recovery) repeats cluster infrastructure, security setup and promotion work.	Keep non-production clusters smaller, use parameter contexts so one flow definition serves every environment, and automate builds with infrastructure as code.
Cluster size and availability target	Node count drives compute, storage, load balancing and ZooKeeper or Kubernetes coordination. Higher availability targets add nodes and failover testing.	Confirm the availability target with the business owner first. Size for real peak load plus one node of headroom rather than for worst-case assumptions.
Repository storage and retention	Content, FlowFile and provenance repositories grow with volume and retention period. Fast disks for repositories also cost more per terabyte.	Set provenance and content retention per flow class. Put repositories on storage sized from measured data, and monitor disk growth from day one.
Integrations and custom processors	Each external system needs connection design, credentials and testing. Custom Java or Python processors need build pipelines, NAR packaging and rebuilds for each NiFi release.	Prefer built-in processors where they meet the requirement. Document each custom processor's owner, build process and target NiFi versions.
Authentication and security controls	Connecting to an identity provider through OpenID Connect, SAML 2.0 or LDAP, plus TLS, access policies and sensitive property encryption, adds design, testing and review effort. Single-user mode is not a production option.	Use one identity provider integration for all environments. Avoid the deprecated Kerberos provider for new work. Reuse a standard access policy model across flows.
Compliance evidence needs	Assessors expect documented access reviews, change records, encryption settings and backup tests. Collecting this evidence is recurring work, and an independent auditor issues any attestation, not DeployOpen.	Agree the evidence list before build starts. Export configuration and flow versions from source control on a fixed schedule instead of assembling records at audit time.
NiFi line: 1.x end of support versus 2.x	NiFi 1.28.1 reached end of support on December 8, 2024, per the NiFi downloads page. Staying on 1.x leaves you without fixes, and the move to 2.x requires the 1.27.0 stepping stone, flow.json.gz conversion and changes to removed variables and renamed components.	Plan the migration as one fixed-scope project. Start on NiFi 2 for new flows. Budget testing of existing flows against the migration guidance and confirm Java 21 runtime readiness on every node.

How a NiFi cost model is built, step by step

The sequence turns a loose sense of NiFi spend into a written model that shows which costs are one-time, which recur, and how the self-hosted option compares with commercial and managed alternatives over the period you care about.

Inventory current or planned flows and data volumes
DeployOpen reviews the flows you run or plan to run, including sources, sinks, processor counts, peak and average throughput, retention needs and the number of environments. You provide access to flow definitions or design notes and the volume figures your teams already track. The phase closes with a written inventory that lists each flow, its volume profile and the open questions that could change sizing. You confirm the inventory before anything is modeled.
Define topology and sizing options
Using the inventory, the team sketches two or three deployment topologies, such as a standalone node for non-production, a clustered setup with embedded or external ZooKeeper, or a Kubernetes-based cluster. Each option states node count logic, repository storage placement, network paths and the failure cases it tolerates. The output is a set of sizing options with stated assumptions, which you review to choose the shapes the cost model will price.
Model infrastructure and storage costs
For each topology, the model lists compute, memory, disk for the content, flowfile and provenance repositories, backup storage, load balancing and network egress in your own cloud accounts or data centers. Infrastructure is mostly recurring and scales with node count, retention and throughput. You confirm rates with your cloud or hardware contracts, because DeployOpen does not set them. The output is a line-item table separating one-time setup from monthly or annual running costs.
Model people, support and upgrade effort
This phase covers the staff time NiFi consumes: platform administration, flow development, security operations, on-call coverage, and periodic upgrades, including custom processor rebuilds. It also covers any support agreement you choose, whether internal or from a vendor or partner. Effort is split into one-time build work and recurring operations. The output is a staffing and support schedule with named roles, and you check it against your own salary bands and on-call policy.
Compare with commercial and managed alternatives
The modeled self-hosted totals are placed next to commercial NiFi-based products and managed services quoted for the same flows and volumes. Each comparison lists what the alternative includes, such as licensing, hosting, upgrades, support terms and data residency, and what it leaves to you. You request written quotes for these alternatives, since published terms vary. The output is a side-by-side view of recurring and one-time costs over the same period, with unpriced gaps flagged.
Hold a decision review
DeployOpen and your stakeholders walk through the model, the assumptions behind each line and the sensitivity to volume growth, retention and staffing. Security, platform and finance leads record which assumptions they accept, challenge or need to verify. The review closes with a signed-off model or a list of items to resolve. Ask for the phase plan and dates in the written scope before work starts, since sequencing depends on your inputs and access.

Which parts of a NiFi cost analysis teams keep in-house and which they outsource

Keep the decisions that depend on your business context inside the organization, and consider outsourcing the modeling work that needs specialist engineering. The business owners of each flow should state which data feeds matter, how long they must be retained, and which outages they can tolerate. Data classification also stays internal, because it determines whether a flow carries regulated personal data, which in turn determines how many nodes, how much encrypted storage and how much provenance retention the cost model must include. Final budget approval and vendor negotiation belong with the people who sign the contracts and carry the risk, since they hold the context the model cannot capture. Outsourcing is most useful for the technical build of the model. Topology sizing requires NiFi operations experience: how the flow file, content and provenance repositories grow under load, how a ZooKeeper or Kubernetes-based cluster behaves when a node fails, and how JVM heap and garbage collection settings change throughput on Java 21. Linux tuning for file descriptors, disk I/O and network buffers is a separate skill set that a platform team may not have on hand. A partner or a specialist internal engineer can translate those findings into node counts and storage tiers you can defend in a review. Benchmark design is the next outsourced task. A useful benchmark replays representative flow volumes, measures backpressure thresholds and records repository disk usage over time. This needs storage engineering to choose the right test disks and identity skills to reproduce authenticated access, because a benchmark run as a single-user account will understate the cost of LDAP, OpenID Connect or SAML 2.0 integration. Ask whoever designs the benchmark to document the workload, the hardware and the assumptions in writing so the results can be rerun after a NiFi 2 minor release. Comparing licensing and support terms is a finance and legal task that benefits from technical input. NiFi itself is licensed under Apache-2.0 with no paid edition from the Apache Software Foundation, so the comparison is between the staffing, infrastructure and support you buy yourself and any commercial NiFi-based product or managed service. Ask each vendor what its support covers for NiFi 2 versions, how it handles the Java 21 and Python processor requirements, whether custom processors are included, and which exit terms apply. Check each answer against your own flow inventory before accepting it as a cost input. Finally, record who owns each assumption in the model. When an internal owner signs off on a number, note the date and the evidence behind it. This keeps the cost analysis usable after the team changes and makes it clear which figures need to be refreshed when your NiFi version, cluster size or retention policy changes.

Where NiFi cost estimates usually go wrong

The cards below cover the assumptions most often missing from Apache NiFi budgets. Each one should be a line item in the model for the full planning horizon, not only the first year. Work through them with the same scope you use for the platform itself so that comparisons with commercial or managed options stay fair.

Repository storage and provenance growth

Estimates often size the cluster for flow throughput and forget the disk the repositories need. NiFi writes content, FlowFile and provenance data to repositories on each node, and provenance retention follows your policy, so it grows with flow volume and the number of days you keep records. Model storage per node from expected data volumes, retention periods and peak backlog, then include growth over the planning horizon. Confirm with the vendor or your own tests how provenance indexing behaves at that size.

Staying on NiFi 1.x

A model that keeps the 1.x line for several years is carrying a platform the project no longer maintains. The NiFi downloads page lists December 8, 2024 as the end-of-support date for 1.28.1, and the project states that 1.x cannot be maintained further because of its Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8 dependencies. Add a migration line item for the years in question, covering the 1.27.0 stepping stone, flow configuration conversion and testing. Ask any support provider what coverage they will give on 1.x.

One cluster, no non-production

Budgets often cover one production cluster and nothing else. Development, test and staging environments need their own infrastructure, storage, identity configuration and flow testing time, and any upgrade or migration needs a place to rehearse before cutover. Model each environment's footprint explicitly, including whether it runs a smaller cluster or a single node. Decide whether those environments mirror production security settings, and include keeping them on the same NiFi release as production in the recurring cost.

People cost of upgrades and rebuilds

Licensing costs are easy to see, while engineering labor is spread across teams and rarely tracked. Each minor release, rolling cluster upgrade and custom processor rebuild requires engineers to review deprecations, recompile NARs, run flow tests and coordinate change windows. Estimate hours per release cycle using the number of custom processors and controller services you own, plus on-call time for upgrade incidents. When requesting a quote, ask partners to separate one-time build effort from recurring upgrade effort.

The free license is one line

Apache NiFi is released under the Apache License 2.0, and the project itself offers no paid edition, so the license fee is zero. The total still includes compute, storage, network, identity integration, monitoring, backups, staff time and any support agreement you buy from a third party. Commercial NiFi-based products and managed services bundle some of these items differently, so compare them on the same scope. List every component in the model, then ask each vendor which items their quote covers.

Registry workflows assumed to persist

Teams that version flows with NiFi Registry may assume the workflow will continue unchanged through upgrades. The NiFi downloads page notes that NiFi Registry is deprecated and planned for removal in NiFi 3.0, while NiFi 2 includes Flow Registry Clients for GitHub and GitLab that store flows in a Git repository. Model the cost of moving version control to a Git-based client, rebuilding bucket permissions and promotion steps, and retraining users. Confirm the NiFi 3.0 timing with the project before fixing a date in your plan.

Recurring costs after NiFi goes live

This table lists the cost components that continue after a NiFi cluster goes live, marked as one-time or recurring. The Apache-2.0 project itself has no license fee, so the costs come from infrastructure, people and any commercial products you add. Use the third column to see what drives each line and what to ask for in a fixed-scope quote.

Cost component	One-time or recurring	What drives it and what to request in a quote
Compute for cluster nodes	Recurring	Node count and size follow flow throughput and redundancy. Ask for node count, instance sizes, and the pricing basis for each environment.
Load balancing and networking	Recurring	Load balancers, ingress, and inter-node traffic. Ask which load balancer, TLS termination point, and bandwidth charges are included.
Repository storage	Recurring	Content, flowfile, and provenance repositories grow with data volume and provenance retention. Ask for storage class, retention settings, and expected growth.
Backup and disaster recovery	One-time setup, recurring operation	Backups of flow definitions, repositories, and encryption keys, plus restore tests. Ask for backup frequency, retention, and restore test scope.
Coordination (ZooKeeper or Kubernetes)	One-time setup, recurring operation	Embedded ZooKeeper runs on nodes, external ZooKeeper adds servers, and Kubernetes uses ConfigMaps or Leases. Ask which mode is priced and who operates it.
Monitoring and logging	Recurring	Metrics, log storage, dashboards, and alerting, often in existing tools. Ask whether the quote includes tooling licenses and log retention costs.
Identity provider licensing	Recurring if commercial, one-time integration	NiFi adds no per-user fee for OpenID Connect, SAML 2.0, or LDAP. Any license cost comes from your identity provider contract, so confirm user counts with that vendor.
Support agreements and commercial editions	Recurring	The project has no paid edition, and community support carries no service levels. Commercial NiFi-based products charge subscriptions that vary by edition and vendor. Ask each vendor for edition scope, term, and renewal terms in writing.
Upgrades, custom processors, and internal skills	Recurring	Minor release upgrades, rebuilding custom NARs, regression testing, and staff time. Ask how upgrade and rebuild effort is scoped in a support or retainer agreement.

How NiFi cost differs by starting point and environment

If your current dataflow platform is a commercial product built on NiFi, the license line changes most. Apache NiFi is released under the Apache License 2.0 and has no paid edition from the project, so the vendor subscription fee stops, but the work of replacing vendor-specific features does not.

Licensing: Vendor subscription or support fees for the product end, while any proprietary processors, connectors or management features need an open-source equivalent or a rebuild.
Flow mapping and testing: Flows that use vendor-specific components must be mapped to Apache NiFi components and tested with representative data before cutover.
Operations tooling: Monitoring, alerting and backup routines tied to the vendor console need new owners and new runbooks.
Staff skills: Engineers who know the product's administration console need training on NiFi configuration, clustering and its security model.
Parallel running: Both platforms may run side by side for a period, which adds infrastructure and operator time for that window.

Ask the provider to list every component in your current flows that has no direct Apache NiFi equivalent, and to confirm who owns the mapping work and how long the parallel run is planned to last.

What your team needs to provide before a NiFi cost review starts

A NiFi cost review is only as accurate as the inputs behind it. Before any model is built, your team should supply a flow inventory covering every flow that is running or planned, with the processor count, source and destination systems, and whether each flow is new or must move from an existing 1.x cluster. The NiFi downloads page lists an end-of-support date of December 8, 2024 for 1.28.1, so any flow still on 1.x carries migration effort that a new build does not. The inventory sets the node count, the number of custom components to maintain and the operating effort needed to keep the platform running. Where an item is unknown, record it as a stated assumption with a named owner, so the reader can see which figures would move if that assumption changes.

Data volumes and retention targets drive most of the storage line. Ask for average and peak ingest rates per flow, typical event size, how long content must stay in the content repository, and how long provenance data must be kept for audit. Provenance retention in particular can drive disk growth quickly, and the repositories sit on each node, so the storage estimate depends on how many nodes you run. Target availability changes the shape of the bill just as much. Confirm whether the platform must survive a single node failure, whether planned maintenance may pause flows, and what recovery time and data loss the business accepts. Those answers determine whether you need a clustered deployment with a coordination layer, which adds nodes and operating work. Mark any target you cannot yet confirm as an assumption.

Constraints from your environment shape the unit costs. Name the identity provider you intend to use, since NiFi supports single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication, while the Kerberos provider is deprecated. State whether the platform will run in a public cloud, a data center or an air-gapped network, and list approved instance types, storage classes, egress rules and any hardening baseline. For cloud deployments, share existing pricing agreements such as committed spend or reserved capacity, because a negotiated rate can move the monthly comparison more than the choice of architecture. For any commercial NiFi-based product under consideration, provide the current license and support contracts, including renewal dates and notice periods. Apache NiFi itself carries no license fee under Apache-2.0, so the comparison rests on infrastructure, people and support terms.

Decisions need named people. Assign an owner for each flow group who can confirm its sources, expected rate of change and business impact, and a platform owner who approves cluster sizing, access policy and upgrade windows. Without these names, the model will carry assumptions that no one is accountable for, and cost estimates tend to drift once the platform is live. Agree on the decision criteria and a deadline before the review begins. Criteria might include the maximum acceptable cost difference over the planning period, required availability, data residency requirements and the team's capacity to operate NiFi. Put the decision date in writing, because a review without a deadline often ends in another round of data requests. List each gap in the inputs as an assumption with an owner and a due date, and show in the final model which assumptions change the result.

Common questions about NiFi cost of ownership and editions

Is there a paid edition of Apache NiFi?

No. Apache NiFi is an Apache Software Foundation project released under the Apache License 2.0 (Apache-2.0), and the project itself does not offer a paid edition. You can download, run and modify it without a license fee from the project. The cost of running it still exists, though. It sits in cluster infrastructure, storage for the repositories, the engineering time needed to build, secure and upgrade flows, and any support you choose to buy. If a vendor sells a NiFi-based product, the price pays for something beyond the Apache-2.0 code, so ask exactly what that something is before comparing totals.

How do commercial NiFi-based products differ from the open-source project?

Commercial NiFi-based products package the Apache-licensed code with their own additions, such as installers, management consoles, extra connectors, hosted operation or a support agreement. The terms vary widely, so confirm them in writing. Ask which components are proprietary and under what license, which NiFi version they track and how quickly they adopt new releases, whether they support NiFi 2 and migrations from 1.x, what support hours and response commitments they offer, who owns custom processors and flows, how you export your data and flows if you leave, what the pricing unit is (nodes, cores or data volume), and how renewal and price changes work.

What drives the total cost of running NiFi yourself?

Four components account for most of the cost. Infrastructure covers the cluster nodes, load balancing, backups and environments for development, test, production and disaster recovery. Storage covers the content, flowfile and provenance repositories, whose size depends on data volume and how long provenance is kept. People cover the platform engineering time to design, build, upgrade, secure and operate the cluster. Support covers vendor or partner help you buy. Costs rise with higher data volume, longer provenance retention, more flows and processors, custom processor development, identity and TLS integration, and frequent upgrades. One-time costs include design, build and migration. Recurring costs include infrastructure, storage, staffing, upgrades and support. Ask any quote to show each component separately.

How long does a NiFi cost of ownership review take?

The length depends on the written scope, so this page does not give a fixed duration. The inputs that set it include the number of environments, data volumes and retention settings, how many flows need an inventory, how complex your identity and hosting setup is, whether existing 1.x flows need migration analysis, and how many stakeholders must review the results. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. To compare options, ask each provider for a list of deliverables, the assumptions the model will use, and the points at which you review and approve the work.

Can our own team build a NiFi cost model without outside help?

Many teams can, because the software is free under Apache-2.0 and most inputs are measurable. A useful model needs node counts and sizing, repository disk performance, data volume and retention, staff hours per year, cloud or data center rates, and support decisions. The main risk is NiFi-specific detail that changes both hours and infrastructure, such as repository tuning, clustering behavior, the Java 21 runtime requirement, and the effects of a 2.x migration on flow configuration and removed variables. Build the model with written assumptions, then check the assumptions against a pilot flow. If you want an independent review or a fixed-scope build of the model, DeployOpen can do that as part of a written scope.

What does a NiFi cost review need from our team?

The review needs access to your flows and the people who know them. Provide the current NiFi version and Java runtime, an export or inventory of flows, the cluster topology, expected data volume and retention, provenance settings, the identity provider, and where the system will run (your cloud accounts, data centers or an air-gapped network). Also share current spending on infrastructure, staff hours spent on NiFi, and any licenses for commercial NiFi-based products. Name an owner for each system and set aside time for questions. Clear inputs shorten the work and make the resulting model easier to check against your budget.

Does running NiFi 1.x add cost that a 2.x plan would avoid?

Yes, the upstream project has ended support for the 1.x line. The NiFi downloads page lists December 8, 2024 as the end-of-support date for 1.28.1, and the project explains that 1.x cannot be maintained further because it depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, which cannot be upgraded in that line. A move to 2.x adds one-time cost. The migration guidance requires upgrading to NiFi 1.27.0 before moving to 2.0.0 and converting flow.xml.gz to flow.json.gz. It also removes the variable registry expression language scope in favor of an ENVIRONMENT scope and renames distributed map cache components. Include testing time in the model. Staying on 1.x leaves the platform without upstream fixes, so confirm with any commercial vendor how they support that line.

How DeployOpen scopes, delivers and hands over NiFi cost work

DeployOpen approaches Apache NiFi cost of ownership as a written, fixed-scope piece of work tied to your own infrastructure and cost model. We plan, build and document the NiFi side of the estimate so your team can check every assumption against its own environment.

How we scope

We agree in writing which NiFi version, cluster topology and environments the cost model covers before work starts.
We list the infrastructure, repository storage, people and support lines the written scope includes and excludes.
We confirm which NiFi 1.x or 2.x decisions, such as the planned migration path, change the ownership figures.

How we build

We build the cost model from your own cloud or data center prices, sizing inputs and staffing assumptions, not from generic figures.
We document each cost component with its owner, its one-time or recurring nature and the factors that drive it up or down.
We test the sizing assumptions against a representative NiFi setup in your environment where the scope calls for it.

How we hand over

We deliver the cost model as a spreadsheet and written notes so your finance and platform teams can change inputs themselves.
We walk your team through each assumption, the open questions and the items you need to confirm with vendors or your own providers.
We record the sources for every input and mark which numbers are estimates from your environment rather than vendor quotes.

How we support

Engagements are fixed-scope, so changes to the cost model are agreed in writing with their own scope and deliverables.
Ongoing support, upgrades and continuous testing are available as a retainer if you want the model kept current after go-live.
We can review the model again when NiFi releases or your hosting prices change, as agreed in the retainer scope.