Controllability is more important than the ownership form of a tool
Unnecessary dependency arises when a provider not only provides a function but effectively becomes the owner of data access, process knowledge, or operational capability.
Companies reduce this risk through documented responsibilities, exportable data, open or at least documented interfaces, independent access, traceable contracts, and a realistic exit scenario. Complete independence is rarely economical. Controllable dependency is the goal.
Starting point
By the end of 2022, the digital tool landscape of many companies had grown significantly. Websites, newsletters, CRM, analytics, appointment booking, project management, file storage, and campaigns were often connected via specialized services.
This division of labor had clear advantages. Functions could be introduced faster. Internal development was not necessary for every use case. Updates, security, and operation were partly the responsibility of the provider.
At the same time, dependencies arose which only became visible during a change, a price increase, a failure, or the end of a service provider relationship. Access credentials were held by individuals. Data could only be partially exported. Automations were not documented. Content was tied to proprietary page elements. A central function depended on a single extension.
The problem was not the use of external tools. It was the lack of an architectural decision about which parts are outsourceable and which foundations must remain manageable within the company.
What lies behind the problem
Function and system are confused
A tool solves a specific task. A system connects tasks, data, roles, and handovers. If the tool decision is made without a system perspective, each department optimizes its own section.
The CRM fits sales, the form fits marketing, and the website fits the current design. Whether data formats, consents, responsibilities, and interfaces match will be clarified later. This creates dependencies not only on the provider but on the grown combination.
Convenience masks switching costs
A service can be very simple in everyday use and generate considerable costs upon switching. It's not just license fees that are decisive. Switching costs include:
- Data cleansing and migration
- Building new interfaces
- Training and process adjustment
- Loss of historical data or metadata
- Reconstruction of undocumented automations
- technical rework on website or forms
- temporary operational risks
These costs are not fundamentally an argument against a tool. They must be visible before the decision is made.
Data export is equated with portability
Many systems offer an export. However, an export alone does not guarantee practical interchangeability. Data can be incomplete, poorly documented, or in a format that loses relationships and history.
Portability therefore demands more: Which data is exported? Are attachments, statuses, assignments, and consent records included? Can they be meaningfully imported into another system? Is the structure documented?
Knowledge remains with service providers or individuals
A technical solution can formally belong to the company and still not be manageable in practice. This happens when only an external person knows about access, hosting, extensions, interfaces, or special logic.
Dependency is then not purely a product issue. It is a documentation and responsibility problem.
Strategic Classification
Open standards create interoperability and connection possibilities
Official guidelines on open standards have emphasized interoperability, data exchange, and the avoidance of unnecessary vendor lock-in for years. Open standards do not guarantee easy migration. However, they increase the likelihood that systems can be connected or replaced via documented formats and interfaces.
For companies, this does not mean exclusively using open-source software. Proprietary services can be technically and economically sensible. The crucial factor is whether critical data and processes remain in understandable, accessible structures.
Core and modules must be separated
A robust architecture distinguishes between the company's own core and interchangeable modules.
The core typically includes:
- Domains and central accounts
- approved content and files
- Customer and contact data within the legally permissible scope
- Documentation of processes and interfaces
- Roles and access rights
- Measurement definitions
- contractual and technical evidence
Modules can be hosting, CMS, newsletter, appointment booking, analysis, or automation. They may be important. However, they should not make the core inaccessible.
Exit capability belongs to the selection decision
A change plan is not an announcement that the provider will be leaving soon. It is a test of one's own ability to act.
Before a critical implementation, companies should clarify:
- Which data and content must be fully exportable?
- Which interfaces are used?
- Who has administrative access?
- What contract terms and additional costs apply?
- How long can operations continue without the service?
- What alternative solution would be fundamentally conceivable?
These questions often already improve ongoing usage.
Perspective from practice
Dependencies often become visible during website relaunches. Although content can be exported, page structures, forms, or individual modules are missing. The company owns its texts, but not the functional logic.
A similar pattern emerges with automations. A process works for years. As soon as the responsible person is unavailable, it is no longer clear which data is transferred to which system and how errors are detected.
The practical countermeasure is not complete in-house technical development. It is robust minimum documentation: system purpose, owner, access points, data types, interfaces, dependencies, backup, costs, contract deadlines, and exit possibility.
The company's own system base
Framework of action
1. Determine criticality
Assess which tools are crucial for revenue, customer communication, website operation, or proof of compliance. The more critical the function, the higher the requirements for access, documentation, and switching options.
2. Secure administrative control
Central accounts, domains, hosting, and billing should be assigned to the company. External partners receive appropriate roles, but not sole control.
3. Practically test export
Do not rely on a functional description. For critical systems, perform a test export and check completeness, format, and reusability.
4. Document interfaces
Record which data flows where, which triggers apply, and how errors are detected. Also document manual handovers.
5. Define exit scenario
Define how an orderly transition could take place. The scenario does not need to be elaborated down to the last technical detail. It must show that data, access, and responsibility do not lie entirely with the provider.
What companies should not do
Companies should not base dependency solely on license costs or the term "cloud." A locally operated, undocumented special solution can be more binding than a well-documented cloud service with open interfaces.
It is equally wrong to assume that every tool must be replaceable at any time without effort. Specialization creates deliberate dependencies. The strategic question is whether the benefits, risks, and switching costs are transparent and justifiable.
Consequences for companies
Digital sovereignty does not arise from foregoing providers. It arises from clear ownership, access, and architecture decisions.
A company remains operational if it knows its data, documents processes, controls central access points, and can realistically assess switching options. This makes tools modules of the system, not its owner.
Subject-matter connection
Check system dependencies before expansion or change
A digital system architecture organizes critical data, tools, interfaces, roles, and switching risks. SDC-Discovery can systematically capture and prioritize this initial situation before a relaunch, consolidation, or the introduction of new systems.
Clarify digital system landscape and dependencies
Sources and technical foundations (5)
- Government Digital Service, Open Standards Principles, 2018. Open source
- Government Digital Service, Working with open standards, available before December 2022. Open source
- Government Digital Service, Managing technical lock-in in the cloud, 2019. Open source
- National Institute of Standards and Technology, NIST Cloud Computing Standards Roadmap, Special Publication 500-291 Revision 2, 2013. Open source
- European Union, General Data Protection Regulation, Article 20 on data portability. Open source
