Avoid vendor lock-in: review a service before buying

The Moment Before Lock-in Is Created

Claudia is about to make a decision that looks routine. The 42-employee DACH industrial service provider serves industrial customers across the DACH region. The team handles around 600 inquiries per month, maintains 280 active maintenance contracts, and works across 14 SaaS tools. A new vendor promises to combine CRM, proposal preparation, and ticket escalation in one package. For Claudia, that sounds like relief. For Mira in Operations, it means less copy-and-paste. For Jonas, the technical lead, it also means that a critical workflow may disappear into a system nobody can describe outside the vendor interface.

Four questions need answers before signing: which data can be exported, which interfaces are required, who controls access, and how could the workflow be replaced? This article covers that purchasing decision. The cloud exit guide covers carrying out a later migration.

The scenario is illustrative, but the operating context is real. According to Eurostat, 52.74% of EU enterprises used paid cloud services in 2025. Among small enterprises the share was 49.3%; among medium-sized enterprises it was 66.78%. Cloud and SaaS are no longer enterprise-only infrastructure. They are daily operating infrastructure for companies with ten or more employees. Using them does not mean you must operate everything yourself. It does mean you need to know which dependency you are deliberately accepting.

Why Lock-in Is Usually a Quiet Design Decision

Vendor lock-in is often described as if a company simply chose the wrong provider. That is too shallow. Many dependencies grow from useful decisions that were never treated as architecture decisions: a quick export in a proprietary format, a webhook chain without a contract, an identity setup with too many implicit permissions, a managed database without a tested restore path, or an automation whose logic only exists inside one tool's UI.

The stronger question is not: "Which vendor should we avoid?" The stronger question is: "Which dependency is deliberate, documented, reversible, and worth the relief it buys?" A payment provider, CRM, cloud service, or workflow platform can be sensible when the data structure is known, exports are tested, permissions are documented, and a replacement path is at least sketched. The same service becomes risky when it turns into the only place where process knowledge, customer data, access rights, and operating logic meet.

The EU/OECD note on competition in cloud computing names typical switching barriers: egress fees, technical barriers, lack of interoperability, lack of data portability, and licensing practices. Those are market mechanisms, but they show up in very concrete ways. Jonas cannot move an application because events are tied to proprietary APIs. Mira cannot explain a process because approval rules live in a SaaS automation builder. Claudia cannot answer an enterprise customer confidently because the data flow exists only as an admin screenshot.

The EU Data Act has strengthened expectations around switching and portability for data processing services since September 12, 2025. From January 12, 2027, switching charges, including certain egress charges, are expected to be removed. That is an important policy signal. It is not an architecture substitute. A right to switch does not document your field logic, credentials, automations, exceptions, or restore tests. This article is marketing and architecture information, not legal advice.

The Five Layers of Vendor Dependency

Lock-in becomes manageable when you split it into layers. For an SME without a dedicated platform department, an abstract commitment to "stay portable" is not enough. The team needs questions Claudia can understand commercially, Jonas can verify technically, and Mira can recognize in the daily workflow. The five layers are data, APIs, identity, operating logic, and runtime.

Data formats and exports. An export button is not an exit path. Check whether the export includes metadata, IDs, attachments, permissions, status, history, and schema meaning. A CRM export without activities and approval status does not help much if those fields explain the proposal process. PostgreSQL's documentation for pg_dump shows why a concrete dump and restore test matters: data is not only exported, it is restored on another machine or architecture. Provider-specific extensions, authentication, triggers, and application coupling still need to be reviewed.

APIs and events. Many teams check whether a vendor has an API. The better question is how stable the contract is. Is there versioning, webhook retry behavior, rate-limit handling, error semantics, change notice, and a test environment? If seven production integrations depend on one proprietary event model, switching vendors is no longer a simple export. It is a rebuild of operating logic.

Identity and access. Lock-in also grows through permissions. Who owns admin accounts, service accounts, OAuth apps, API keys, SSO rules, and break-glass access? If Stefan, the external developer, built the first connections with personal credentials, that is not a small hygiene issue. It is an operating risk. Access belongs in the handover pack: owner, purpose, expiry, rotation, and replacement path.

