--- title: "Avoiding Vendor Lock-In: 7 Strategies for IT Decision-Makers" date: 2026-01-27T11:50:00+01:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//en/blog/vendor-lock-in-vermeiden" section: "Entries: Articles" --- ### Why Lock-In Is Getting More Expensive [\#](#why-lock-in-is-getting-more-expensive "Why Lock-In Is Getting More Expensive") The economics of lock-in have intensified. Cloud providers generate a significant share of margin not from storage but from egress fees charged when data leaves their infrastructure; industry analyses, including work by the European cloud association CISPE, have documented egress charges that exceed the underlying transfer costs many times over. For backup and archiving workloads, where data volumes are large and retrieval scenarios (disaster recovery, audits, migrations) are predictable, this is not a theoretical risk, it is a budget line item that routinely catches organizations off guard. On the software side, proprietary backup formats, deduplicated repositories that only one vendor can read, and agent architectures that require the original vendor’s tools for any restore all serve the same function: raising exit barriers. The EU Data Act addresses this directly. Since September 2025, providers of data processing services must enable switching to alternative providers or to on-premises infrastructure, and may charge for the switch only at reduced, cost-based rates. From 12 January 2027, switching charges, including egress for the switch, are banned entirely. Organizations negotiating cloud and SaaS contracts now have concrete regulatory leverage, and should use it. --- ### Strategy 1: Prefer Open Standards and Protocols [\#](#strategy-1-prefer-open-standards-and-protocols "Strategy 1: Prefer Open Standards and Protocols") Open protocols are the single most effective lock-in prevention mechanism. When evaluating any storage or backup system, require native support for: - **NFS / SMB:** standard file-level access, universally supported - **S3-compatible API:** the object storage baseline; verify actual compatibility, not just marketing claims - **iSCSI / Fibre Channel:** block-level access for workloads that require it - **REST / documented APIs:** for management and automation The key question is not whether a vendor supports these protocols, but whether the data can be fully accessed and restored using only those open interfaces, without the vendor’s proprietary client, agent or cloud relay. Request written confirmation. Vendors whose systems require a proprietary component for restores introduce lock-in at the restore path, the worst possible moment for a dependency to surface. On-premises storage systems that speak standard protocols natively allow organizations to swap backup software, change hardware generations or migrate between systems without converting formats or re-ingesting data. --- ### Strategy 2: Identify Proprietary Format Risk in Backup Software [\#](#strategy-2-identify-proprietary-format-risk-in-backup-software "Strategy 2: Identify Proprietary Format Risk in Backup Software") Backup software is frequently the hidden source of lock-in, not the storage hardware underneath it. Proprietary deduplicated repositories, encrypted containers that only the original backup engine can decrypt, and catalog databases with no documented schema all indicate that exit will require either a full re-backup (weeks or months for large datasets) or a paid migration service from the same vendor. **Evaluation questions for backup software:** - In what format are recovery points stored? Is the format documented? - Can a restore be performed without the original backup server, using only open tools? - What happens to backup data if the vendor discontinues the product or the license lapses? - Is the deduplication metadata exportable, and in what format? - Does the vendor offer a supported, tested migration path to competing products? Backup applications that store data in documented formats carry substantially lower lock-in risk than systems that store data in opaque, compressed and encrypted blobs accessible only via the vendor’s API. --- ### Strategy 3: Calculate Egress Costs Upfront [\#](#strategy-3-calculate-egress-costs-upfront "Strategy 3: Calculate Egress Costs Upfront") Egress calculation is straightforward in principle but routinely skipped during procurement because proposals obscure or omit it. Apply this methodology before signing any cloud storage or backup-as-a-service contract: **Step 1: Estimate the data volume subject to egress.** For backup workloads: the total protected volume, not daily change rates. A full recovery scenario means restoring the complete dataset. **Step 2: Identify the egress rate.** Hyperscalers publish tiered egress pricing; typical internet egress list rates run around USD 0.05 to 0.09 per GB. Free monthly allowances are irrelevant at enterprise backup volumes. **Step 3: Model three scenarios.** - Routine operations: regular restore tests (5 to 10% of the dataset) - Incident response: one full restore per year - Full migration to another provider: 100% of stored data (note: from January 2027 the switch itself must be free of charges under the EU Data Act; operational restores remain billable) **Step 4: Annualize and add to TCO.** Add egress to storage fees, compute and support. For large datasets, egress for restores and tests alone can rival years of storage fees. **Benchmark (illustrative):** A 100 TB dataset at USD 0.08 per GB egress costs roughly USD 8,000 to retrieve once. At 500 TB, roughly USD 40,000 per full retrieval. On-premises storage has zero egress cost by definition. --- ### Strategy 4: Contractually Secure Exit Strategies (EU Data Act) [\#](#strategy-4-contractually-secure-exit-strategies-eu-data-act "Strategy 4: Contractually Secure Exit Strategies (EU Data Act)") The EU Data Act (Regulation (EU) 2023⁄2854, applicable since 12 September 2025) creates specific obligations for providers of data processing services. Procurement teams should translate these into contract language: **What the Data Act requires from providers:** - Data portability: customers can retrieve all exportable data and digital assets in a structured, commonly used, machine-readable format - Switching support: providers must support migration to another provider or to on-premises infrastructure, with a standard 30-day transition period - Charges: switching charges only at reduced, cost-based rates now, and banned entirely from 12 January 2027 - Transparency: contracts must specify switching procedures, data formats and known restrictions **What to add to contracts now:** - An explicit clause invoking the Data Act’s switching and portability provisions - A defined SLA for a complete export in an open format - A cap on switching-related fees, anticipating the 2027 ban - A data deletion certification upon contract end (supporting GDPR Art. 28 obligations) - For critical systems: escrow arrangements for configurations or source code with a neutral third party For non-EU providers, confirm applicability: providers serving customers in the EU fall within the Data Act’s scope for those services. --- ### Strategy 5: Multi-Vendor Architecture: Separate Backup Software from Storage Hardware [\#](#strategy-5-multi-vendor-architecture-separate-backup-software-from-storage-hardware "Strategy 5: Multi-Vendor Architecture: Separate Backup Software from Storage Hardware") Single-vendor stacks, where backup software, deduplication appliance and cloud target all come from one provider, offer convenience at procurement and maximum leverage to the vendor at renewal. Structural separation of layers preserves the ability to replace each one independently: - **Backup software** (for example Veeam, Commvault, Bacula): replaced on feature gaps, licensing cost or vendor direction - **Primary storage target** (on-premises NAS, NFS/SMB or S3-compatible appliance): replaced on capacity, performance or refresh cycles - **Secondary / air gap target** (physically isolatable backup system): driven by compliance requirements and recovery SLAs - **Archive / WORM storage** (hardware WORM appliance): driven by retention policy and regulatory audits When each layer communicates via open protocols and stores data in accessible formats, migration risk is contained to one layer at a time. A hardware refresh does not force a backup software change; a software migration does not force a storage re-architecture. On-premises storage that presents standard S3-compatible endpoints, NFS shares or iSCSI targets to the backup software above it enables this separation structurally: the software does not care which hardware is underneath, and the hardware does not care which software writes to it. --- ### Strategy 6: Test Data Portability Before Signing [\#](#strategy-6-test-data-portability-before-signing "Strategy 6: Test Data Portability Before Signing") Portability claims are frequently made and rarely tested during procurement. The EU Data Act provides a regulatory basis for demanding proof, not promises. Build a portability proof of concept into every storage and backup procurement. **Portability PoC requirements (before contract signature):** - Full export of a representative dataset (at least 1 TB) in a documented, open format - Successful restore of that dataset using only open tools, no proprietary client - Export completion within a defined time window (put the SLA in the contract) - Documentation of the export format: schema, encoding, compression, encryption - Successful import of the exported data into at least one competing system If the vendor cannot or will not perform this demonstration, treat it as a disqualifying factor. ​“We can do that” is not equivalent to ​“here is how it works, documented and tested.” For backup software specifically: run a restore-only test on an isolated system with no vendor agent installed. If it fails, your recovery path in a real disaster is vendor-dependent. --- ### Strategy 7: Evaluation Criteria for Sovereign Storage Solutions [\#](#strategy-7-evaluation-criteria-for-sovereign-storage-solutions "Strategy 7: Evaluation Criteria for Sovereign Storage Solutions") Data sovereignty and vendor independence reinforce each other. A storage solution that keeps data on-premises, under EU jurisdiction, with open protocols and no mandatory cloud connectivity achieves both simultaneously. **Lock-in risk by storage type (qualitative):** - Hyperscaler object storage: low format lock-in, high egress cost, high jurisdictional risk (CLOUD Act exposure); overall high - EU-based S3-compatible cloud: low format lock-in, medium egress cost, lower jurisdictional risk; overall medium - On-premises storage with standard protocols: low lock-in across the board, no egress, no jurisdictional risk - On-premises hardware WORM appliance: low lock-in, no egress, no jurisdictional risk - Proprietary integrated backup appliance: high protocol and format lock-in despite no egress; overall medium to high **Sovereign storage evaluation criteria:** 1. **Data residency:** Is the physical location of all data fully under your control? 2. **Legal jurisdiction:** Which country’s law governs access requests? Is the vendor subject to extraterritorial laws such as the US CLOUD Act? 3. **Protocol independence:** Can all data be accessed, restored and migrated via open, documented protocols? 4. **No mandatory cloud connectivity:** Does the system require a cloud component for licensing, management or restore? 5. **Vendor location:** Is the vendor subject to EU law? Is support available within the EU? 6. **Hardware origin:** Where is the hardware manufactured, and how transparent is the supply chain? 7. **Exit documentation:** Does the vendor provide documented migration procedures to alternative systems? --- ### Procurement Checklist: Vendor Lock-In Due Diligence [\#](#procurement-checklist-vendor-lock-in-due-diligence "Procurement Checklist: Vendor Lock-In Due Diligence") **Protocols and formats** - All supported protocols documented and standards-compliant? - Export format documented, with no proprietary-only dependencies? - Restore possible without a proprietary client? **Commercial terms** - Egress costs identified and modelled for the full migration scenario? - EU Data Act portability and switching obligations reflected in the contract? - Exit clause with a defined SLA for complete data export? - No auto-renewal without explicit opt-in? **Architecture** - Backup software and storage hardware independently replaceable? - No mandatory cloud component for licensing or core functionality? - Portability demonstrated in a PoC, not just claimed? **Sovereignty** - Data residency confirmed (physical location)? - Vendor not subject to extraterritorial access laws affecting EU data? - EU-based support and legal jurisdiction? --- ### Further Resources [\#](#further-resources "Further Resources") → EU Data Act: What Changes for Cloud Users (/en/blog/eu-data-act-cloud-nutzer/) → Data Egress Fees: The Hidden Costs of Your Cloud Backup (/en/blog/egress-kosten-cloud/) → What Is Data Sovereignty? Definition and Three Dimensions (/en/blog/was-ist-datensouveraenitaet/) → Supply Chain Security Under NIS2: How to Evaluate Your Hardware Vendors (/en/blog/supply-chain-security-nis2/) → Silent Brick System: On-Premises Secondary Storage with Open Protocols (/en/produkte/silent-brick-system/) → Silent Cubes: Hardware WORM Archiving (/en/produkte/silent-cubes/) ### Supply Chain Security Supply chain security refers to the systematic assessment, securing and contractual obligation of all IT service providers, cloud providers and storage vendors in an organization's IT supply chain — NIS2 and DORA make this mandatory and require evidence of data localization, audit rights and exit strategies. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/supply-chain-security) ### Data Sovereignty Data sovereignty describes an organization's complete control over its data: where it is stored, who can access it, which legal framework applies to it and whether it is available at any time without dependency on a single provider. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/data-sovereignty) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### GDPR The GDPR (General Data Protection Regulation, EU 2016/679) is the European regulation for the protection of personal data — particularly relevant for IT infrastructure in Art. 5 (principles), Art. 17 (right to erasure), Art. 28 (processors) and Art. 32 (security of processing). [Mehr erfahren →](https://www.fast-lta.de//en/glossary/gdpr) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm)