Vendor Lock-in & Exit Readiness Index 2026

Executive Summary

Vendor Lock-in wird häufig auf zwei zu enge Fragen reduziert: „Kann ich meine Daten exportieren?“ und „Gibt es eine API?“. Beide Fragen sind wichtig, aber unzureichend. Ein produktives System besteht aus mehreren Zustandsklassen, die gemeinsam wiederhergestellt werden müssen:

Geschäftsdaten
+ Beziehungen
+ Dateien
+ Identitäten
+ Berechtigungen
+ Konfiguration
+ Automationen und Regeln
+ Integrationen und Credentials
+ Audit-/Historiedaten
+ Runtime- und Deploymentwissen

Zusätzlich verändert sich die Integrationsoberfläche im laufenden Betrieb. APIs werden versioniert, Felder deprecated, Endpunkte stillgelegt und SDKs aus dem Support genommen. Ein statischer Export kann deshalb vorhanden sein, während die operative Exit-Fähigkeit trotzdem niedrig bleibt.

Dieser Report verbindet drei Module:

1. Lock-in-Risiko: Wie portabel sind Daten, Geschäftslogik, Runtime, Integrationen und Betrieb?
2. Exportvollständigkeit: Welche Zustandsklassen sind öffentlich exportierbar, und gibt es einen realistischen Reconstitution-Pfad?
3. API-Deprecation-Readiness: Wie früh und maschinenlesbar können Teams Breaking Changes erkennen und migrieren?

Zitierfähige Kernergebnisse

1. [CALCULATED] Der Lock-in-Risikoscore der Zehnerstichprobe reicht von 17 bis 63 Punkten; der Median liegt bei 55.
2. [CALCULATED] Das Exportvollständigkeitsmodul erreicht einen Mittelwert von 72,3 und einen Median von 73,8 Punkten.
3. [CALCULATED] Die neun untersuchten API-Ökosysteme erreichen im Deprecation-Readiness-Modul im Mittel 81,9 Punkte; der Median liegt bei 85,0.
4. [CALCULATED] Im gemeinsamen Sechs-Anbieter-Komposit reicht die Exit Readiness von 35,5 bis 64,6 Punkten.
5. [OBSERVED] Kerndaten sind in der Stichprobe häufiger exportierbar als Berechtigungen, Automationen, Audit-Zustand und lauffähige Konfiguration.
6. [INTERPRETATION] Eine API reduziert Lock-in nur, wenn ihre Version, Authentisierung, Limits, Deprecation-Signale und Exportabdeckung operationalisiert sind.
7. [INTERPRETATION] „CSV vorhanden“ ist ein Datenzugriffssignal, kein Nachweis eines Backups und kein Nachweis eines getesteten Restores.
8. [RECOMMENDATION] Kritische Plattformen sollten mindestens jährlich einen Reconstitution Drill durchführen: Export, neues Ziel, Import, Integritätsprüfung und dokumentierte Restabweichung.

Gemeinsamer Exit-Komposit der sechs Überschneidungen

Der folgende FW-Delta-Komposit kombiniert zu 60 Prozent den invertierten Lock-in-Risikoscore und zu 40 Prozent die Exportvollständigkeit. Die Gewichtung ist eine transparente Methodenentscheidung, kein externer Standard.

Rang	Anbieter	Lock-in-Risiko	Portabilitätswert	Exportvollständigkeit	Exit Readiness
1	Salesforce	54,0	46,0	92,5	64,6
2	Zapier	56,0	44,0	78,1	57,6
3	HubSpot	61,0	39,0	75,0	53,4
4	Airtable	58,0	42,0	70,0	53,2
5	Notion	52,0	48,0	58,8	52,3
6	Webflow	63,0	37,0	33,3	35,5

[LIMITATION] Nur sechs Anbieter kommen in beiden Stichproben vor. Der Komposit darf nicht auf andere Produkte übertragen oder als Marktanteil interpretiert werden.

---

1. Forschungsdesign

1.1 Forschungsfrage

Kann ein Unternehmen ein kritisches SaaS-System innerhalb eines planbaren Zeitraums verlassen und seinen fachlichen Betriebszustand auf einer anderen Runtime rekonstruieren?

Die Frage ist strenger als „Kann ein Export heruntergeladen werden?“. Ein Exit gilt in diesem Forschungsmodell erst dann als technisch belastbar, wenn folgende Kette dokumentiert ist:

Inventar
→ Export
→ Integritätsprüfung
→ Transformation
→ Import
→ Rekonstruktion von Logik und Berechtigungen
→ Rebinding von Integrationen
→ Parallelbetrieb
→ fachliche Abnahme
→ Abschaltung und Löschbestätigung

1.2 Drei Module, drei Nenner

Modul	Bewertungsrichtung	Stichprobe	Kerndatei
Lock-in-Risiko	höher = mehr Risiko	10	data/FDR-2026-02_lockin_risk_scores.csv
Exportvollständigkeit	höher = mehr dokumentierte Zustandsabdeckung	10	data/FDR-2026-02_export_completeness_scores.csv
API-Deprecation-Readiness	höher = bessere Lifecycle-Steuerbarkeit	9	data/FDR-2026-02_api_deprecation_readiness.csv

Die Module besitzen unterschiedliche Stichproben und dürfen nur für die explizite Schnittmenge kombiniert werden.

1.3 Acht Lock-in-Schichten

1. Datenmodell: Tabellen, Objekte, Relationen, IDs und Historie
2. Dateien: Attachments, Medien, Exporte, externe Speicher
3. Identität: Nutzer, Gruppen, Servicekonten, SSO-Zuordnung
4. Berechtigung: Rollen, Policies, Freigaben, Sharing
5. Geschäftslogik: Workflows, Formeln, Regeln, Trigger, Views
6. Integrationen: Webhooks, Apps, API-Verbindungen, Secrets
7. Runtime: Hosting, Scheduler, Queues, proprietäre Services
8. Betriebswissen: Runbooks, Monitoring, Ownership, Restorefolge

1.4 Aussageklassen

Die Kennzeichnungen [OBSERVED], [CALCULATED], [SCENARIO], [INTERPRETATION], [RECOMMENDATION] und [LIMITATION] gelten für den gesamten Report.

---

2. Synthese: Daten sind nicht der Betriebszustand

2.1 Exportierbar ist nicht rekonstruierbar

Ein Datensatz kann vollständig exportiert sein und dennoch nicht denselben Prozess erzeugen. Beispiel:

CRM-Kontakte vorhanden
≠
Lifecycle-Phasen, Routing-Regeln, Scoring, Automationen,
Berechtigungen, Consent-Historie und Integrationen rekonstruiert

Deshalb trennt der Report vier Stufen:

Stufe	Nachweis
Zugriff	Daten können eingesehen oder per API gelesen werden
Export	Daten können außerhalb des Systems gespeichert werden
Restore	Zustand kann in dasselbe oder kompatibles System zurückgespielt werden
Reconstitution	Fachlicher Betrieb kann auf anderer Runtime mit dokumentierten Abweichungen wiederhergestellt werden

2.2 Open Format löst nur einen Teil

CSV, JSON, XML, SQL-Dumps oder offene Telemetrieformate reduzieren Format-Lock-in. Sie lösen nicht automatisch:

• proprietäre IDs und Semantik,
• Reihenfolgeabhängigkeiten,
• unexportierte Policies,
• fehlende Secrets,
• Marketplace-App-Daten,
• Limits und Paginierung,
• referenzielle Integrität,
• importseitige Einschränkungen.

[INTERPRETATION] Ein offenes Format ist notwendig, aber nicht hinreichend. Entscheidend ist die semantische Portabilität.

2.3 APIs sind laufende Verträge

Eine API ist kein statisches Feature. Sie ist ein veränderlicher technischer Vertrag. Exit-Fähigkeit hängt daher zusätzlich ab von:

• Pinning einer API-Version,
• angekündigtem Sunset,
• Supportfenster,
• maschinenlesbaren Deprecation-Headern,
• zentralem Changelog,
• Migrationsleitfaden,
• Testumgebung,
• Ownership der konsumierenden Integration.

Fehlt diese Steuerung, entsteht Deprecation Debt: Die Organisation weiß, dass eine Oberfläche verschwindet, kann aber Aufwand, Frist und betroffene Prozesse nicht zuverlässig bestimmen.

2.4 Exit Debt als Bilanz technischer Abhängigkeit

Der Report verwendet „Exit Debt“ als operativen Arbeitsbegriff:

Exit Debt =
unbekannte Zustandsklassen
+ ungetestete Exporte
+ proprietäre Logik
+ fehlende Zielimporte
+ veraltete API-Versionen
+ nicht dokumentierte Credentials
+ fehlender Parallelbetriebsplan

Exit Debt ist keine buchhalterische Kennzahl. Sie ist eine Managementmetrik für die Menge ungelöster Arbeit, die erst bei einem Wechsel sichtbar würde.

---

Teil I - Vendor-Lock-in-Risiko

I.1 Forschungsfrage

Wie viel eines produktiven Systems kann ein Unternehmen anhand öffentlich dokumentierter Funktionen mitnehmen, und wie viel muss beim Anbieterwechsel neu aufgebaut werden?

Die Frage bezieht sich auf operative Portabilität. Der Report bewertet nicht, ob ein Anbieter Lock-in absichtlich erzeugt oder ob das Produkt wirtschaftlich sinnvoll ist.

---

I.2 Definitionen

Datenportabilität

Export der fachlichen Datensätze und Anhänge in dokumentierten, weiterverarbeitbaren Formaten.

Logikportabilität

Übertragbarkeit von:

• Workflows
• Formeln
• Automationen
• Datenmodellen
• Regeln
• Dashboards
• Berechtigungslogik
• benutzerdefiniertem Code

Runtime-Portabilität

Möglichkeit, dieselbe oder eine kompatible Laufzeit außerhalb des Anbieters zu betreiben.

Exit-Dokumentation

Öffentliche Beschreibung der Schritte, Grenzen, Formate und Verantwortlichkeiten eines Exports oder Wechsels.

Lock-in

Ein Zustand, in dem Wechselkosten durch technische, organisatorische, vertragliche oder wirtschaftliche Abhängigkeiten steigen. Der Begriff ist in diesem Report wertneutral. Ein höherer Lock-in kann für ein Unternehmen akzeptabel sein, wenn Nutzen, Stabilität und Preis ihn rechtfertigen.

---

I.3 Stichprobe

Untersucht wurden zehn Plattformen aus fünf Funktionsklassen:

Klasse	Produkte
Automation	Zapier, Make, n8n
CRM	HubSpot, Salesforce
Knowledge/Work Management	Notion, Airtable
Business Intelligence	Tableau, Microsoft Power BI
Web Platform	Webflow

Die Auswahl ist kuratiert. Sie deckt verbreitete Geschäftslogik- und Datenplattformen ab, ist aber nicht repräsentativ für den Gesamtmarkt.

---

I.4 Methodik

4.1 Risikodimensionen

Code	Dimension	Gewicht	0 Punkte bedeutet	Maximalpunkte bedeuten
E	Datenexport	20	weitgehend vollständiger, dokumentierter Export	wesentliche Daten nur eingeschränkt übertragbar
O	Offene Formate	15	offene, maschinenlesbare Formate	proprietäre oder verlustreiche Formate
B	Geschäftslogik	25	Logik weitgehend übertragbar	Logik muss großteils neu gebaut werden
A	API und Administration	15	umfassende dokumentierte Schnittstellen	relevante Objekte nicht automatisiert zugänglich
R	Runtime	10	selbst oder kompatibel betreibbar	nur auf Anbieter-Runtime ausführbar
C	Credentials/Integrationen	5	portable Konfiguration	Neuautorisierung und manuelle Rekonstruktion
X	Exit-Dokumentation	10	vollständige öffentliche Exit-Anleitung	Grenzen und Verfahren nur teilweise dokumentiert

Lock-in-Risiko = E + O + B + A + R + C + X
Maximum = 100

4.2 Risikobänder

Punkte	Band
0–24	niedrig
25–49	moderat
50–69	hoch
70–100	sehr hoch

Die Bänder gelten nur für diese Methodik.

4.3 Grundsatz „nicht gefunden“ versus „nicht vorhanden“

Der Report bewertet öffentlich dokumentierte Fähigkeiten. Wurde eine Funktion in der systematischen Recherche nicht gefunden, bedeutet dies nicht automatisch, dass sie technisch oder vertraglich unmöglich ist. Anbieter können zusätzliche Enterprise-Tools, APIs oder Services bereitstellen.

---

I.5 Gesamtergebnis

Rang nach niedrigerem Risiko	Produkt	Risiko / 100	Band
1	n8n	17	Niedrig
2	Make	47	Moderat
3	Microsoft Power BI	52	Hoch
4	Notion	52	Hoch
5	Salesforce	54	Hoch
6	Zapier	56	Hoch
7	Tableau	58	Hoch
8	Airtable	58	Hoch
9	HubSpot	61	Hoch
10	Webflow	63	Hoch

Vollständige Scorematrix

Produkt	E /20	O /15	B /25	A /15	R /10	C /5	X /10	Gesamt
n8n	2	2	5	2	0	4	2	17
Make	5	5	15	5	10	4	3	47
Microsoft Power BI	5	8	17	5	8	4	5	52
Notion	5	4	20	8	10	2	3	52
Salesforce	4	8	18	5	8	4	7	54
Zapier	5	5	20	8	10	5	3	56
Tableau	5	8	18	7	8	5	7	58
Airtable	5	5	22	7	10	4	5	58
HubSpot	5	8	20	8	10	5	5	61
Webflow	8	5	20	10	10	5	5	63

Maschinenlesbare Daten:

data/FDR-2026-02_lockin_risk_scores.csv

---

I.6 Produktanalysen

6.1 n8n – 17 Punkte

[OBSERVED] n8n unterstützt den Export und Import von Workflows als JSON sowie CLI-basierte Verfahren. Die Community Edition kann auf eigener Infrastruktur betrieben werden.

Das reduziert zwei Risiken gleichzeitig:

• Workflow-Definitionen sind exportierbar.
• Die Laufzeit ist nicht ausschließlich an einen fremden SaaS-Betrieb gebunden.

Grenzen bleiben:

• Credentials enthalten sensible Informationen und müssen sicher migriert oder neu angelegt werden.
• Community Nodes und Versionen müssen kompatibel sein.
• Datenbank, Execution-Historie, Secrets, Queues, Binary Data, Webhook-Domains und externe Services benötigen einen eigenen Migrationsplan.
• Selbsthosting überträgt die Betriebsverantwortung auf das Unternehmen.

[INTERPRETATION] Portabilität ist nicht gleich Wartungsfreiheit. n8n schneidet niedrig ab, weil die technische Kontrolle höher ist – nicht, weil ein Exit ohne Arbeit möglich wäre.

6.2 Make – 47 Punkte

Make erlaubt den Export und Import von Szenario-Blueprints. Das ist ein substanzieller Vorteil gegenüber rein visuellen Systemen ohne exportierbare Logik.

Blueprints ersetzen jedoch keine komplette Runtime:

• Verbindungen und Credentials müssen neu autorisiert werden.
• Organisations-, Team- und Governance-Konfigurationen sind nicht vollständig in einem Blueprint enthalten.
• Module sind an Make-Integrationen und deren Semantik gebunden.
• Execution-Historie und operative Betriebsdaten sind nicht dasselbe wie die Szenariodefinition.

[INTERPRETATION] Make bietet Logikportabilität innerhalb des eigenen Ökosystems, aber keine vollständige Runtime-Portabilität.

6.3 Power BI – 52 Punkte

Power BI unterstützt den Export bestimmter Reports als PBIX und entwickelt mit PBIP/TMDL stärker dateibasierte Arbeitsweisen. Datenmodelle, Measures und Berichtselemente können damit teilweise versionierbar werden.

Grenzen hängen vom Artefakt ab:

• nicht jeder Report lässt sich in jeder Konstellation als PBIX exportieren,
• Service-Konfiguration, Gateways, Credentials, Tenant-Policies und Berechtigungen sind nicht vollständig im Reportartefakt enthalten,
• proprietäre Visuals oder Funktionen können die Migration erschweren,
• ein Wechsel zu einem anderen BI-System erfordert semantische Neuimplementierung.

6.4 Notion – 52 Punkte

Notion ermöglicht Workspace-Exporte unter anderem als HTML, Markdown und CSV. Damit können Inhalte grundsätzlich gesichert und weiterverarbeitet werden.

Nicht vollständig portabel sind typischerweise:

• Datenbankverhalten
• Relations und Rollups in identischer Semantik
• Automationen
• Berechtigungsmodell
• Ansichten
• Formeln
• Integrationen
• die interaktive Anwendung als Ganzes

[INTERPRETATION] Notion exportiert Content besser als die komplette Arbeitsumgebung.

6.5 Salesforce – 54 Punkte

Salesforce bietet umfangreiche Datenexport-, API- und Metadata-Funktionen. Die Plattform ist damit dokumentationsseitig leistungsfähig.

Der Wechselaufwand entsteht an anderer Stelle:

• Apex
• Flows
• Managed Packages
• Objektmodell
• Validierungsregeln
• Berechtigungen
• Integrationen
• Berichte und Dashboards
• Datenqualitätsregeln

Viele Artefakte lassen sich extrahieren, aber nicht automatisch in eine andere CRM-Runtime übersetzen.

[INTERPRETATION] Tiefe APIs reduzieren Informationsverlust. Sie reduzieren nicht zwingend den semantischen Wiederaufbau.

6.6 Zapier – 56 Punkte

Zapier unterstützt in Team- und Enterprise-Kontexten den Import und Export von Zap-Workflows als JSON. Zusätzlich können Account-Daten exportiert werden.

Grenzen:

• Zaps bleiben an Zapier-Apps, Trigger und Actions gebunden.
• Credentials werden nicht als frei portables Paket übertragen.
• externe App-Semantik muss im Zielsystem nachgebildet werden.
• Task-Historie und operative Zustände sind nicht gleich Workflow-Definition.
• eine alternative Runtime für denselben Export ist nicht vorgesehen.

6.7 Tableau – 58 Punkte

Tableau-Workbooks können als .twb oder .twbx gespeichert werden. Das ist nützlich für Archivierung und Übergabe innerhalb des Tableau-Ökosystems.

Beim Wechsel auf eine andere BI-Plattform müssen jedoch typischerweise neu gebaut werden:

• berechnete Felder
• Dashboard-Interaktionen
• Datenquellenlogik
• Extrakte
• Berechtigungen
• Server-/Cloud-Konfiguration
• proprietäre Visualisierungssemantik

6.8 Airtable – 58 Punkte

Airtable erlaubt Datenexporte und API-Zugriff. Tabelleninhalte sind relativ zugänglich.

Die Anwendungsschicht ist weniger portabel:

• Interfaces
• Automations
• Formulas
• linked records
• views
• permissions
• extensions
• forms

CSV bildet Daten ab, aber nicht die Datenbankanwendung.

6.9 HubSpot – 61 Punkte

HubSpot dokumentiert Exporte für CRM-Daten und verschiedene Contenttypen. APIs unterstützen zahlreiche Objekte.

Die Rekonstruktion betrifft:

• Workflows
• Lifecycle-Logik
• Scoring
• Lists
• Properties
• Pipelines
• Marketing-Automation
• Formulare
• Tracking
• Berechtigungen
• App-Integrationen

[INTERPRETATION] Ein vollständiger CRM-Datenexport ist nur eine Ebene. Ohne Mapping der Automations- und Prozesslogik ist er kein betriebsbereiter Ersatz.

6.10 Webflow – 63 Punkte

Webflow erlaubt bei geeigneten Plänen den Export von HTML, CSS, JavaScript und Assets. Das ist wertvoll für statische Frontends.

Die Einschränkungen betreffen unter anderem:

• CMS- und Ecommerce-Funktionalität
• Formverarbeitung
• Search
• User-/Membership-Funktionen
• Editor- und Hosting-Dienste
• dynamische Datenlogik
• bestimmte plattformspezifische Komponenten

[INTERPRETATION] Der Codeexport kann die Präsentationsschicht retten, ohne das vollständige Produkt zu portieren.

---

I.7 Der zentrale Befund: Daten sind nicht das System

Ein produktives System besteht aus mindestens sieben Ebenen:

1. Rohdaten
2. Datenmodell
3. Geschäftslogik
4. Integrationen und Credentials
5. Berechtigungen
6. Runtime und Deployment
7. Betriebswissen und Historie

Viele Exit-Checks betrachten nur Ebene 1. Ein belastbarer Exit muss alle sieben Ebenen inventarisieren.

Beispiel CRM

Ein CSV-Export kann enthalten:

• Kontakte
• Unternehmen
• Deals
• Aktivitäten

Er enthält nicht automatisch:

• wann ein Deal erstellt wird,
• welche Felder Pflicht sind,
• wie Leads geroutet werden,
• wann ein SLA eskaliert,
• welche E-Mails ausgelöst werden,
• wie Dubletten behandelt werden,
• welche Rollen was sehen.

Der wirtschaftliche Lock-in sitzt deshalb häufig in unsichtbarer Logik.

---

I.8 Exit Readiness Model

[RECOMMENDATION] Unternehmen sollten für jedes kritische SaaS-System ein Exit-Paket pflegen:

A. Asset Register

• Datenobjekte
• Volumen
• Eigentümer
• Aufbewahrung
• personenbezogene Daten
• Downstream-Abhängigkeiten

B. Logic Register

• Workflows
• Regeln
• Formeln
• Trigger
• Schedules
• Exception Handling
• manuelle Overrides

C. Integration Register

• APIs
• Webhooks
• Credentials
• Rate Limits
• IP-Allowlisting
• Verantwortliche
• Renewal-Termine

D. Runtime Register

• Hosting
• Domains
• Secrets
• Queues
• Worker
• Storage
• Observability
• Backup
• Recovery

E. Exit Test

Mindestens jährlich:

1. repräsentativen Datenexport ausführen,
2. Prüfsummen und Vollständigkeit prüfen,
3. einen kritischen Workflow rekonstruieren,
4. Credentials-Rotation testen,
5. Zeit und Personalaufwand dokumentieren,
6. Abhängigkeiten aktualisieren.

---

I.9 Procurement-Fragen

Vor Vertragsabschluss:

1. Welche Daten sind vollständig exportierbar?
2. In welchen Formaten?
3. Sind Anhänge, Historien und Audit-Logs enthalten?
4. Können Automationen exportiert werden?
5. Ist das Format öffentlich dokumentiert?
6. Gibt es eine alternative Runtime?
7. Welche Objekte fehlen in APIs?
8. Werden Credentials oder nur Referenzen exportiert?
9. Wie lange steht ein Read-only-Zugang nach Kündigung bereit?
10. Welche Gebühren und Fristen gelten für Exit-Unterstützung?
11. Kann ein vollständiger Testexport vor Vertragsabschluss durchgeführt werden?
12. Werden Löschung und Abschlussbestätigung dokumentiert?

---

---

Teil II - Exportvollständigkeit und Reconstitution

II.1 Forschungsfrage

Welche Klassen des operativen Plattformzustands sind bei zehn SaaS-Produkten öffentlich dokumentiert exportierbar, automatisierbar und wiederherstellbar?

Nicht untersucht werden:

• individuelle Enterprise-Exportservices,
• Support-assisted migrations,
• tatsächliche API-Performance und Rate Limits,
• Datenqualität eines konkreten Kundenkontos,
• rechtliche Datenherausgabeansprüche,
• Verschlüsselung und Zugriffsschutz exportierter Dateien,
• vollständige Zielsystemkompatibilität,
• Kosten und Dauer einer Migration.

---

II.2 Export, Backup, Restore und Migration

Begriff	Kontrollziel
Export	Daten oder Konfiguration aus dem System herausbringen
Backup	definierten Zustand zu einem Zeitpunkt gegen Verlust sichern
Restore	Zustand in einer nutzbaren Umgebung wiederherstellen
Migration	Betrieb kontrolliert in eine andere Plattform oder Architektur überführen
Archive	Daten unverändert und langfristig lesbar aufbewahren
Reconstitution	Geschäftsprozess aus Daten, Logik, Berechtigungen und Integrationen erneut funktionsfähig zusammensetzen

Ein Export kann Teil eines Backups sein. Er ist jedoch erst dann als Recovery-Kontrolle belastbar, wenn der Restore getestet wurde.

---

II.3 Methodik

3.1 Stichprobe

Die zehn Produkte decken unterschiedliche Kategorien ab:

• CRM,
• Work Management,
• Knowledge Base,
• Messaging,
• Workflow Automation,
• Website/CMS,
• Enterprise Work Tracking.

Die Auswahl ist gezielt und nicht repräsentativ.

3.2 Quellen

Gewertet wurden offizielle:

• Export- und Backup-Hilfen,
• Entwickler-APIs,
• Metadata-/Deployment-Dokumente,
• Import- und Migration Guides,
• Whole-Account- und Workspace-Exportpfade,
• Data-Act-Einordnung.

3.3 Zustandsklassen

Zustandsklasse	Gewicht	Was ein belastbarer Export abdecken müsste
Core Records	15	zentrale Geschäftsdaten und Inhalte
Attachments / Files	10	Dateien, Medien und Anhänge
Comments / History	10	Kommentare, Versionen oder relevante Historie
Relationships	10	Links, Relationen, Parent-/Child- und Referenzstruktur
Users & Permissions	10	Rollen, Nutzer, Teams und Zugriffsmodell
Automations / Workflows	15	Geschäftslogik, Trigger und Aktionen
Audit Logs	10	nachvollziehbare Aktivitäts- und Änderungsdaten
Metadata / Schema	10	Custom Fields, Objektdefinitionen und Struktur
Machine-readable API	5	API-basierter, automatisierbarer Exportpfad
Restore / Import Path	5	dokumentierter Weg zur Rekonstruktion

3.4 N/A-Normalisierung

Ein Kriterium kann als nicht anwendbar markiert werden, wenn die Plattformfläche diese Zustandsklasse strukturell nicht besitzt. Der Score lautet:

Score
= Summe(Erfüllung × Gewicht)
  / Summe(anwendbare Gewichte)
  × 100

Bewertung:

1,0 = öffentlich weitgehend abgedeckt
0,5 = teilweise, planabhängig oder mit wesentlichen Verlusten
0,0 = nicht hinreichend öffentlich belegt
N/A = für die definierte Produktfläche nicht sinnvoll anwendbar

[CRITICAL] Unterschiedliche Nenner bleiben in der Ergebnistabelle sichtbar. Ein Score ohne anwendbares Gewicht darf nicht zitiert werden.

---

II.4 Ergebnisse

Plattform	Score / 100	anwendbares Gewicht	Einordnung
Salesforce	92.5	100	hohe öffentliche Dokumentationsreife
Atlassian Jira	90.0	100	hohe öffentliche Dokumentationsreife
Asana	80.0	100	solide öffentliche Dokumentationsreife
Zapier	78.1	80	solide öffentliche Dokumentationsreife
HubSpot	75.0	100	solide öffentliche Dokumentationsreife
Slack	72.5	100	solide öffentliche Dokumentationsreife
monday.com	72.5	100	solide öffentliche Dokumentationsreife
Airtable	70.0	100	solide öffentliche Dokumentationsreife
Notion	58.8	85	partielle öffentliche Dokumentationsreife
Webflow	33.3	90	begrenzte öffentliche Dokumentationsreife

Verteilung

• [CALCULATED] Mittelwert: 72,3
• [CALCULATED] Median: 73,8
• [CALCULATED] Spannweite: 33,3 bis 92,5
• [CALCULATED] Sieben Produkte besitzen 100 anwendbare Gewichtspunkte; Zapier 80, Notion 85 und Webflow 90.

Die große Spannweite ist sachlich plausibel: Ein CRM mit Metadata API besitzt andere Portabilitätsflächen als ein gehosteter Website Builder.

---

II.5 Plattformbeobachtungen

Salesforce - 92,5

[OBSERVED] Data Export, Metadata API und Data Loader decken große Teile von Daten, Struktur und Deployment ab.

[LIMITATION] Ein Restore benötigt Reihenfolge, Target Compatibility, IDs, Abhängigkeiten, Berechtigungen und gegebenenfalls produktspezifische Tools. Marketplace-Komponenten und externe Integrationen bleiben eigene Risiken.

Atlassian Jira - 90,0

[OBSERVED] Jira dokumentiert Exporte, Backups, APIs und breite Konfigurationspfade.

[LIMITATION] Marketplace-App-Daten, Instanztypen und Zielversionen können eine exakte Rekonstruktion verhindern. Jira Cloud zu Jira Cloud, Cloud zu Data Center und Drittplattform sind unterschiedliche Migrationen.

Asana - 80,0

[OBSERVED] Projekt- und Taskdaten können exportiert beziehungsweise über APIs gelesen werden.

[LIMITATION] Automationen, Berechtigungen, Auditdaten und das vollständige Team-/Organisationsmodell sind nicht ein einzelnes Reconstitution Bundle.

Zapier - 78,1

[OBSERVED] Workflow-JSON, Accountdaten und Run History sind getrennt exportierbar. Für Zapier wurden nicht relevante Zustandsklassen aus dem Nenner genommen.

[CRITICAL] OAuth Grants, API Keys und Drittanbieter-Credentials dürfen nicht als portable Klartext-Secrets erwartet werden. Sie müssen im Zielsystem neu autorisiert oder aus einem eigenen Secret Store bereitgestellt werden.

HubSpot - 75,0

[OBSERVED] HubSpot bietet umfangreiche Daten- und Content-Exporte sowie CRM APIs.

[LIMITATION] Workflows, Permissions, Audit, Reports, Marketing Assets und Custom Objects bilden keine einzelne, unmittelbar restorable Datei.

Slack - 72,5

[OBSERVED] Workspace-Export kann je Plan und Genehmigung Nachrichten und Dateien abdecken; Importwerkzeuge sind dokumentiert.

[LIMITATION] Private Channels, DMs, Apps, Workflows, Retention, Identity Mapping und Zielplattformsemantik sind getrennt zu behandeln.

monday.com - 72,5

[OBSERVED] Whole-Account-Exporte können Boards und optional Files erfassen.

[LIMITATION] Integrationen, Automationen, Permissions und vollständige Runtime-Rekonstruktion benötigen zusätzliche Arbeit.

Airtable - 70,0

[OBSERVED] CSV und API decken Records und Teile des Schemas ab.

[LIMITATION] Interfaces, Automationen, Berechtigungen, History und externe Integrationen sind nicht vollständig durch Tabellenexporte repräsentiert.

Notion - 58,8

[OBSERVED] HTML-, Markdown-, CSV- und PDF-Exporte erhalten Content und Files in unterschiedlichem Umfang.

[LIMITATION] Relations, Permissions, Comments, Database Behavior und Integrationen können verloren oder semantisch reduziert werden. Notion wurde für eine nicht anwendbare Automationsklasse nicht bestraft.

Webflow - 33,3

[OBSERVED] Webflow bietet Code- und CMS-Exporte.

[LIMITATION] Hosted CMS Runtime, Forms, Memberships, Ecommerce, Search und Plattformkonfiguration werden nicht zu einem vollständig portablen Laufzeitpaket.

[INTERPRETATION] Der Wert zeigt nicht, dass „nur 33 Prozent einer Website“ exportiert werden. Er zeigt, dass viele gewichtete Zustandsklassen der gehosteten Plattform nicht als vollständiger Exit-State öffentlich dokumentiert sind.

---

II.6 Die zehn Zustandsklassen im Detail

Core Records

Erforderlich sind:

• stabile IDs,
• Zeitstempel,
• Status,
• Owner,
• Custom Fields,
• Deleted/Tombstone State,
• vollständige Pagination.

Relationships

Ein Datensatz ohne Beziehungen kann fachlich wertlos sein. Notwendig sind:

• Parent-/Child-Bezüge,
• Many-to-Many-Verknüpfungen,
• Foreign Keys oder Mappingtabellen,
• Referenzintegrität,
• Reihenfolge des Imports.

Users und Permissions

Aus Sicherheitsgründen ist eine direkte Übernahme nicht immer möglich. Trotzdem müssen mindestens Rollenmodell, Gruppen, Ownership und Objektfreigaben inventarisierbar sein.

Automations

Zu sichern sind:

• Trigger,
• Bedingungen,
• Aktionen,
• Zeitpläne,
• Fehlerpfade,
• Abhängigkeiten,
• Version,
• Aktivzustand.

Audit Logs

Auditdaten dienen nicht nur Compliance. Sie helfen bei:

• Delta-Migration,
• Konfliktklärung,
• Post-Exit-Forensik,
• Nachweis der letzten Änderungen.

---

II.7 Reconstitution Drill

Phase 1: Inventory

• Datenklassen und Volumen,
• Schema und Custom Fields,
• Files,
• Beziehungen,
• Nutzer und Rollen,
• Workflows,
• Integrationen,
• Audit und Retention.

Phase 2: Export

• Full Export,
• API Delta Export,
• Hashes und Manifest,
• dokumentierte Fehler,
• Rate Limits und Dauer.

Phase 3: Restore

• isolierte Zielumgebung,
• Importreihenfolge,
• ID Mapping,
• Files und Links,
• Rollen,
• Automationen,
• Stichproben und Reconciliation.

Phase 4: Business Validation

• zentrale Nutzerprozesse,
• Berichte,
• Integrationen,
• Suchbarkeit,
• Berechtigungsgrenzen,
• Auditnachweis.

Reconciliation

Record Completeness
= erfolgreich rekonstruierte Records
/ erwartete Records

Relationship Integrity
= gültige rekonstruierte Beziehungen
/ erwartete Beziehungen

Workflow Parity
= erfolgreich getestete kritische Workflows
/ inventarisierte kritische Workflows

---

II.8 Export Security

Ein Export reduziert Plattformabhängigkeit, erhöht aber temporär das Datenrisiko:

• unverschlüsselte ZIP-Archive,
• lokale Downloads,
• unkontrollierte Admin-Laptops,
• öffentliche Object-Storage-Buckets,
• lange Aufbewahrung,
• fehlende Hashes,
• personenbezogene Daten außerhalb definierter Systeme.

Mindestkontrollen

• Export Service Account,
• MFA und Approval,
• verschlüsseltes Ziel,
• kurzlebige Downloadlinks,
• Hashmanifest,
• Least Privilege,
• Access Log,
• Retention und sichere Löschung,
• DLP/PII-Klassifizierung.

---

II.9 Architekturprinzipien

1. stabile interne IDs statt Provider-ID als alleiniger Schlüssel,
2. Event-/Change-Log für Delta-Rekonstruktion,
3. eigene Kopie kritischer Stammdaten,
4. Secrets außerhalb von SaaS-Workflows,
5. Business Logic nicht ausschließlich in proprietären UI-Flows,
6. regelmäßige maschinenlesbare Exporte,
7. Schema Registry,
8. Import- und Restore-Code im Repository,
9. unabhängige Domains, DNS und Identität,
10. getesteter Degraded-Mode.

---

---

Teil III - API-Deprecation- und Migration-Readiness

III.1 Forschungsfrage

Wie vollständig dokumentieren neun Plattformen die Signale und Werkzeuge, die ein Unternehmen benötigt, um API- und Runtime-Deprecations ohne ungeplanten Produktionsausfall zu bewältigen?

Nicht untersucht werden:

• tatsächliche individuelle Benachrichtigungen an Kunden,
• nicht öffentliche Enterprise-Supportprozesse,
• die historische Häufigkeit aller Breaking Changes,
• die Qualität jedes einzelnen Migrationsdokuments,
• proprietäre interne APIs,
• SDKs und Versionen außerhalb der konkret geprüften Flächen,
• Kausalität zwischen Score und realer Uptime.

---

III.2 Vier Zustände, die Teams häufig vermischen

Zustand	Bedeutung
Deprecated	Nutzung wird nicht mehr empfohlen; Ersatz oder Abschaltung kann folgen
Unsupported	Anbieter oder Projekt verspricht keine reguläre Unterstützung mehr
Sunset / Retired	Endpoint, Version oder Funktion wird abgeschaltet beziehungsweise entfernt
Breaking Change	Bestehendes Verhalten oder Schema ist ohne Anpassung nicht kompatibel

Ein Endpoint kann deprecated, aber noch erreichbar sein. Eine Version kann supported sein, obwohl ein einzelnes Feld bereits ausläuft. Ein SDK kann nicht mehr gepflegt werden, während die zugrunde liegende API weiterläuft.

[RECOMMENDATION] Das interne Register muss den konkreten Gegenstand festhalten: Endpoint, Feld, Auth-Methode, API-Version, SDK-Version, Runtime, Webhook-Version oder Plattformfunktion.

---

III.3 Methodik

3.1 Auswahl

Die Stichprobe deckt verschiedene Governance-Modelle ab:

• datumsbasierte API-Versionen,
• Release- und Minor-Versionen,
• quartalsweise API-Versionen,
• accountgebundene Versionierung,
• Cloud-SDK- und Runtime-Lifecycle,
• changelog-zentrierte Plattformänderungen.

Die Auswahl ist purposive. Sie soll Unterschiede in der Steuerungsarchitektur zeigen, nicht den gesamten API-Markt abbilden.

3.2 Quellen

Gewertet wurden offizielle:

• Versioning- und Support Policies,
• Deprecation- und Sunset-Seiten,
• Changelogs und Release Notes,
• Upgrade- und Migration Guides,
• Runtime- und SDK-Maintenance-Dokumente,
• HTTP- beziehungsweise API-Signale,
• Benachrichtigungs- und Subscription-Hinweise.

3.3 Kriterien

Kriterium	Gewicht	Evidenzsignal
Policy und Begriffe	15	Deprecation, Retirement, Sunset und Support klar definiert
Version Pinning	15	Produktionsnutzung auf eine stabile Version fixierbar
Notice-/Support-Fenster	15	Mindestfrist oder Release-basierter Support nachvollziehbar
Zentraler Changelog	10	Änderungen an einer dauerhaften Stelle auffindbar
Sunset-Datum	10	Enddatum beziehungsweise Abschaltstatus klar sichtbar
Maschinenlesbares Signal	10	Header, Statuscode, Schema oder Feed unterstützt Automatisierung
Migration Guidance	15	Ersatz, Breaking Changes und Migrationsschritte dokumentiert
Benachrichtigungen/Tools	10	Subscriptions, Statushinweise oder Upgrade-Werkzeuge verfügbar

3.4 Score

1,0 = klar und substanziell öffentlich dokumentiert
0,5 = teilweise, produktabhängig oder nicht durchgängig dokumentiert
0,0 = im Prüfpfad nicht hinreichend öffentlich belegt

Der gewichtete Score ist eine Dokumentationsmetrik. Er ist keine Behauptung über technische Überlegenheit.

---

III.4 Ergebnisse

API-/Plattformfläche	Score / 100	Einordnung
GitHub REST API	95.0	hohe öffentliche Dokumentationsreife
Kubernetes API	90.0	hohe öffentliche Dokumentationsreife
Microsoft Graph	90.0	hohe öffentliche Dokumentationsreife
Shopify API	90.0	hohe öffentliche Dokumentationsreife
Twilio Conversations	85.0	hohe öffentliche Dokumentationsreife
Stripe API	77.5	solide öffentliche Dokumentationsreife
Google Maps Platform	75.0	solide öffentliche Dokumentationsreife
AWS SDK & Runtimes	72.5	solide öffentliche Dokumentationsreife
Slack Platform	62.5	partielle öffentliche Dokumentationsreife

Verteilung

• [CALCULATED] Mittelwert: 81,9
• [CALCULATED] Median: 85,0
• [CALCULATED] Spannweite: 62,5 bis 95,0
• [CALCULATED] Fünf von neun Flächen erreichen mindestens 85 Punkte.
• [CALCULATED] Zwei von neun liegen unter 75 Punkten.

Die Werte sind für eine ausgewählte Gruppe reifer Ökosysteme hoch. Das zentrale Defizit ist selten ein fehlender Changelog. Häufiger fehlen einheitliche Fristen, machine-readable Signals oder ein über alle Produktflächen konsistentes Lifecycle-Modell.

---

III.5 Anbieter- und Projektbeobachtungen

GitHub REST API - 95,0

[OBSERVED] GitHub dokumentiert datumsbasierte API-Versionen, einen Supportzeitraum, Breaking Changes und Upgrade-Verhalten. Deprecation- und Sunset-Header sowie definierte HTTP-Reaktionen machen Lifecycle-Signale maschinenlesbar.

[INTERPRETATION] Der Wert entsteht aus der Kombination von menschlicher Dokumentation und automatisierbarer Laufzeit-Evidenz. Ein Team kann nicht nur lesen, dass etwas ausläuft, sondern den Zustand in Requests erkennen.

Kubernetes API - 90,0

[OBSERVED] Kubernetes besitzt eine formale Deprecation Policy, release-basierte Regeln und dokumentierte Migrationspfade. Das API-Lifecycle-Modell ist eng mit Release- und Version-Skew-Policies verbunden.

[LIMITATION] Ein Cluster-Upgrade umfasst mehr als entfernte API-Versionen: Controller, CRDs, Admission Webhooks, Operators und Drittanbieter-Tools können eigene Abhängigkeiten mitbringen.

Microsoft Graph - 90,0

[OBSERVED] Microsoft Graph unterscheidet stabile und Beta-Flächen und dokumentiert Versioning, Retirement und Migration. Für allgemein verfügbare API-Versionen werden öffentliche Lifecycle-Erwartungen beschrieben.

[CRITICAL] Beta-Endpunkte besitzen nicht dieselbe Stabilität wie GA-Flächen. Produktionssysteme dürfen Beta nicht stillschweigend als dauerhaftes Vertragsinterface behandeln.

Shopify API - 90,0

[OBSERVED] Quartalsweise Versionen, eine definierte Supportdauer und dokumentiertes Fall-forward-Verhalten schaffen einen vorhersehbaren Takt.

[INTERPRETATION] Ein fester Takt reduziert Überraschung, erhöht aber die Notwendigkeit eines kontinuierlichen Upgrade-Prozesses. „Vorhersehbar“ bedeutet nicht „wartungsfrei“.

Twilio Conversations - 85,0

[OBSERVED] Lifecycle-Stufen, Supporterwartungen und Migrationshinweise sind öffentlich. Die Signalisierung ist stärker menschenlesbar als durchgängig maschinenlesbar.

[RECOMMENDATION] Twilio-Abhängigkeiten sollten zusätzlich durch synthetische API- und Webhook-Tests überwacht werden, weil Kommunikationspfade besonders ausfallkritisch sind.

Stripe API - 77,5

[OBSERVED] Stripe bietet starkes Version Pinning und Upgrade-Werkzeuge. Versionen können account- beziehungsweise requestbezogen gesteuert werden.

[LIMITATION] Nicht jede Produktänderung lässt sich auf eine einzige universelle Mindestfrist reduzieren. APIs, Events, SDKs und Dashboard-Funktionen besitzen unterschiedliche Änderungsoberflächen.

Google Maps Platform - 75,0

[OBSERVED] Eine zentrale Deprecation-Seite, Migrationshinweise und für erfasste Core Services eine angekündigte Mindestfrist sind vorhanden. Einzelne Bibliotheken und Kanäle können abweichende Bedingungen besitzen.

[CRITICAL] Alpha- und Beta-Kanäle sind nicht wie stabile Produktionskanäle zu behandeln. Die Wahl eines experimentellen Channels ist selbst eine Architekturentscheidung über Änderungsrisiko.

AWS SDKs & Runtimes - 72,5

[OBSERVED] AWS veröffentlicht Maintenance Policies und Runtime-Deprecation-Zeitpläne. Das betrachtete Feld umfasst jedoch viele Services, SDKs und Runtimes und ist deshalb weniger einheitlich als eine einzelne API.

[INTERPRETATION] Bei großen Cloud-Plattformen muss das Lifecycle Register auf Ressourcenebene geführt werden: Lambda Runtime, SDK Major Version, Managed Engine, Betriebssystem-Image und API können getrennte End-of-Support-Termine haben.

Slack Platform - 62,5

[OBSERVED] Slack unterhält einen zentralen Changelog und veröffentlicht konkrete Migration Guides. Weniger klar ist eine einheitliche, plattformweite Policy für Mindestfristen und maschinenlesbare Sunset-Signale.

[RECOMMENDATION] Teams sollten relevante Changelog-Kategorien abonnieren und Slack-Apps regelmäßig gegen aktuelle Scopes, Events und Auth-Anforderungen testen.

---

III.6 Die Kennzahl „Migration Runway“

Ein Anbieter kann zwölf Monate Vorlauf geben und ein Unternehmen trotzdem überrascht werden, wenn die Information erst zehn Tage vor Sunset intern ankommt.

Migration Runway
= Sunset-Datum
- interner Erkennungszeitpunkt

Beispiel:

Anbieter kündigt Sunset an: 01.01.
Intern erkannt:              01.10.
Sunset:                      31.12.

Öffentlicher Vorlauf: 364 Tage
Interner Runway:       91 Tage

[INTERPRETATION] Deprecation Readiness ist deshalb zu mindestens der Hälfte ein internes Informationsproblem.

Ergänzende Kennzahlen

• Detection Latency: Tage zwischen öffentlicher Ankündigung und internem Ticket.
• Inventory Coverage: Anteil externer Dependencies mit Owner und Version.
• Test Coverage: Anteil kritischer API-Verträge mit Contract Tests.
• Migration Lead Time: Zeit vom Ticket bis Produktionsumstellung.
• Sunset Margin: verbleibende Tage nach erfolgreicher Umstellung.
• Unknown Version Rate: Anteil produktiver Calls ohne bekannte Zielversion.

---

III.7 Referenzarchitektur für Deprecation Control

Offizielle Changelogs / Feeds / E-Mails
                    ↓
          Dependency Intelligence
                    ↓
      normalisiertes Lifecycle Register
                    ↓
     Jira/GitHub Issue + Owner + Deadline
                    ↓
 Contract Tests → Staging → Canary → Rollout
                    ↓
    Nachweis: alte Version nicht mehr genutzt

Das Lifecycle Register

dependency_id: "github-rest"
business_process: "release-automation"
owner: "platform-team"
endpoint_or_runtime: "REST API"
pinned_version: "YYYY-MM-DD"
source_of_truth: "official-versioning-url"
deprecation_detected_at: null
sunset_date: null
replacement: null
contract_tests: true
last_tested_at: "YYYY-MM-DD"
criticality: "high"
fallback: "manual-release-runbook"

Detection Sources

• RSS/Atom oder E-Mail-Abonnement,
• Deprecation-/Sunset-HTTP-Header,
• Statuscodes wie 410, bevor sie produktiv auftreten,
• Schema-Diffs,
• SDK-Warnungen,
• Release Notes,
• Runtime Inventory,
• IaC- und Container-Scans,
• synthetische Requests.

[RECOMMENDATION] Ein Changelog-Abonnement ohne Owner und Workflow ist lediglich eine weitere ungelesene Inbox.

---

III.8 Contract Tests statt Hoffnung

Unit Tests prüfen eigene Logik. Contract Tests prüfen die Annahmen an der externen Grenze:

• Feld vorhanden und Typ unverändert,
• Authentifizierung funktioniert,
• Pagination und Limits verhalten sich erwartet,
• Webhook-Signatur und Event-Schema stimmen,
• Fehlercodes werden korrekt behandelt,
• Ersatzversion liefert semantisch gleichwertige Daten,
• Rate Limits und Timeouts bleiben innerhalb des Betriebsbudgets.