Operating logic and automation. Workflows are often the least visible part. n8n documents workflow export and import and source control with environments. That supports a useful practice: workflow definitions can become visible, reviewable, and versioned. But exported JSON alone is not governance. Credentials, environment variables, tests, failure routes, domain owners, and review gates still need design.

Runtime and infrastructure. Kubernetes can reduce dependency when workloads are containerized and a portable runtime layer justifies the operating effort. The Kubernetes documentation describes Kubernetes as a portable, extensible, open-source platform for containerized workloads with declarative configuration and automation. It is also not a complete PaaS and not a universal remedy. For small workloads, it can add overhead. For business-critical containerized applications, it can be the abstraction layer that makes provider moves, rollouts, and operations more standard.

The Portability Check Before Adoption

The most important portability check does not happen during a migration project. It happens before purchase, before a service becomes business-critical. Claudia does not need an 80-page architecture report for that. She needs a short review gate every new critical vendor must pass. Jonas checks the technical side, Mira checks operational reality, and Claudia decides whether the dependency is worth the relief.

The first question is: Which data must come out so the process can continue? Not only customer names and email addresses, but status, attachments, approvals, internal notes, mappings, IDs, history, and deletion information. For this DACH industrial service provider, that means: if a proposal workflow routes 600 inquiries per month, the export must contain more than contacts. It must show which inquiry is in which state, who approved what, and which follow-up action is still open.

The second question is: Which logic must not disappear into the tool? Some rules can deliberately live inside the vendor system. Critical process logic should be documented, versioned, or exportable. If a discount applies above a certain maintenance-contract class, if an inquiry about machine downtime escalates differently, or if an enterprise customer requires extra evidence, that logic should not exist only as checkboxes inside a vendor builder.

The third question is: Who owns access, documentation, and review? Vendor switching often fails not because of a data format, but because nobody owns the dependency. Nobody knows which service account is production. Nobody rotated the API key. Nobody understands the last schema change. Every business-critical dependency therefore belongs in a dependency map: owner, data, API, credentials, backup, failure path, export test, and replacement option.

Portable Architecture for Lean Teams

For SMEs, portability does not mean every system must be self-hosted. That would often be worse operations. Portable architecture means the most important dependencies are chosen deliberately and run with an exit key. Managed services may reduce operational work as long as they do not become the company's only memory.

A pragmatic stack for lean teams starts with open interfaces and documented data models. APIs are not merely "connected"; they are treated as contracts: version, purpose, fields, failure behavior, and owner. Data models are explained, not only configured in admin screens. Where data is business-critical, there should be an export and restore test. Where workflows are business-critical, there should be an exportable or at least explainable definition.

Infrastructure as Code is the next reproducibility anchor. When servers, networks, Kubernetes manifests, roles, or automation runs live in Git, review, history, and rebuild paths become possible. This is not an enterprise-only discipline. For a company with 35 to 45 internal weekly users, it is often the difference between "Jonas remembers" and "the system can be reconstructed from a known revision."

Containers and Kubernetes enter the picture where runtime portability justifies the effort. A small form or one-off report does not need a cluster. A customer portal with 240,000 records, CRM and ticketing integrations, and a clear roadmap may benefit from a portable runtime layer. Planfold can reference Kubernetes operations and cloud-native delivery with CKA- and CKAD-backed capability. LFCS supports the Linux systems foundation. These certifications are capability signals, not compliance badges.

Workflow automation follows the same pattern. n8n or comparable orchestration can be valuable when workflows are visible, exportable, monitored, and equipped with failure paths. An n8n workflow that moves invoice data, ticket status, or proposal drafts needs owners, logs, test data, environment variables, and a human approval point wherever risk appears. Automation without review only moves lock-in from one SaaS tool into another invisible flow.

From Tool Purchase to Ownership Model

This DACH industrial service provider does not need to replace every vendor. That would be neither realistic nor useful. The goal is an ownership model: Which parts of the digital machine belong to the company as knowledge, data, code, documentation, and operating procedure, and which relief is deliberately purchased?

Before the review, the proposal workflow looks like this: An inquiry arrives in the CRM, a SaaS automation tool checks maintenance contract and machine type, creates a task for Mira, and prepares a proposal template. If an API fails, Mira only sees that the task is missing. Jonas knows that a webhook exists somewhere, but not which fields trigger it. Stefan built the original workflow, but his contract ends soon. Claudia cannot clearly explain to a key account how inquiry, customer data, approval, and proposal are connected.

After 30 days, the same workflow looks different. The three most critical data flows are documented. The two riskiest API dependencies have an owner, field list, failure behavior, and vendor contact address. The most important proposal workflow has an exported definition, a short flow diagram, a manual fallback, a review date, and a credential list. Mira knows where to check if a case is stuck. Jonas knows which parts are portable and which are not. Claudia can say: "We use this vendor deliberately, and here is our handover pack."

The numbers remain illustrative. 240,000 customer records, 1.8 TB of project and service documentation, 7 production integrations, and 9 automations are not Planfold customer data. They are a realistic model for the complexity that appears in SMEs long before anyone says "platform team." The value is not a guaranteed saving. The value is decision ability: the company knows where it is dependent, why it is dependent, and what switching or handover would mean.

This is also where data localization and portability meet. If you do not know where data lives, who processes it, how it is exported, and which workflow states depend on it, you cannot make a serious provider decision. Portability is therefore not only a cloud question. It is an ownership question.

How Planfold Builds Portability Into Operations

Planfold treats portability not as an emergency folder, but as an operating discipline. That fits especially well for Mittelstand firms and solo-founder teams with 10 to 100 employees and no dedicated platform department. The task is not to move every responsibility in-house. The task is to build the care-free package so the exit key remains available.

Plan means auditing dependencies, data flows, access paths, export formats, and provider-specific logic. Which systems carry revenue, customer communication, project knowledge, or operations? Which API contracts are documented? Which backups have actually been restored? Which credentials are tied to people? Which customer or compliance questions could arrive tomorrow? The output is not a fear list. It is a prioritized dependency map.

Unfold means building the first portable layer. That can be a documented data model, a Git repository for infrastructure definitions, a Kubernetes or container deployment where runtime portability makes sense, an n8n workflow with export, owner, failure path, and review, or a DACH hosting option where governance and customer requirements demand it. Managed convenience remains valid. It is simply no longer bought blindly.

Resonate means keeping the exit path current. Quarterly reviews of the top five dependencies. Export and restore tests. Service account rotation. Monitoring for critical automations. Handover packs for customer evidence. Logged human approvals on risky decisions. Portability then stays part of operations, not a project artifact.

Planfold can support architecture for portability, documented exit paths, Kubernetes operations, n8n automation, Infrastructure as Code, DACH-first or trusted hosting options, and compliance-readiness evidence. Planfold does not replace legal advice, privacy review, formal compliance certification, or customer audits. That boundary matters: technical architecture can provide evidence and make review easier. Legal evaluation remains with the responsible specialists.

A 30-Day Start Plan Against Silent Lock-in

You do not have to start with a migration. Start with visibility. A 30-day plan is enough to turn a vague lock-in concern into a usable worklist.

Week 1: Map dependencies. List the 20 most important tools, cloud services, databases, automations, and integrations. Mark the five dependencies where an outage, price change, or provider switch would hit operations hardest. For each one, record owner, data type, user group, contracts, integrations, and critical dates.

Week 2: Check exports and access. Do not test every system. Pick the most important data source and the most important workflow. Export data, inspect fields, metadata, attachments, and status. Review admin access, service accounts, API keys, SSO rules, and backup status. Document gaps without blame.

Week 3: Decouple one critical workflow. Pick the workflow where invisibility creates the greatest risk. Write down the flow, secure the field list, name an owner, define a failure path, and check whether the logic can be exported or versioned. If automation is involved, add human approval where risk appears.

Week 4: Set the review rhythm. Portability dies when nobody revisits it. Establish a quarterly check: top five dependencies, exports, access owners, backup status, replacement path, open risks. It does not need to be heavy governance. It needs to be repeatable.

If you take this plan seriously, the result is not anti-vendor thinking. It is better purchasing and architecture discipline. You can still use managed services. You can still buy cloud. You can still rely on SaaS. The difference is that the dependency has a name, owner, export path, failure path, and review date.

Plan. Unfold. Stay Sovereign.