Which license fits a self-hosted SIEM backend: OpenSearch's Apache-2.0 or Elastic's three options?
If your team is choosing a search backend for logs and SIEM and legal or procurement is reviewing the license, the short answer is this: OpenSearch is licensed under Apache-2.0, and its FAQ does not describe any paid edition of the software. Elasticsearch source code is offered under three licenses: the Elastic License 2.0 (the default distribution), SSPL 1.0 and AGPLv3, with AGPLv3 added in September 2024 before the 8.16 release. Only the AGPLv3 option is OSI-approved. ELv2 and SSPL are not, so a team that requires OSI-approved terms should look at OpenSearch or the Elastic AGPLv3 option, not the default distribution.
The right answer depends on three questions you should settle before the review. First, do you plan to offer the search backend to third parties as a managed service? Elastic's ELv2 restricts that, and the license terms for each option should be read by counsel against your actual use. Second, do you need OSI-approved terms in policy, or is a source-available license acceptable? Third, which security controls must you have? Elastic's self-managed subscription page places SAML or OpenID Connect single sign-on and endpoint features under paid tiers, and states that the Platinum tier is no longer sold to new customers. Ask Elastic in writing which tier includes each control you need, and confirm the current terms for the AGPLv3 distribution with the vendor.
For a SIEM backend, the license question is only part of the cost. OpenSearch Security provides SAML, OpenID Connect, LDAP and Kerberos authentication, role-based access control, and document- and field-level security in the open-source distribution, which you should verify against your own requirements in a proof of concept. Also confirm which release line you will run and its maintenance window, since OpenSearch versions receive security patches but no new features during maintenance. Your cost then comes from the people who install, patch and monitor the cluster, not from a license fee, so ask any implementation partner for a written scope that covers those tasks.
How the two licenses compare term by term
This table sets OpenSearch's Apache-2.0 terms against Elastic's three licenses for Elasticsearch and Kibana, row by row. Read each row as a question to put to your legal team and your vendor, since the managed service wording in particular needs confirmation against the license text.
| Term | OpenSearch | Elasticsearch and Kibana (Elastic) |
|---|---|---|
| License | Apache License 2.0 for all software in the OpenSearch project | Elastic License 2.0 (default distribution), SSPL 1.0 and AGPLv3, the last added in 2024 before the 8.16 release |
| OSI status | Apache-2.0 is an OSI-approved open source license | ELv2 and SSPL are not OSI-approved; AGPLv3 is the OSI-approved option |
| Default distribution | Apache-2.0 for the whole project, with no separate paid edition described in the FAQ | ELv2 since 2021, per Elastic's licensing FAQ, with the other two licenses offered as alternatives |
| Paid editions | None described in the OpenSearch FAQ; paid features are not part of the license model | Self-managed Platinum (no longer sold to new customers) and Enterprise subscriptions, per Elastic's subscriptions page |
| Managed service terms | Apache-2.0 places no field-of-use limit in the license itself; confirm vendor-specific terms with counsel | ELv2 restricts providing the software as a managed service to third parties; confirm the exact scope with counsel |
| Source of derivation | Forked from Elasticsearch 7.10.2; OpenSearch Dashboards derived from Kibana 7.10.2 | Elasticsearch and Kibana source continues in Elastic's own line under the three licenses above |
| Current release lines | OpenSearch 3.9.0, released September 29, 2026 | Elastic 9.5.5 and 9.4.8, released October 6, 2026, with 8.19.23 still maintained |
What Apache-2.0 allows that ELv2 and SSPL do not
OpenSearch is released under the Apache License, Version 2.0, and every component in the OpenSearch project carries that license. The OpenSearch FAQ describes no paid edition of the engine, so an internal team can run, modify and redistribute it under one set of terms. Elasticsearch and Kibana are different. Elastic states that its source code is available under three licenses: the Elastic License 2.0 (ELv2), which is the default distribution, SSPL 1.0, and AGPLv3, which Elastic added in September 2024 before the 8.16 release. Elastic also states that ELv2 and SSPL are not OSI-approved open source licenses, and that it added AGPLv3 to offer an OSI-approved option. For a platform team, the practical distinction is that Apache-2.0 is the only one of these choices that is both OSI-approved and free of the managed-service restrictions attached to ELv2 and SSPL. Confirm with your legal team which of the three Elastic licenses applies to the exact artifacts you plan to deploy, because the choice is made per distribution, not per product name.
A vendor that embeds either search engine in a product must read the applicable terms before shipping, and the restrictions that matter most concern offering the software as a hosted service. Security teams sometimes assume that a self-hosted deployment inside their own network raises no license question at all, but a product that bundles Elasticsearch and sells access to its functions to customers is a different case from an internal logging cluster. The supplied Security Onion license documentation notes that ELv2 forbids offering the software as a managed service, which is the same restriction a vendor would meet when hosting Elastic components for others. An internal platform that serves only the owning organization is in a different position from a managed service provider or an ISV. Before committing to a design, ask counsel to review the license text for each component, including OpenSearch Dashboards, which derives from Kibana 7.10.2, and to document which terms govern each artifact in the build.
Factors that change which license matters
The license question rarely has one answer. Which terms bite depends on how you deliver the stack, what your procurement rules accept, which paid features you need and where your SIEM sits. Work through these six factors before you treat the license choice as settled.
Reselling or hosting for customers
If you run OpenSearch or Elasticsearch as a service for other organizations, the license terms on managed service offerings matter more than the license terms on internal use. Elastic's ELv2 forbids offering the software as a managed service, and the same restriction shapes what a provider can sell. Apache-2.0 places no comparable limit on OpenSearch. Ask counsel to read the managed service language in each license against your actual offering, not a summary.
Procurement requiring OSI approval
Some procurement policies accept only OSI-approved licenses. Elastic states that ELv2 and SSPL are not OSI-approved, and that AGPLv3 was added to give an OSI-approved option. OpenSearch under Apache-2.0 meets that test directly. If your policy names approved licenses, confirm which Elastic license your deployment would use, since the default distribution is ELv2.
Paid security features such as SSO
Elastic reserves several security features for paid tiers, including single sign-on through SAML or OpenID Connect and anomaly detection alerting. OpenSearch Security includes SAML, OpenID Connect and LDAP authentication, along with document-level and field-level security and audit logs. Inventory the controls your SIEM needs, then check each against the current Elastic subscription page before you assume the free tier covers it.
Dependence on Elastic release lines
Elastic's support windows differ by release line. The 8.19.23 line is still maintained, while the 9.x line lists end of maintenance on October 15, 2027. Teams standing on 8.x should plan a path before its end of maintenance on January 15, 2027. OpenSearch releases follow a minor version about every eight weeks, with the 2.19 line still receiving maintenance. Map your upgrade calendar against both vendors' published dates.
SIEM built on Graylog or Wazuh
If your SIEM is Graylog, its open edition is licensed under SSPL-1.0, and its search backend is self-managed OpenSearch or Graylog Data Node. If your SIEM is Wazuh, its indexer is an open source fork of OpenSearch, and the indexer and dashboard are Apache-2.0. In both cases your OpenSearch exposure runs through another product's license terms. Confirm which backend and license apply to the exact components you will deploy.
Internal teams extending the code
Platform teams that plan to patch, fork or embed the search engine inherit the license obligations that come with modifying it. Apache-2.0 allows modification and redistribution with notice requirements, and the OpenSearch Software Foundation is not involved in technical oversight of the project. Elasticsearch under AGPLv3 would require source disclosure for network-facing modifications. Have legal review what your team plans to change before you pick the base.
Which license position suits each buyer
A platform team that runs search and logging for its own employees is usually the party with the simplest license position, because it operates the software inside its own organization. The Apache-2.0 terms of OpenSearch impose few conditions on internal use, while Elastic's default distribution is licensed under the Elastic License 2.0, which is not OSI approved. The practical question is whether the team will ever add features that depend on a paid tier, since those features change the cost model even when the license terms do not change.
- Internal use is the usual case: Elastic's licensing FAQ describes ELv2 as the default distribution, so an internal deployment needs no managed-service analysis unless the team also hosts it for others.
- Paid features shape cost: Security features such as SAML single sign-on and field-level security sit in Elastic's paid tiers, while the OpenSearch Security plugin documents these controls as part of the distribution.
- Upgrade paths differ: OpenSearch maintains each minor line for a stated window, so the team should compare its own upgrade cadence with the support windows in each project's documentation.
- Forks and patches: If the team modifies source code, confirm what each license requires when the modified software is shared outside the company.
- Tooling around the cluster: Check whether operators, dashboards or agents you plan to add carry their own license terms.
Ask counsel whether any planned modification or internal-only use triggers a source disclosure obligation under the chosen license, and confirm the answer against the exact license file for the version you deploy.
A software vendor that embeds search inside its own product is the party most exposed to license wording, because distributing or hosting the engine for customers changes the obligations. Elastic's licensing FAQ states that ELv2 and SSPL are not OSI approved, and the Elastic License 2.0 is widely read as restricting offering the software as a managed service. OpenSearch is Apache-2.0, which permits redistribution and commercial embedding under the terms of that license. The vendor should not rely on a summary: the exact terms of each license decide what can be sold.
- Managed service restrictions: Confirm with counsel whether offering a hosted search function to customers falls under any restriction in ELv2 or SSPL that applies to the version you ship.
- Redistribution terms: Apache-2.0 requires license and notice retention when you redistribute, so the product's third-party notices need to list the engine and its dependencies.
- Dashboards: OpenSearch Dashboards derives from Kibana 7.10.2, so check the license of the dashboard component separately from the engine.
- Version pinning: Record which exact version you ship, since license and support terms are tied to versions.
- Customer contracts: Your customer terms may need to disclose the open-source components and their license obligations.
Ask counsel for a written opinion on the managed service and redistribution questions for the specific Elastic version and OpenSearch version your product will bundle.
Many regulated enterprises set an internal rule that approved open-source software must carry an OSI-approved license. For this group, the license question is less about what the engine permits and more about whether it passes the policy gate at all. Elastic's licensing FAQ says ELv2 and SSPL are not OSI-approved, and that AGPLv3 was added to offer an OSI-approved option. OpenSearch is under Apache-2.0 for all project software. Policy owners should check whether the approved list is applied to the exact license of each component, including the dashboard.
- Policy wording: Read the internal standard for how it defines open source and whether it names specific licenses or only the OSI list.
- Component-level review: Check the engine and the dashboard separately, since their licenses may differ on each platform.
- Procurement evidence: Keep the license file and the version identifier in the approval record so an assessor can trace the decision.
- Paid tiers: If the policy approves the core license but the security controls you need sit in a paid tier, record that dependency in the approval.
- Exceptions process: Document any exception request with a named owner and a review date.
Ask counsel and the internal policy owner whether an AGPLv3 Elastic distribution would satisfy the policy, and whether any non-OSI component in the chosen stack needs a formal exception.
A team already running Elastic Security has detection content, agents and dashboards built on the Elastic stack, so the license question is about whether to stay, move or run both. Elastic says its default distribution has been under ELv2 since 2021 and that AGPLv3 is also available. The team does not need to change license to keep operating, but it should confirm which license applies to the version it runs now and which one it will run after each planned upgrade. Switching engines carries a migration cost that is separate from the license comparison.
- Current license position: Identify the license under which your current Elasticsearch and Kibana packages are distributed, since the choice may be made at download time.
- Subscription tier: Confirm which features in your current tier are paid, such as detection, machine learning and endpoint prevention, and whether they are available in your tier at renewal.
- Upgrade windows: Compare your version's maintenance end date with your upgrade plan, because support ends on a fixed schedule for each line.
- Mixed estates: If you plan to run OpenSearch alongside Elastic, check which components you will license under each arrangement.
- Migration scope: Detection rules, dashboards and agent policies are the parts that change when you move engines, so count them separately from the engine itself.
Ask counsel whether a move to OpenSearch changes any existing Elastic subscription obligations, and ask your Elastic representative to confirm your current tier entitlements in writing.
What this means for vendors and internal platforms
The license on a SIEM or log product and the license on the search engine underneath it are separate questions, and this section matters most when a team is choosing a product partly for its backend. Graylog Open is licensed under the SSPL-1.0 and is not OSI approved, even though its documented search backend can be self-managed OpenSearch, which is Apache-2.0. Security Onion moved to the Elastic License 2.0 starting with version 2.4, and it bundles Elasticsearch and Elastic Agent, so its position follows the Elastic license rather than the OpenSearch one. Wazuh is a different case again: the server and agent are GPL-2.0 with an OpenSSL linking exception, while the Wazuh indexer, which is an open source fork of OpenSearch, is Apache-2.0. A platform team should map each layer (application, agent, indexer, dashboard) to its own license before writing a policy that assumes one license covers the stack.
The OpenSearch Software Foundation is a Linux Foundation project with a board that includes AWS, IBM, SAP and Uber, but it is not involved in the technical oversight of the OpenSearch project. For a vendor or internal platform team, that means the Apache-2.0 grant is the contractual anchor, while release direction is set by the project's maintainers rather than by the foundation's board. Confirm the license for each component in its own repository, such as the LICENSE file in the OpenSearch, Graylog, Wazuh and Security Onion repositories, and record the version you deploy. Licenses change over time: Elastic added AGPLv3 in 2024, and Graylog changed its license in 2020, so a license review should be scheduled as part of each upgrade cycle, not done once at selection.
If your organization will ship or host a SIEM for others, or offer a managed service, check the managed service terms of each license in writing with legal counsel before the design is fixed. The Elastic License 2.0 forbids offering the software as a managed service, and the SSPL carries its own conditions for service providers, so a product that looks free to run internally may not be free to resell. Ask the vendor or your counsel to confirm whether a given product and backend combination permits your intended use. Keep the license inventory alongside your architecture diagrams so that a later change of backend, such as moving from Elasticsearch to OpenSearch, is reviewed against the license of every component it touches.
How to confirm the license position in your environment
This sequence turns the license question into a dated, written position your team, counsel and procurement can all check against the same evidence. It covers which components you run, what each license says, which features you depend on, and how users reach the service.
Inventory every component and its version
List each OpenSearch and Elasticsearch component in scope, including the search engine, the dashboards layer, any Elastic Agent or Beats collectors, and any security or alerting plugins, with the exact version each one runs or is planned to run. Name the owner of each entry and record which environment it sits in, such as production, disaster recovery or a lab. The step is done when the inventory is a single document that a reviewer can match against the running clusters.
Pull the license files from each repository
For each component, open the license file in the source repository for the exact version you chose, then save a copy with the commit or release tag. For OpenSearch, that is the LICENSE.txt in the opensearch-project repository under Apache-2.0. For Elasticsearch and Kibana, check which of the three offered licenses applies to your distribution, since the default distribution is under the Elastic License 2.0 and AGPLv3 is a separate option. The step closes when every component has a dated license copy on file.
List the features in use and check their tier
Export the list of features your deployment actually uses, such as single sign-on, alerting based on anomaly detection, machine learning, case management, field or document-level security, or endpoint prevention. Check each one against the current subscription page for the Elastic stack and against the feature documentation for OpenSearch plugins. Mark any feature that sits in a paid tier and record whether you already hold that subscription. The output is a feature-to-tier table that shows where the Elastic path would require a paid subscription and where OpenSearch covers the same need under its own license.
Document how the service reaches users
Write down who uses the cluster and how access is granted: internal staff only, business units, customers through an application, or a hosted service run by your team or a third party for others. Note whether any party outside your organization operates the software, receives its interface, or pays for access to it. This record is the input counsel needs, because the Elastic License 2.0 restricts offering the software as a managed service, while Apache-2.0 places no comparable restriction on OpenSearch. The step closes with a signed-off description of each service model.
Check support windows for the chosen versions
Confirm the release line you intend to run is still in maintenance at the date you plan to go live. For OpenSearch, review the maintenance and end-of-life rules on the releases page, which say versions stay under maintenance until the next major version enters maintenance or one year passes, whichever is longer, and that maintenance releases carry security patches but no new features. For Elastic, check the end-of-maintenance dates on the product end-of-life page for the 8.x and 9.x lines. Record the dates in the inventory so the upgrade plan has a fixed target.
Ask counsel to review the managed service terms
Send counsel the inventory, the saved license files, the feature-to-tier table and the service model record, and ask for a written view on whether each planned use is permitted under the applicable license. Ask specifically about any arrangement where a third party consumes the service, any use of the software inside a product you sell, and any obligations that follow from AGPLv3 if you choose that option. Your legal team's reply, with its date and scope, is the document that closes the step.
Record the position and set a review trigger
Combine the outputs into one licensing position record that states the chosen license for each component, the tier and subscription status for each paid feature, the approved service model, counsel's conclusions and the support dates. Assign an owner and name the events that should reopen the review, such as a new feature, a change to how users access the service, a new version line, or a change in license terms published by either vendor. Confirm the record with procurement so that quotes and contracts match it.
How release support windows affect license choice
The license decides what you may do with the code, but the maintenance policy decides how often you must upgrade it. Both projects set their own support windows, and those windows shape upgrade planning whatever license you choose. OpenSearch keeps each version in maintenance until the next major version enters maintenance or one year passes, whichever is longer. During maintenance it receives bug fixes and security patches but no new features. Version 1 reached end of life on May 6, 2025, and version 2 is maintained through the 4.0 GA release. The current OpenSearch line is 3.9.0, released on September 29, 2026, and the 2.19 line still received a 2.19.6 maintenance release on July 6, 2026. A team on 2.19 should plan its path to the 3.x line now, while the patch stream is still active.
Elastic uses a different rule. Each major release is maintained for the longer of 30 months from general availability or 18 months after the next major release, plus 6 more months of support. Elastic's end-of-life page lists end of maintenance for the 8.x line on January 15, 2027, with 8.x support ending July 15, 2027, and for the 9.x core stack on October 15, 2027. The current release lines are 9.5.5 and 9.4.8, released on October 6, 2026, with 8.19.23 still maintained. Before you commit to either stack, confirm these dates on Elastic's end-of-life page, because they are the dates your patch obligations will follow, and map them against your change calendar and any compliance evidence you must keep for patching.
Use these windows as a planning input alongside the license. For a self-hosted SIEM backend, the question is which upgrade path you can fund and staff over the next few years, not only which license is permitted. Read the sibling OpenSearch vs Elasticsearch comparison for where the APIs have diverged and what migration in either direction involves, and confirm with your own platform team how long a major upgrade takes in your environment before you set a target version.
Questions buyers ask about OpenSearch and Elastic licensing
Is OpenSearch free to use commercially?
Yes, OpenSearch is licensed under the Apache License, Version 2.0, and the OpenSearch FAQ does not describe any paid edition of the core project. The license itself does not charge per node, per user or per gigabyte. Your costs sit elsewhere: the engineers who install, tune, secure, upgrade and back up the cluster, the hardware or cloud spend that stores your logs, and any support contract you choose to buy from a vendor or partner. Have counsel confirm how Apache-2.0 applies to your specific distribution, plugins and any modifications you make before you ship a product that embeds it.
Does ELv2 let a provider host Elasticsearch?
The Elastic License 2.0 is the default license for Elasticsearch and Kibana source code, and Elastic's licensing FAQ states it is not an OSI-approved open source license. ELv2 restricts providing the software to third parties as a hosted or managed service, so a managed service provider cannot offer Elasticsearch as a service under that license without a separate agreement with Elastic. Internal use inside your own organization is a different question. Ask counsel to read the full ELv2 text against your planned use, including whether a partner operating the cluster for you counts as providing a managed service.
What does AGPLv3 change?
AGPLv3 is a third license option for Elasticsearch and Kibana source code, which Elastic added in September 2024 before the 8.16 release. Elastic says it added AGPLv3 to offer an OSI-approved open source option alongside ELv2 and SSPL 1.0. The AGPL requires that users who interact with a modified version over a network can obtain its source code, which matters if you change the software and expose it to others. Whether AGPLv3 suits you depends on your modifications, your distribution model and your internal policy on copyleft licenses, so have counsel review it before choosing that option.
Is OpenSearch OSI-approved?
OpenSearch is licensed under Apache-2.0, which is an open source license, and the OpenSearch project is released under it in full. By contrast, Elastic's licensing FAQ states that ELv2 and SSPL are not OSI-approved open source licenses, so Elasticsearch is open source only if you select the AGPLv3 option. Confirm the license of each individual component you deploy, including Elastic-branded agents, plugins and dashboards, because mixing components from different license families affects your compliance position. Your procurement or legal team should record the license for every artifact in your bill of materials.
Can we switch licenses later and what does it cost?
Switching is possible in both directions, but the cost depends on the features you rely on and the version you are running. OpenSearch is a fork of Elasticsearch 7.10 and is wire-compatible with Elasticsearch 7.10, can use indices from Elasticsearch 6.0 through 7.10, and supports rolling upgrades from those versions. Moving to newer Elasticsearch releases or to OpenSearch from later Elastic versions involves API differences that have grown since the fork, so plan a test migration, a rollback path and a review of client code, dashboards and security configuration. The main cost is engineering and testing time, which grows with the number of indices, pipelines, custom integrations and saved objects. Ask any partner for a written scope that lists these items before work starts.
What work does a license review need from our team and from a partner?
Your team should inventory every component in the stack, including the Elasticsearch or OpenSearch version, Kibana or OpenSearch Dashboards, agents, plugins, ingest tooling and any Elastic-branded software. For each item, record the license, the edition you use and how you use it: internal operations, customer-facing services, or a hosted offering. Your counsel then confirms how those license terms apply to your use, and that conclusion is a legal opinion, not a technical one. A partner such as DeployOpen can document the deployed components, versions and configuration, and prepare the technical evidence that counsel asks for, but it does not provide legal advice on license terms. Confirm the scope, deliverables and timeline in writing before the work starts.
Which Elastic features need a paid subscription if we keep Elasticsearch?
Elastic's self-managed subscriptions page lists single sign-on with SAML, OpenID Connect, Kerberos and JWT among its security features, and it places the Platinum tier, which is no longer sold to new customers, and the Enterprise tier as the paid options. Elastic's announcement blog post states that single sign-on, Active Directory and LDAP authentication and field- or document-level security stayed in paid tiers after TLS, the file and native realms and role-based access control became free in the Basic tier. Read the current subscription page before you budget, because editions change. Ask Elastic for a written quote that names each feature your architecture requires.
What switching later costs and what to ask in a quote
The cost of switching between OpenSearch and Elasticsearch is mostly engineering and review time, not a license fee. Before you commit, ask the implementer to break the work into four lines: license review by counsel, client and API changes, migration tooling, and upgrade path. Counsel's review covers what your organization ships, hosts or offers to customers, and whether any internal platform or managed service it builds would fall under the Elastic License 2.0 or the SSPL. That review is a one-time cost for most teams, but it recurs whenever you change product scope, add a managed offering or move to a different Elastic distribution.
The engineering cost depends on how much your code depends on Elastic-specific behavior. OpenSearch is a fork of Elasticsearch 7.10 and is wire-compatible with it, and it can use indices from Elasticsearch 6.0 through 7.10 with rolling upgrades from those versions, according to the OpenSearch FAQ. That makes a move between those two lines comparatively contained, while later Elastic releases may have APIs that OpenSearch does not match. Ask for an inventory of client libraries, index templates, ingest pipelines, Kibana or Dashboards saved objects and alerting rules, with each item marked as unchanged, adapted or rebuilt. Migration tooling and rolling upgrade steps are one-time work, but the parallel run period adds infrastructure cost while both clusters are live.
In the written scope, request named components with versions, a license review deliverable that states the conclusions and the assumptions behind them, and explicit migration boundaries. The boundaries should say which indices, dashboards, security roles and SIEM content move, which stay on the source cluster, and who validates query results and alert behavior after cutover. Confirm whether the quote covers only the search cluster or also the agents, shippers and dashboards that feed it. Ask what happens if you need to roll back. Vendor prices and support terms are for you to confirm directly with Elastic and the OpenSearch community distributions you evaluate, since DeployOpen does not publish a price list and quotes follow from the agreed scope.
How DeployOpen helps evaluate and implement this choice
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For the OpenSearch or Elasticsearch decision, we start from your licensing position and build from there, so the choice is tested against your actual deployment and not a generic checklist.
How we scope
- Written scope lists which license terms, editions and features your team must confirm before work starts.
- We map which security and identity controls your use case needs, then flag which of them sit in paid Elastic tiers.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any build begins.
- We document who in your organization will own license review, vendor contact and renewal decisions after handover.
How we build
- We stand up the chosen search backend in your environment, using Docker, Helm, the OpenSearch Kubernetes Operator, tarball, RPM, Debian or Ansible as your team prefers.
- We configure authentication, role-based access and TLS according to the scope agreed in writing.
- We test ingestion, index lifecycle and security settings against the requirements recorded in the scope.
- Where a migration path is in scope, we plan and test the move between the two platforms in a non-production copy first.
How we hand over
- Handover documentation records the license, edition and version decisions made, with the reasons behind each one.
- You receive configuration, runbooks and an inventory of components and their license terms for your own audit trail.
- We prepare controls and evidence for compliance assessments, but independent auditors issue any audit report or certification.
- Knowledge transfer sessions cover upgrade steps, maintenance windows and how to recheck license terms when versions change.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
- A retainer can cover tracking vendor release lines and maintenance windows so your team sees changes before they affect operations.
- Ask for the support scope, response expectations and upgrade responsibilities in the written quote before you sign.
- Ask your legal and procurement teams to confirm license terms for your specific use, since licensing advice is outside our role.