Für kritische APIs sollten Tests gegen:

1. aktuell produktive Version,
2. angekündigte Zielversion,
3. kontrollierte Failure Cases

laufen. So wird eine Migration nicht erst nach dem ersten Produktionsfehler sichtbar.

---

---

3. Der FW Delta Reconstitution Drill

3.1 Ziel

Nicht „einen Export erzeugen“, sondern einen kontrollierten fachlichen Mindestbetrieb außerhalb des Ursprungssystems herstellen.

3.2 Ablauf

Phase	Aktivität	Exit-Evidenz
1. Scope	kritische Prozesse, Datenklassen und RTO/RPO festlegen	signierter Scope
2. Inventory	Objekte, Files, Logik, Rollen, Integrationen erfassen	Zustandsregister
3. Export	vollständigen Export/API-Snapshot ziehen	Checksums, Logs, Zeitstempel
4. Validate	Counts, Relations, Nullwerte, Dateien und Historie prüfen	Abweichungsbericht
5. Transform	Zielmodell und Mappings versionieren	reproduzierbare Transformationsjobs
6. Import	isolierte Zielumgebung befüllen	Importprotokoll
7. Rebind	IdP, Webhooks, APIs und Secrets neu verbinden	Integrationsregister
8. Replay	repräsentative Geschäftsereignisse wiederholen	fachliche Testfälle
9. Parallel Run	Alt- und Zielsystem zeitlich begrenzt vergleichen	Differenzreport
10. Sign-off	Restabweichungen, Risiken und Eigentümer bestätigen	Exit-Acceptance

3.3 Mindest-Erfolgskriterien

• mindestens 99,9 Prozent der fachlich relevanten Kerndatensätze verifiziert oder jede Abweichung erklärt;
• alle kritischen Beziehungen referenziell geprüft;
• notwendige Attachments abrufbar;
• Rollen und Berechtigungen im Ziel dokumentiert;
• mindestens ein End-to-End-Prozess erfolgreich;
• RTO und RPO gegen tatsächliche Zeiten geprüft;
• fehlende Funktionen als bewusste Abweichung freigegeben;
• Lösch- und Abschaltplan vorbereitet.

[LIMITATION] 99,9 Prozent ist eine vorgeschlagene operative Schwelle, kein universeller Rechts- oder Industriestandard.

---

4. Architektur- und Vertragskontrollen

4.1 Während der Auswahl

• Export- und API-Dokumentation vor Vertragsabschluss prüfen.
• Musterexporte und Sandbox verlangen.
• Marketplace- und Add-on-Daten separat inventarisieren.
• IdP- und Servicekonto-Abhängigkeiten dokumentieren.
• Rate Limits und Bulk-Endpunkte prüfen.
• Post-Termination-Zugriff vertraglich festhalten.
• Migrationsunterstützung, Fees und Datenlöschung definieren.
• Deprecation- und Breaking-Change-Notice vereinbaren.

4.2 Während des Betriebs

• Daten regelmäßig in kontrollierte Systeme replizieren, wo rechtlich und technisch sinnvoll.
• Konfiguration als Code oder versionierte Exporte halten.
• Credentials in eigener Secret-Verwaltung kontrollieren.
• Webhooks und Integrationen zentral inventarisieren.
• API-Versionen und Sunset-Termine überwachen.
• Restore nicht nur dokumentieren, sondern testen.
• den Exit Owner benennen und mit Budget ausstatten.

4.3 Vor Renewal

• Export-Drill spätestens T−150 Tage.
• kritische API-Deprecations und SDK-EOLs prüfen.
• Zielsysteme und Transformationen aktualisieren.
• Parallellaufzeit und Daten-Dual-Write bewerten.
• tatsächliche Migrationskosten als Verhandlungs-BATNA dokumentieren.

---

5. Visualisierungsspezifikation

Chart 1 - Lock-in-Risiko nach Plattform

• Daten: FDR-2026-02_lockin_risk_scores.csv
• X: Risiko 0–100
• Hinweis: höher = mehr modelliertes Risiko

Chart 2 - Exportvollständigkeit nach Zustandsklasse

• Daten: FDR-2026-02_export_completeness_long.csv
• Typ: Heatmap
• Zeilen: Plattform
• Spalten: Zustandsklasse
• Werte: 0 / 0,5 / 1
• Legende sichtbar

Chart 3 - Risiko vs. Exportvollständigkeit

• Daten: FDR-2026-02_exit_readiness_composite_shared_sample.csv
• X: Lock-in-Risiko
• Y: Exportvollständigkeit
• Label: Anbieter
• keine Trendlinie bei n=6

Chart 4 - API-Migration-Runway

• Daten: FDR-2026-02_api_deprecation_readiness.csv
• Darstellung: Score plus dokumentierte Notice-/Supportdimensionen

Chart 5 - Reconstitution Chain

Export → Validate → Transform → Import → Rebind → Replay → Sign-off

Konzeptionelle Grafik, keine Messreihe.

---

6. Reproduzierbarkeit

Datendateien

• data/FDR-2026-02_lockin_risk_scores.csv
• data/FDR-2026-02_export_completeness_scores.csv
• data/FDR-2026-02_export_completeness_long.csv
• data/FDR-2026-02_api_deprecation_readiness.csv
• data/FDR-2026-02_exit_readiness_composite_shared_sample.csv

Wiederholungsprotokoll

1. Nur offizielle Export-, Backup-, API-, Versioning-, Migration- und Terms-Dokumente als Score-Evidenz verwenden.
2. Produktplan, Region und Administrationsrolle dokumentieren.
3. Jede Zustandsklasse separat bewerten.
4. Ein Feature nicht als exportierbar zählen, wenn nur ein Screenshot oder manueller Copy-Paste-Weg existiert.
5. API-Zugriff nicht mit Bulk-Export oder Restore gleichsetzen.
6. Deprecation-Readiness nur bei dokumentierter, auffindbarer Evidenz bewerten.
7. Gemeinsame Komposits nur für echte Stichprobenüberschneidungen berechnen.
8. Reale Drills getrennt von Dokumentationsscores veröffentlichen.

---

7. Grenzen

1. Die Scores messen öffentliche Dokumentation, nicht garantiertes Vertragsrecht.
2. Enterprise-Pläne können zusätzliche Export- und Supportfunktionen enthalten.
3. Kein vollständiger realer Exit wurde für jede Plattform durchgeführt.
4. Ein niedriger Lock-in-Risikoscore beweist keinen günstigen Wechsel.
5. Ein hoher Exportscore beweist keine semantisch identische Zielanwendung.
6. API-Policies können produkt- oder versionsspezifisch variieren.
7. Marketplace-Apps und Drittanbieterintegrationen sind nur teilweise sichtbar.
8. Credentials sind aus guten Sicherheitsgründen häufig nicht exportierbar; das erhöht operative Arbeit, nicht zwingend negatives Produktverhalten.
9. Scores enthalten redaktionelles Ermessen trotz offener Kriterien.
10. Rechtliche Portabilitätsansprüche werden nicht ausgelegt.

---

8. Zitierhinweise

Zulässig:

„FW Delta unterscheidet Datenexport, Restore und Reconstitution. In der untersuchten Plattformstichprobe waren Kerndaten häufiger dokumentiert exportierbar als Automationen, Berechtigungen und Audit-Zustand.“

Nicht zulässig:

„Kein SaaS-Anbieter ermöglicht einen vollständigen Export.“

Zulässig:

„Der gemeinsame Sechs-Anbieter-Komposit lag zwischen 35,5 und 64,6 Punkten und gilt nur für die Überschneidung zweier transparenter FW-Delta-Module.“

Nicht zulässig:

„Salesforce ist zu 64,6 Prozent portabel.“

---

9. Versionshistorie

• 1.0 · Juli 2026 · Drei Portabilitätsmodule konsolidiert; gemeinsamer Sechs-Anbieter-Komposit; Reconstitution Drill und Exit-Debt-Modell ergänzt.
• Live-Version offen · Vor Veröffentlichung alle API-Versionen, Exportpfade und Help-Center-Seiten erneut prüfen.

