Apache NiFi vs Airbyte: when each one fits your data movement
Choose Apache NiFi when your team must move, route and transform data continuously between systems and needs per-record visibility into where that data went. Choose Airbyte when the job is mostly scheduled loads from supported sources into a warehouse or lake using its connectors. The apache nifi vs airbyte decision turns on three things: the shape of your flows (continuous routing and transformation versus batch loads from connectors), the license terms for internal use, and who will operate the platform day to day. Teams that need both should expect to run two tools rather than force one to cover the other's job.
On flow shape, NiFi is a dataflow system with a browser UI for design, control and monitoring, and its data provenance records lineage from beginning to end, which matters when auditors or incident responders ask where a specific record came from and where it was delivered. Airbyte is built around ELT pipelines from APIs, databases and files into warehouses, lakes and AI applications. If your sources are well covered by Airbyte connectors and your work is loading and syncing on a schedule, its model fits more directly. Before committing, list every source and destination you need and confirm connector coverage and maintenance for each in Airbyte's own catalog, since coverage is the main reason ELT platforms are chosen or rejected.
On license and operations, the two projects differ in ways that change the decision. Apache NiFi is licensed under Apache-2.0 and the project offers no paid edition of its own. Airbyte Core is under the Elastic License 2.0, which permits commercial internal use, use for client work as a data agency and building applications on Airbyte data, but forbids hosting Airbyte as a managed service or exposing its UI or API to customers. Airbyte's connectors and Connector Development Kit are MIT. Airbyte is designed for Kubernetes and recommends deploying with Helm, so confirm whether your platform team can run that stack. NiFi clusters can use ZooKeeper or Kubernetes ConfigMaps and Leases, and NiFi 2 requires Java 21. Have your operators confirm these requirements before you pick.
Which platform fits which data movement scenario
This table maps common data movement scenarios to the platform that fits each one better, with the condition that decides it and the case where either tool is the wrong choice. Read each row as a routing question: pick the scenario closest to your work, then check the condition before shortlisting.
| Scenario | Better fit | Condition that decides it | Where the other platform is the wrong tool |
|---|---|---|---|
| Routing events between operational systems | Apache NiFi | Flows need content-based routing, protocol mediation or per-message handling across many systems, and operators must watch them in a live UI. | Airbyte moves batches from sources to destinations on sync schedules, so it does not route live operational messages between applications. |
| Loading SaaS and database sources into a warehouse | Airbyte | The work is many prebuilt source connectors feeding a warehouse or lake on a sync schedule, with incremental loads handled by the tool. Confirm the specific connectors you need in the current catalog. | NiFi can do this with processors, but each source is hand-built and maintained, which adds effort when connector count grows. |
| Transforming and filtering in flight | Apache NiFi | Records must be filtered, enriched, split or reshaped before they land, especially when the logic changes per message or per route. | Airbyte's model is extract and load with transformation usually run after landing, so in-flight logic belongs elsewhere. |
| Auditing where data came from | Apache NiFi | Your auditors or incident responders need record-level lineage from origin to destination. NiFi's data provenance records this from beginning to end. | Airbyte tracks sync status and logs, but confirm whether its run history meets your lineage requirement at record level before relying on it. |
| Embedding data movement in a client-facing product | Depends on the license reading | Under ELv2, you may build applications powered by Airbyte data, but you may not host and sell Airbyte as an ELT tool or expose its UI or API to customers. Get written legal review of your product model. | NiFi is Apache-2.0 with no paid edition from the project, so the license is simpler, but you still must design the tenant isolation and the UI exposure yourself. |
| Running a small team with many standard connectors | Airbyte | Your team wants to add sources by configuration rather than by building and testing flows, and accepts the Helm-based Kubernetes deployment. | Teams without Kubernetes skills may find Airbyte's deployment burden high, and NiFi clustering on Kubernetes also needs planning. |
| Running a visual, always-on flow platform for many teams | Apache NiFi | Several teams build and monitor their own flows in one UI, and continuous streaming matters more than scheduled batch loads. | Airbyte's connector-first model gives less control over the flow graph itself, so it suits fewer custom routing designs. |
| Building a platform with no license review | Apache NiFi | Your legal team needs an unambiguous open-source license for internal and redistributed use, and wants no commercial edition gating features. | Airbyte Core is under ELv2, so confirm your use against the license FAQ and the LICENSE file before committing. |
How NiFi and Airbyte are built and deployed
NiFi and Airbyte solve different problems with different runtimes, so their operating models differ from the start. Each card below names one architectural decision and the work it creates for the team that runs it.
NiFi as a clustered Java service
NiFi runs as a Java service that you operate as a cluster, with a browser UI for designing, controlling and monitoring flows. Every node runs the same flows, so the cluster must be sized, patched and monitored as one system. NiFi 2.x requires Java 21 at minimum, and Python-based processors are an optional beta feature that needs Python 3.10, 3.11 or 3.12. Check that your build pipeline and base images meet those versions before you commit to the platform.
Zero-leader clustering with ZooKeeper
NiFi uses zero-leader clustering, where nodes coordinate through ZooKeeper, either embedded or external. Your team owns the ZooKeeper ensemble as well as the NiFi nodes, so its availability, quorum and upgrades become part of your runbook. Confirm who will operate that ensemble and how it is backed up before you size the cluster.
Kubernetes coordination with ConfigMaps or Leases
On Kubernetes, NiFi can coordinate cluster state and leader election through ConfigMaps or Leases instead of ZooKeeper. This removes one stateful component from the design, but it ties cluster behavior to the Kubernetes API and its RBAC. Ask your platform team which option they will support, and test node loss and rolling restarts in a non-production cluster before you rely on either mechanism.
Airbyte built for Kubernetes and Helm
Airbyte is designed to be deployed into a Kubernetes cluster, and its documentation highly recommends installing with Helm using the documented chart values. Configuration lives in chart values, so your team needs Helm and Kubernetes skills and a process for managing values files across environments. Plan for the chart upgrade path as part of routine platform maintenance.
Single-machine setups with abctl and Docker
For evaluation, development or a single host, Airbyte documents abctl and Docker as deployment paths. These paths suit a proof of concept, but they are not the production model the platform is built around. If a pilot runs on one machine, confirm the migration route to a Kubernetes install before you connect production sources and destinations.
Operational consequence for each team
A NiFi deployment asks your team to run a stateful, always-on dataflow cluster, including its coordination layer and repositories. An Airbyte deployment asks your team to run a Kubernetes application stack and its sync jobs. Staff the operating model you choose, not the tool name, and get the sizing, backup and upgrade ownership written down before procurement closes.
Capability comparison: NiFi and Airbyte
This table compares Apache NiFi and Airbyte on the capabilities that usually decide the shortlist: license, core model, visual building, provenance, clustering, Kubernetes deployment, connectors and identity. Read each row against your own movement pattern, and treat any row marked to confirm as an open question for the vendor before you commit.
| Capability | Apache NiFi | Airbyte |
|---|---|---|
| License | Apache-2.0 for the whole project, with no paid edition from the project itself | Core platform under Elastic License 2.0, connectors and Connector Development Kit under MIT |
| Core model | Continuous dataflow with processors that route, transform and move records between systems | Connector-based ELT that extracts from sources and loads into destinations on sync schedules |
| UI for building pipelines | Browser-based UI for designing, controlling and monitoring flows | Web UI for configuring source and destination connections and sync jobs |
| Data provenance | Records lineage from beginning to end for each piece of data moved through a flow | To confirm: the depth of per-record lineage and audit trails in the self-managed edition |
| Clustering and high availability | Zero-leader clustering coordinated through ZooKeeper, embedded or external, or on Kubernetes using ConfigMaps or Leases | To confirm: the high availability model for self-managed Core on Kubernetes in the deployment documentation |
| Kubernetes deployment | Clusters can run on Kubernetes using ConfigMaps or Leases for state and leader election | Built to deploy into a Kubernetes cluster, with Helm and documented chart values highly recommended |
| Connector ecosystem | Large set of built-in processors for routing, transforming and moving data across protocols and formats | Connectors for APIs, databases and files into warehouses, lakes and AI applications; confirm the current catalog and connector support levels |
| Identity options | Single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate; Kerberos provider is deprecated | To confirm: supported SSO and identity options for self-managed Core in Airbyte's docs |
| Minimum runtime | Java 21 minimum; Python 3.10, 3.11 or 3.12 for optional Python processors (beta) | To confirm: runtime and container prerequisites in the current Airbyte deployment guide |
What the license allows for internal use
Apache NiFi is an Apache Software Foundation project released under the Apache License 2.0 (SPDX identifier Apache-2.0). The license is permissive, and the project itself offers no paid edition, so the software you download from the project carries no commercial license key or feature gating. Your obligations are the ones the Apache License sets out, such as keeping license notices and attribution in redistributed copies. Internal use, hosting for your own customers, and building services around NiFi are not restricted by the project's license terms. Check the NiFi downloads page for the current release and license statement before you standardize on a version.
- No paid edition from the project: the Apache project does not sell a separate enterprise tier of NiFi, so there is no feature license to purchase from the project itself.
- Internal operations: running NiFi for your own data movement is covered by the Apache-2.0 terms without a usage limit set by the license.
- Redistribution: if you package NiFi into an internal image or product, keep the license and notice files that come with the distribution.
- Third-party vendors: any commercial support, managed service or add-on comes from a separate company under its own contract, so review that contract separately.
- Version and support: the license does not set support windows, so confirm which NiFi line you will run against the project's support statements.
Ask your counsel to confirm how any bundled third-party components or vendor add-ons you introduce are licensed.
Airbyte's platform is licensed under the Elastic License 2.0 (ELv2) and has been under that license since version 0.30.0, released on September 27, 2021. Airbyte's connectors and Connector Development Kit are under the MIT license, which is far more permissive. Under ELv2, your organization may use Airbyte commercially for internal operations, build applications powered by the data Airbyte moves, and use it for client work as a data agency. The restrictions are narrower: you may not host and sell Airbyte as an ELT tool, and you may not directly expose its UI or API to customers. The Airbyte license FAQ explains these boundaries in more detail.
- Internal operations permitted: your own teams can run self-managed Airbyte to move data into warehouses, lakes and applications.
- Hosting and resale limit: offering Airbyte as a hosted or managed ELT service to third parties falls outside ELv2.
- UI and API exposure: giving customers direct access to the Airbyte UI or API is restricted, even when you do not charge for it.
- MIT connectors: connectors and the CDK are MIT-licensed, and Airbyte says contributors who develop their own connectors can choose the license they prefer.
- Editions: Airbyte documentation references Core and Enterprise Flex editions, and the deployment guide covers the open Core version for self-managed installations. Confirm which edition's terms and features apply to your deployment.
Have counsel confirm whether your client engagement model falls under the data agency allowance or the restricted hosting and exposure categories.
Client work is where license terms most often stop being obvious. A team that builds pipelines for an outside customer, operates the stack on the customer's behalf, or gives that customer a login to a data tool sits in a different position from a team that only moves its own data. Before you deliver either NiFi or Airbyte in a client engagement, map how the customer will touch the platform, who operates it, and who holds the credentials. The answers determine whether the work stays inside internal operations, client work or a restricted category. This is a licensing question for counsel, not a technical one, and DeployOpen does not provide legal advice.
- Operator identity: determine whether your staff or the client's staff run the platform, since this changes how the use is characterized.
- Customer access: confirm whether the client receives direct UI or API access to Airbyte, which ELv2 restricts.
- Service model: distinguish building data products for a client from offering the ELT tool itself as a service.
- Hosting location: note whether the platform runs in the client's infrastructure, your infrastructure or a shared environment, and record that decision.
- Written terms: put the permitted use, edition and support scope into the statement of work so the boundaries are documented.
Before signing, ask counsel to review the Airbyte license FAQ against your exact service description, and confirm the NiFi license statement covers any bundled components you ship.
Where the Airbyte license changes the build decision
The Airbyte license decides the build question before connector features do. Airbyte Core, the platform, is under the Elastic License 2.0 (ELv2), while its connectors and Connector Development Kit are MIT. Under ELv2, your organization may use Airbyte commercially for internal operations, so a data platform team that runs Airbyte to load its own warehouse is inside the terms. The same applies to building applications powered by Airbyte data, and to client work as a data agency. The line is crossed in two cases: hosting and selling Airbyte as an ELT tool, or directly exposing its UI or API to customers. Confirm with Airbyte's license FAQ which side of that line your plan falls on.
If your product exposes data movement to its own customers, such as letting users connect their sources and sync them through your service, treat the ELv2 terms as a legal review item before you choose Airbyte. Ask your legal counsel to read the license alongside the Airbyte LICENSE file and the license FAQ, and to test your specific deployment model, customer-facing surfaces and any license key handling against them. Do not rely on the connector license to cover the platform. The MIT terms on connectors do not change the ELv2 status of Airbyte Core.
Apache NiFi is licensed under Apache-2.0, and the supplied facts for this comparison do not include any restriction on hosting it for customers or exposing its functions through your own product. That is a narrower statement than legal advice. Ask counsel to confirm the Apache-2.0 obligations that apply to your distribution, including notices and any bundled third-party components. If your product model requires customer-facing movement without the ELv2 limits, NiFi's license removes that question, though you still need to plan NiFi's own operating effort inside your environment.
Moving pipelines between NiFi and Airbyte
This sequence turns an existing set of Airbyte syncs or NiFi flows into a tested replacement, with each source, destination and transformation accounted for before anything is switched off. The output is a documented cutover that both teams have reconciled against the same data.
Inventory sources, destinations and schedules
The data owner and the platform engineer list every Airbyte connection or NiFi flow in scope, along with its source system, destination, sync mode, schedule and the team that depends on the output. Include credentials owners and any downstream consumers that read from the destination. The step is done when the inventory is signed off by both the data owner and the people who run the pipelines, and every entry has a named owner and a target destination.
Map connectors to processors or the reverse
The integration engineer maps each Airbyte connector to a NiFi processor that performs the same read or write, or maps each NiFi processor to an Airbyte connector where one exists. Gaps are recorded as custom work, either a scripted processor in NiFi or a custom connector built with the Connector Development Kit, which is MIT licensed. The check is a mapping table where every source and destination has a matching component or an approved custom build, with a note on each gap.
Rebuild transformations and error handling
Airbyte transformations, typically run after loading, are rebuilt as NiFi processors or downstream jobs, and NiFi relationships for success, failure and retry are defined for each path. The engineer writes the routing so that malformed records go to a named failure path rather than being dropped silently. The step is complete when every transformation has a test input and expected output, and each failure path has an owner and a documented retry or quarantine action.
Export NiFi flow definitions to version control
In NiFi 2.x the flow configuration is stored as flow.json.gz, so the engineer confirms the file location on each node, stores the flow definition in version control, and records the NiFi version used. Flow Registry clients such as the GitHub or GitLab options can hold versioned flows, which lets the team review changes before they reach production. The check is a tagged, reviewable flow definition that can be restored to a test cluster without manual edits.
Run both pipelines in parallel with reconciliation
The old Airbyte syncs and the new NiFi flows run against the same sources for an agreed period while writing to separate destination tables or paths. A reconciliation job compares row counts, key coverage, checksums on sampled records and schema changes, and each mismatch is logged with a cause. The step is done when the agreed comparison checks pass across the observation window and every difference has a documented explanation.
Migrate state, credentials and scheduling deliberately
Airbyte sync state, such as incremental cursors and bookmarks, does not transfer automatically to NiFi, so the team sets the new flows' starting points from the last reconciled record and checks for duplicates or gaps. Credentials are recreated in the secrets store of the target platform, never copied from configuration files, and schedules are reset in NiFi's timers or an external scheduler. The check is a written record of each starting point, each credential owner and each schedule before the old jobs are paused.
Cut over and retire the old pipelines
After reconciliation passes, the team points consumers at the NiFi outputs, pauses the Airbyte connections rather than deleting them at once, and keeps them available for a documented rollback period. The security owner confirms that access to the NiFi UI and API is restricted, and the platform team updates the runbook and monitoring. The step closes when consumers have confirmed reads from the new destination, the rollback steps have been tested, and the old connections are retired under change control.
What drives running cost on each platform
Running cost for NiFi and Airbyte comes from different places: a clustered Java service you operate yourself versus a Kubernetes application built around connector containers. The cards below cover the components that recur over the life of each platform, and what to put in a written quote so the comparison rests on your scope rather than on assumptions.
Clustered NiFi infrastructure
A production NiFi cluster needs enough nodes, storage for content and provenance repositories, and a coordination layer. NiFi's administration guide describes ZooKeeper coordination, embedded or external, or Kubernetes-native state using ConfigMaps or Leases. Ask the vendor or partner to size provenance retention, repository disks and node count against your event volume, and state which coordination option the quote assumes. Provenance storage grows with throughput, so it is usually the largest recurring infrastructure line.
Kubernetes hosting for Airbyte
Airbyte is built to be deployed into a Kubernetes cluster, and its documentation highly recommends Helm with the documented chart values. Recurring costs include the cluster itself, database and object storage for sync state and logs, and the compute that runs connector sync jobs. Confirm which of these your platform team already runs, and ask for the chart version, node pools and storage classes the quote assumes.
Flow authoring skills versus connector setup
NiFi flows are built by designing processor graphs in the browser, which means staff need to understand routing, back pressure, record handling and, for some work, Python processors that the administration guide describes as beta. Airbyte work is mostly configuring existing connectors, with custom work done in code when a source is missing. Ask who maintains flows after handover and whether the quote includes knowledge transfer for each platform.
NiFi 1.x end of support and the 2.x move
NiFi 1.x can no longer be maintained because it depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, and the project's downloads page strongly encourages users to move to NiFi 2. The migration guidance requires upgrading to NiFi 1.27.0 before moving to 2.0.0 and changing the flow file from flow.xml.gz to flow.json.gz. If you run 1.x today, include this migration path, the variable registry changes and renamed cache components in the scope. Treat these as recurring risk items until the migration is complete.
Airbyte major version upgrades
Airbyte is an open-source platform with an Elastic License 2.0 core, and major releases change the platform and connector behavior. Airbyte v2.0.0 was published on October 15, 2025, so any installation that predates it should have its upgrade path, connector version pinning and rollback plan written down. Ask for testing of representative syncs after each upgrade, and confirm whether the quote covers chart upgrades separately from connector updates.
Vendor support versus DeployOpen retainers
Neither project sells a standard support contract for the open-source self-hosted edition, so support cost depends on who you engage. Airbyte offers Cloud and Enterprise options, and NiFi has no paid edition from the project itself. DeployOpen provides ongoing support, upgrades and testing as retainers, and most engagements are fixed-scope with written deliverables. Ask each provider for response expectations in writing, what an upgrade includes, and which items recur each year.
Where NiFi and Airbyte implementations usually run long
The longest delays in a NiFi project usually come from design decisions made late, not from installation. Teams often start by dragging processors onto a canvas and only later ask how many flowfile events they must keep, how long provenance data should be retained, and where its repositories will sit on disk. Sizing provenance retention, repository storage and back-pressure thresholds takes measurement against real payload sizes, so it cannot be fully estimated on a whiteboard. Clustering and TLS setup add their own work: the team must choose between embedded and external ZooKeeper or Kubernetes-based state and leader election, issue certificates for node-to-node and UI traffic, and confirm that the flow configuration format matches the NiFi release in use. Identity integration is often the last step and the slowest, because the choice among single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 authentication must be mapped to group membership and access policies that the security team has already approved.
Airbyte projects tend to slip for a different reason: connector coverage. A source or destination that is not in the catalog, or a version that does not behave as the API documentation describes, means writing and testing a custom connector with the Connector Development Kit, which is MIT-licensed, and then maintaining it after every upstream API change. Ask the vendor or your own team to list every source system and target in writing, and check each against the connector catalog before committing to a timeline. On Kubernetes, the deployment is normally driven by the Helm chart and its documented values, so resource limits, persistent storage, ingress, secrets and sync worker sizing all require tuning in your cluster. Durations for any of this depend on how many flows, connectors and environments are in scope, so agree a fixed-scope plan in writing that lists each connector, cluster, identity source and test cycle before work starts.
Questions buyers ask before choosing NiFi or Airbyte
Is Airbyte open source?
Partly. Airbyte's platform, Airbyte Core, has been under the Elastic License 2.0 since September 27, 2021 (version 0.30.0), while Airbyte's connectors and Connector Development Kit are under the MIT license. Read the platform and the connectors as two different licenses. Apache NiFi, by contrast, is Apache-2.0 licensed as a whole, and the project offers no paid edition of its own. Confirm which components your deployment actually pulls before you describe the stack as open source in a procurement file.
Does internal use of Airbyte need a license review?
Usually yes, at least a documented one. The Airbyte license FAQ says organizations may use Airbyte commercially for internal operations, build applications powered by Airbyte data, and use it for client work as a data agency. It does not allow you to host and sell Airbyte as an ELT tool or to expose its UI or API to your customers. If your data platform will serve external users, have counsel read the FAQ against your exact service model. Your review should also cover any connectors you write yourself, since Airbyte says contributors may choose their own license.
Can NiFi replace Airbyte for every data movement job?
Not always. NiFi is a flow-based dataflow system that routes, transforms and tracks data with a visual UI and data provenance, which suits continuous movement, filtering and routing between systems. Airbyte is built around connectors for pulling data from APIs, databases and files into warehouses, lakes and AI applications. Where your sources are many SaaS APIs with ready-made connectors, Airbyte usually needs less custom build. Where you need fine-grained routing, lineage for every record, or streaming transformations, NiFi fits better. Many teams run both. Confirm connector coverage for each of your sources before you decide.
What does the implementation need from our team?
The work divides into platform operations, connector or flow ownership, and data governance. For NiFi, expect people who can design flows, manage the cluster and handle the Java 21 runtime and any Python processors you enable, which the administration guide describes as beta. For Airbyte, expect Kubernetes skills, because the project is built for deployment into a cluster and recommends Helm with its documented chart values, plus owners for each source connection. Ask whoever you hire to document ownership of credentials, upgrades and failure handling before go-live.
Can our team run either platform without outside help?
It depends on your Kubernetes and Java or Python skills, and on how many sources and flows you run. A team that already operates Kubernetes and Helm can usually stand up Airbyte with the documented chart. A team that knows Java operations can run NiFi, but clustering, upgrades and security setup need careful planning. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers.
How long does a migration between these tools take?
No supplied figure covers this, so treat any timeline as unknown until your own scope is written. The main drivers are the number of sources and destinations, whether flows need rewriting or only re-pointing, how much transformation logic sits in each job, and how much history you must keep. NiFi itself has a version-upgrade path that matters if you run a 1.x line, since the project says 1.x cannot be maintained further and recommends moving to NiFi 2. Ask any implementation partner to inventory your jobs first and to state the migration plan, testing and rollback in writing.
What should we ask for in a quote?
Ask for a written scope that lists each source, destination and transformation, the number of flows or connections, and the environments covered. Request the deployment target, whether that is Kubernetes or another self-managed layout, and who owns licensing review, security configuration and backups. Ask which items are one-time work, such as build and hardening, and which recur, such as upgrades and support. Confirm the acceptance criteria and the handover documentation. Quotes follow from the written scope, and DeployOpen does not publish a price list.
How DeployOpen helps choose, implement or migrate NiFi or Airbyte
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For NiFi or Airbyte, we start by mapping which data movement jobs each tool would own, then build and hand over only what your written scope covers.
How we scope
- Map source systems, destinations and the flow types each one needs, such as routing, transformation or connector-based loading.
- Confirm the license position for internal use, client work or any hosted offering with your legal team before design begins.
- Agree deliverables, timelines and responsibilities in writing, since most engagements are fixed-scope.
How we build
- Deploy the chosen platform into your infrastructure, including Kubernetes or ZooKeeper-based clustering where your topology requires it.
- Configure authentication, network exposure and secrets handling to match your existing identity and security controls.
- Test flows or connectors against representative data, including failure, restart and backfill scenarios agreed in scope.
How we hand over
- Document architecture, configuration, runbooks and upgrade steps so your own team can operate the platform.
- Provide evidence of configuration and controls that your internal or external auditors can review for compliance readiness.
- Walk your operators through monitoring, backup and recovery procedures before the engagement closes.
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover, scoped separately from the original build.
- Plan version upgrades around the vendor's support windows and migration guidance, confirmed against current releases.
- Revisit the scope when source systems, volumes or license terms change, with any changes agreed in writing.
