Before migrating to a new data platform, you should ask vendors about data sovereignty, open-source licensing, deployment flexibility, total cost of ownership, security and compliance capabilities, and long-term migration and support commitments. These six areas separate platforms that genuinely support your operational independence from those that trade one form of lock-in for another. The questions below give you a structured framework for evaluating any vendor honestly, including the ones who sound best in a demo.
At Stackable, we built the Stackable Data Platform (SDP) specifically to address the gaps that come up repeatedly in these evaluations. At the end, you’ll see exactly how the SDP holds up against each of these areas.
What happens to your data sovereignty when you switch platforms?
When you switch data platforms, your data sovereignty depends entirely on where your data is stored, in what format, and who controls access to it. A platform that stores data in proprietary formats or tightly couples storage to its own APIs can leave you unable to access your data without the vendor’s software, even after you’ve paid for it. Data sovereignty means you retain full control over your data at all times, independent of any vendor relationship.
The key questions to ask are practical ones: Can you export your data in open, standard formats at any time? Does the platform use open table formats like Apache Iceberg or Apache Parquet, or does it wrap data in vendor-specific structures? Who holds the encryption keys? Where is the data physically stored, and can that location be mandated by your organization?
For organizations in regulated industries, data sovereignty also has a compliance dimension. The NIS-2 Directive (always hyphenated) and the Digital Operational Resilience Act (DORA) both place obligations on organizations to maintain operational control over critical data infrastructure. A vendor that cannot clearly answer where your data lives and who can access it is not a vendor you should migrate to.
How do you evaluate a vendor’s open-source commitments?
To evaluate a vendor’s open-source commitments, look at whether their core software is published under an approved open-source license, whether contributions are made upstream to the projects they depend on, and whether the source code is genuinely accessible or just visible. Some vendors describe themselves as “open source” while keeping critical components proprietary or releasing code under licenses that restrict commercial use.
Concrete signals of genuine open-source commitment include:
- Source code published in a public repository with an OSI-approved license
- Active upstream contributions to Apache Software Foundation projects or equivalent
- A community edition that includes all core functionality, not just a stripped-down trial tier
- Clear documentation of which components are open source and which are proprietary add-ons
- Transparency about how the vendor sustains the project commercially without restricting user rights
Open-core models, where the free version is intentionally limited to drive upgrades, are common. That is not inherently bad, but you should know exactly where the line is before you commit. Ask the vendor to show you the license file, not just the marketing page.
What should you ask about Kubernetes-native architecture and deployment flexibility?
You should ask whether the platform was designed from the ground up for Kubernetes or adapted to run on it, and whether it supports deployment across on-premises clusters, multiple cloud providers, edge environments, and hybrid configurations without requiring separate product versions. A Kubernetes-native data platform manages data workloads as native Kubernetes resources, using Operators and Custom Resource Definitions to handle provisioning, configuration, and lifecycle management declaratively.
The distinction between “runs on Kubernetes” and “Kubernetes-native” matters in production. A platform that was retrofitted to Kubernetes often exposes its origins through manual configuration steps, limited operator support, or inconsistent behavior across environments. Ask specifically:
- Are all components managed via Kubernetes Operators?
- Can you define the entire stack in YAML and apply it reproducibly across environments?
- Does the platform support infrastructure-as-code workflows with version control?
- What happens when a node fails or a pod is evicted? Is recovery automated?
- Can you run the same configuration on-premises and in a cloud provider without modification?
Deployment flexibility is also a sovereignty question. If a platform only runs well in one cloud provider’s managed Kubernetes service, you have not escaped lock-in, you have just moved it one layer down.
How can you assess the real cost of vendor lock-in before signing?
To assess the real cost of vendor lock-in, calculate the cost of exit, not just the cost of entry. This means estimating what it would take to migrate your data, rebuild your pipelines, retrain your team, and replace proprietary APIs if you needed to leave in three to five years. Vendors rarely make this calculation easy, which is itself a signal.
Specific areas where lock-in accumulates include proprietary query languages or APIs with no open equivalent, data stored in formats only the vendor’s tools can read efficiently, managed services that abstract away configuration in ways that cannot be exported, and licensing structures that make it expensive to scale without upgrading to higher tiers.
Ask vendors directly: What does an exit look like? How long does a full migration typically take for an organization of our size? What data formats do you use for storage, and are those formats readable by third-party tools? If the vendor cannot answer these questions clearly, that tells you something about the relationship you are entering.
Transparent pricing and licensing are easier to evaluate upfront. The hidden costs of lock-in only appear later, and they tend to be larger than anyone projected.
Which questions reveal whether a vendor can support enterprise-grade security and compliance?
The questions that reveal enterprise-grade security and compliance capability are the ones that ask for specifics rather than assurances. Ask about authentication and authorization models, encryption in transit and at rest, audit logging, supply chain security, and how the vendor handles disclosed vulnerabilities. A vendor that responds with general statements about “enterprise security” without technical detail is not a vendor whose security posture you can verify.
Supply chain and vulnerability management
Ask whether the vendor maintains a Software Bill of Materials (SBOM) for their platform components and whether they operate as a CVE Numbering Authority (CNA) for their software. Ask how they communicate vulnerabilities, whether through Common Security Advisory Framework (CSAF) documents or Vulnerability Exploitability eXchange (VEX) files, and what their typical time-to-patch looks like for critical Common Vulnerabilities and Exposures (CVE) disclosures.
Regulatory alignment
For organizations subject to DORA, the NIS-2 Directive, or the Cyber Resilience Act (CRA), ask vendors to describe how their platform supports your obligations under each. The CRA in particular places new requirements on software vendors supplying products with digital elements, so understanding whether your vendor has begun aligning their practices is a reasonable due diligence question. We inform here, we do not provide legal advice.
What migration support and long-term service commitments should a vendor guarantee?
A vendor should be able to describe clearly what migration support looks like in practice, including who is responsible for what, what tooling is provided, and what happens when the migration hits problems. Long-term service commitments should cover update and patch delivery, upgrade paths between major versions, and what your options are if you need to reduce or exit the commercial relationship.
Questions worth asking before you sign include:
- Do you provide a structured migration path from our current platform, or is that our responsibility?
- What does the upgrade process look like for major version changes, and how disruptive is it typically?
- How do you handle end-of-life for components you depend on, such as upstream Apache projects?
- What are the terms if we need to reduce our subscription or move to self-managed operation?
- Is consulting and training available, and is it delivered by the same team that builds the platform?
The answers here tell you as much about the vendor’s business model as they do about the product. A vendor whose commercial model depends on making exit difficult will answer these questions differently from one whose model depends on earning your continued business.
How Stackable helps with data platform vendor evaluation
The SDP was built to answer most of the questions above with verifiable facts rather than sales assurances. Here is what that looks like concretely:
- Data sovereignty: The SDP stores data in open formats and runs entirely in your infrastructure, whether on-premises, in any cloud, or in a hybrid environment. You hold your data and your keys.
- Open-source commitment: The SDP is 100% open source under OSI-approved licenses. All core modules are included in the community edition. The source code is publicly available, and Stackable contributes upstream to the Apache projects the platform depends on.
- Kubernetes-native architecture: Every component in the SDP is managed via a dedicated Kubernetes Operator, including the Stackable Operator for Apache Kafka®, operators for Apache Druid™, Trino, Apache Spark™, and others. Configuration is fully declarative and reproducible across environments using
stackablectl. - No vendor lock-in: Because the SDP is built on open-source components with open APIs and open data formats, exit does not require a migration away from proprietary structures. You can move, scale, or self-manage without renegotiating your position.
- Security and supply chain: Stackable operates as a CVE Numbering Authority (CNA) and publishes CSAF and VEX documents for disclosed vulnerabilities. We maintain a fully traceable software supply chain aligned with Supply-chain Levels for Software Artifacts (SLSA) principles.
- Migration and support: Commercial subscriptions include expert support from the team that builds the platform. Consulting and training are available. Pricing is transparent, with no hidden scaling tiers.
If you are currently evaluating platforms and want to work through these questions with the Stackable team directly, get in touch with us and we will give you straight answers, including the ones that might not favor us.