---

10. Quellen

1. Zapier Help, „Import and export Zap workflows in your Team or Enterprise account“, https://help.zapier.com/hc/en-us/articles/8496308481933-Import-and-export-Zap-workflows-in-your-Team-or-Enterprise-account, abgerufen im Juli 2026.
2. Zapier Help, „Export your Zapier account data“, https://help.zapier.com/hc/en-us/articles/8496304855565-Export-your-Zapier-account-data, abgerufen im Juli 2026.
3. Make Help Center, „Blueprints“, https://help.make.com/blueprints, abgerufen im Juli 2026.
4. Make Developer Hub, https://developers.make.com/, abgerufen im Juli 2026.
5. n8n Docs, „Export and import workflows“, https://docs.n8n.io/workflows/export-import/, abgerufen im Juli 2026.
6. n8n Docs, „CLI commands“, https://docs.n8n.io/hosting/cli-commands/, abgerufen im Juli 2026.
7. HubSpot Knowledge Base, „Export your content and data“, https://knowledge.hubspot.com/account-management/export-your-content-and-data, abgerufen im Juli 2026.
8. HubSpot Developers, „CRM API“, https://developers.hubspot.com/docs/api/crm/understanding-the-crm, abgerufen im Juli 2026.
9. Salesforce Help, „Export backup data from Salesforce“, https://help.salesforce.com/s/articleView?id=000383962&type=1, abgerufen im Juli 2026.
10. Salesforce Developers, „Metadata API“, https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_intro.htm, abgerufen im Juli 2026.
11. Notion Help, „Export your content“, https://www.notion.com/help/export-your-content, abgerufen im Juli 2026.
12. Notion Developers, „Introduction“, https://developers.notion.com/docs/getting-started, abgerufen im Juli 2026.
13. Airtable Support, „Exporting data from Airtable“, https://support.airtable.com/docs/exporting-data-from-airtable, abgerufen im Juli 2026.
14. Airtable Web API, https://airtable.com/developers/web/api/introduction, abgerufen im Juli 2026.
15. Webflow Help, „How do I export my Webflow site code?“, https://help.webflow.com/hc/en-us/articles/33961386739347-How-do-I-export-my-Webflow-site-code, abgerufen im Juli 2026.
16. Webflow Developers, „Webflow APIs“, https://developers.webflow.com/, abgerufen im Juli 2026.
17. Tableau Help, „Save workbooks“, https://help.tableau.com/current/pro/desktop/en-us/save_savework_packagedworkbooks.htm, abgerufen im Juli 2026.
18. Tableau, „REST API“, https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api.htm, abgerufen im Juli 2026.
19. Microsoft Learn, „Download a report from the Power BI service to Power BI Desktop“, https://learn.microsoft.com/en-us/power-bi/create-reports/service-export-to-pbix, abgerufen im Juli 2026.
20. Microsoft Learn, „Power BI Desktop project“, https://learn.microsoft.com/en-us/power-bi/developer/projects/projects-overview, abgerufen im Juli 2026.
21. Salesforce Developers, Data Loader, https://developer.salesforce.com/tools/data-loader, abgerufen im Juli 2026.
22. Zapier Help, Export account data, https://help.zapier.com/hc/en-us/articles/8496289406349-Export-or-delete-your-Zapier-account-data, abgerufen im Juli 2026.
23. Zapier Help, Export run history, https://help.zapier.com/hc/en-us/articles/8496294549005-Export-your-Zap-history, abgerufen im Juli 2026.
24. Slack Help, Export workspace data, https://slack.com/help/articles/201658943-Export-your-workspace-data, abgerufen im Juli 2026.
25. Slack Help, Import data, https://slack.com/help/articles/204897248-Guide-to-Slack-import-and-export-tools, abgerufen im Juli 2026.
26. Asana Guide, Export your project, https://help.asana.com/s/article/export-your-project, abgerufen im Juli 2026.
27. Asana Developers, API reference, https://developers.asana.com/reference/rest-api-reference, abgerufen im Juli 2026.
28. monday.com Support, Export entire account, https://support.monday.com/hc/en-us/articles/360002543719-How-to-export-your-entire-account-s-data, abgerufen im Juli 2026.
29. monday.com Developers, GraphQL API, https://developer.monday.com/api-reference/docs, abgerufen im Juli 2026.
30. Webflow Help, Export CMS collections, https://help.webflow.com/hc/en-us/articles/33961367030547-Export-collection-content, abgerufen im Juli 2026.
31. Atlassian Support, Export Jira Cloud data, https://support.atlassian.com/jira-cloud-administration/docs/export-issues/, abgerufen im Juli 2026.
32. Atlassian Developers, Jira Cloud REST API, https://developer.atlassian.com/cloud/jira/platform/rest/v3/intro/, abgerufen im Juli 2026.
33. European Commission, Data Act explained, https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained, abgerufen im Juli 2026.
34. Google Maps Platform, Deprecations, https://developers.google.com/maps/deprecations, abgerufen im Juli 2026.
35. Microsoft Graph, Versioning and support, https://learn.microsoft.com/en-us/graph/versioning-and-support, abgerufen im Juli 2026.
36. Microsoft Graph, Changelog, https://developer.microsoft.com/en-us/graph/changelog, abgerufen im Juli 2026.
37. GitHub Docs, REST API versions, https://docs.github.com/en/rest/about-the-rest-api/api-versions, abgerufen im Juli 2026.
38. GitHub Docs, Breaking changes, https://docs.github.com/en/rest/overview/breaking-changes, abgerufen im Juli 2026.
39. Kubernetes, Deprecation policy, https://kubernetes.io/docs/reference/using-api/deprecation-policy/, abgerufen im Juli 2026.
40. Kubernetes, Deprecated API migration guide, https://kubernetes.io/docs/reference/using-api/deprecation-guide/, abgerufen im Juli 2026.
41. Stripe Docs, API versioning, https://docs.stripe.com/api/versioning, abgerufen im Juli 2026.
42. Stripe Docs, Upgrade your API version, https://docs.stripe.com/upgrades, abgerufen im Juli 2026.
43. Stripe Docs, SDK versioning, https://docs.stripe.com/sdks/versioning, abgerufen im Juli 2026.
44. Shopify Dev, API versioning, https://shopify.dev/docs/api/usage/versioning, abgerufen im Juli 2026.
45. Shopify Dev, Developer changelog, https://shopify.dev/changelog, abgerufen im Juli 2026.
46. Slack Developer Docs, Changelog, https://docs.slack.dev/changelog/, abgerufen im Juli 2026.
47. Slack Developer Docs, API deprecations, https://docs.slack.dev/changelog/category/deprecation/, abgerufen im Juli 2026.
48. AWS, SDKs and Tools maintenance policy, https://docs.aws.amazon.com/sdkref/latest/guide/maint-policy.html, abgerufen im Juli 2026.
49. AWS Lambda, Runtime deprecation policy, https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html, abgerufen im Juli 2026.
50. Twilio, Versioning and support lifecycle, https://www.twilio.com/docs/conversations-classic/versioning-and-support-lifecycle, abgerufen im Juli 2026.
51. IETF RFC 8594, The Sunset HTTP Header Field, https://www.rfc-editor.org/rfc/rfc8594, abgerufen im Juli 2026.
52. IETF RFC 9745, The Deprecation HTTP Response Header Field, https://www.rfc-editor.org/rfc/rfc9745, abgerufen im Juli 2026.

---

Disclosure und Haftungsausschluss

FW Delta entwickelt selbst kontrollierte Software- und Dateninfrastrukturen und kann wirtschaftlich von Migrations- und Exit-Projekten profitieren. Kriterien, Quellen, Scores und Grenzen werden offengelegt, um diese Perspektive prüfbar zu machen.

Der Report ist keine Rechts- oder Vertragsberatung. Ein dokumentierter technischer Weg ersetzt weder individuelle Vertragsprüfung noch Datenschutz-, Aufbewahrungs- oder Löschpflichten.