Vendor Lock-in & Exit Readiness Index 2026

Executive Summary

Vendor lock-in is frequently reduced to two questions that are too narrow: “Can I export my data?” and “Is there an API?”. Both questions matter, but they are insufficient. A productive system consists of several state classes that have to be restored together:

Business data
+ Relationships
+ Files
+ Identities
+ Permissions
+ Configuration
+ Automations and rules
+ Integrations and credentials
+ Audit and history data
+ Runtime and deployment knowledge

In addition, the integration surface changes during ongoing operation. APIs are versioned, fields deprecated, endpoints retired and SDKs taken out of support. A static export can therefore exist while operational exit capability nevertheless stays low.

This report combines three modules:

1. Lock-in risk: How portable are data, business logic, runtime, integrations and operations?
2. Export completeness: Which state classes are publicly exportable, and is there a realistic reconstitution path?
3. API deprecation readiness: How early and how machine-readably can teams detect breaking changes and migrate?

Citable key findings

1. [CALCULATED] The lock-in risk score of the ten-platform sample ranges from 17 to 63 points; the median is 55.
2. [CALCULATED] The export completeness module reaches a mean of 72.3 and a median of 73.8 points.
3. [CALCULATED] The nine API ecosystems examined reach a mean of 81.9 points in the deprecation readiness module; the median is 85.0.
4. [CALCULATED] In the shared six-vendor composite, exit readiness ranges from 35.5 to 64.6 points.
5. [OBSERVED] In the sample, core data is more frequently exportable than permissions, automations, audit state and runnable configuration.
6. [INTERPRETATION] An API reduces lock-in only if its version, authentication, limits, deprecation signals and export coverage are operationalized.
7. [INTERPRETATION] “CSV available” is a data access signal, not evidence of a backup and not evidence of a tested restore.
8. [RECOMMENDATION] Critical platforms should run a reconstitution drill at least annually: export, new target, import, integrity check and documented residual deviation.

Shared exit composite of the six overlaps

The following FW Delta composite combines the inverted lock-in risk score at 60 percent with export completeness at 40 percent. The weighting is a transparent methodological decision, not an external standard.

Rank	Vendor	Lock-in risk	Portability value	Export completeness	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] Only six vendors appear in both samples. The composite must not be transferred to other products or interpreted as market share.

---

1. Research design

1.1 Research question

Can a company leave a critical SaaS system within a plannable timeframe and reconstruct its operational business state on a different runtime?

The question is stricter than “Can an export be downloaded?”. In this research model an exit only counts as technically robust once the following chain is documented:

Inventory
→ Export
→ Integrity check
→ Transformation
→ Import
→ Reconstruction of logic and permissions
→ Rebinding of integrations
→ Parallel operation
→ business sign-off
→ Shutdown and deletion confirmation

1.2 Three modules, three denominators

Module	Scoring direction	Sample	Core file
Lock-in risk	higher = more risk	10	data/FDR-2026-02_lockin_risk_scores.csv
Export completeness	higher = more documented state coverage	10	data/FDR-2026-02_export_completeness_scores.csv
API deprecation readiness	higher = better lifecycle control	9	data/FDR-2026-02_api_deprecation_readiness.csv

The modules have different samples and may only be combined for the explicit intersection.

1.3 Eight lock-in layers

1. Data model: tables, objects, relations, IDs and history
2. Files: attachments, media, exports, external storage
3. Identity: users, groups, service accounts, SSO mapping
4. Permissions: roles, policies, grants, sharing
5. Business logic: workflows, formulas, rules, triggers, views
6. Integrations: webhooks, apps, API connections, secrets
7. Runtime: hosting, scheduler, queues, proprietary services
8. Operational knowledge: runbooks, monitoring, ownership, restore sequence

1.4 Statement classes

The labels [OBSERVED], [CALCULATED], [SCENARIO], [INTERPRETATION], [RECOMMENDATION] and [LIMITATION] apply to the entire report.

---

2. Synthesis: data is not the operational state

2.1 Exportable is not reconstructable

A dataset can be exported completely and still not produce the same process. Example:

CRM contacts present
≠
Lifecycle stages, routing rules, scoring, automations,
permissions, consent history and integrations reconstructed

The report therefore separates four levels:

Level	Evidence
Access	data can be viewed or read via API
Export	data can be stored outside the system
Restore	state can be loaded back into the same or a compatible system
Reconstitution	business operation can be restored on a different runtime with documented deviations

2.2 Open formats solve only one part

CSV, JSON, XML, SQL dumps or open telemetry formats reduce format lock-in. They do not automatically solve:

• proprietary IDs and semantics,
• ordering dependencies,
• unexported policies,
• missing secrets,
• marketplace app data,
• limits and pagination,
• referential integrity,
• import-side restrictions.

[INTERPRETATION] An open format is necessary but not sufficient. What is decisive is semantic portability.

2.3 APIs are ongoing contracts

An API is not a static feature. It is a changeable technical contract. Exit capability therefore additionally depends on:

• pinning an API version,
• an announced sunset,
• a support window,
• machine-readable deprecation headers,
• a central changelog,
• a migration guide,
• a test environment,
• ownership of the consuming integration.

Where this control is missing, deprecation debt arises: the organization knows that a surface is disappearing but cannot reliably determine effort, deadline and affected processes.

2.4 Exit debt as a balance sheet of technical dependency

The report uses “exit debt” as an operational working term:

Exit Debt =
unknown state classes
+ untested exports
+ proprietary logic
+ missing target imports
+ outdated API versions
+ credentials that are not documented
+ missing parallel operation plan

Exit debt is not an accounting figure. It is a management metric for the amount of unresolved work that would only become visible in a switch.

---

Part I - Vendor lock-in risk

I.1 Research question

How much of a productive system can a company take with it on the basis of publicly documented features, and how much has to be rebuilt when switching vendors?

The question concerns operational portability. The report does not assess whether a vendor creates lock-in deliberately or whether the product makes economic sense.

---

I.2 Definitions

Data portability

Export of the business records and attachments in documented formats that can be processed further.

Logic portability

Transferability of:

• workflows
• formulas
• automations
• data models
• rules
• dashboards
• permission logic
• custom code

Runtime portability

The ability to run the same or a compatible runtime outside the vendor.

Exit documentation

Public description of the steps, limits, formats and responsibilities of an export or a switch.

Lock-in

A state in which switching costs rise through technical, organizational, contractual or economic dependencies. The term is value-neutral in this report. Higher lock-in can be acceptable for a company if benefit, stability and price justify it.

---

I.3 Sample

Ten platforms from five functional classes were examined:

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

The selection is curated. It covers widely used business logic and data platforms but is not representative of the overall market.

---

I.4 Methodology

4.1 Risk dimensions

Code	Dimension	Weight	0 points means	Maximum points mean
E	Data export	20	largely complete, documented export	essential data transferable only with restrictions
O	Open formats	15	open, machine-readable formats	proprietary or lossy formats
B	Business logic	25	logic largely transferable	logic has to be rebuilt for the most part
A	API and administration	15	comprehensive documented interfaces	relevant objects not accessible in an automated way
R	Runtime	10	can be run self-hosted or compatibly	executable only on the vendor runtime
C	Credentials/integrations	5	portable configuration	reauthorization and manual reconstruction
X	Exit documentation	10	complete public exit guide	limits and procedures only partly documented

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

4.2 Risk bands

Points	Band
0–24	low
25–49	moderate
50–69	high
70–100	very high

The bands apply only to this methodology.

4.3 The principle of “not found” versus “not present”

The report assesses publicly documented capabilities. If a feature was not found in the systematic research, this does not automatically mean that it is technically or contractually impossible. Vendors may provide additional enterprise tools, APIs or services.

---

I.5 Overall result

Rank by lower risk	Product	Risk / 100	Band
1	n8n	17	Low
2	Make	47	Moderate
3	Microsoft Power BI	52	High
4	Notion	52	High
5	Salesforce	54	High
6	Zapier	56	High
7	Tableau	58	High
8	Airtable	58	High
9	HubSpot	61	High
10	Webflow	63	High

Complete score matrix

Product	E /20	O /15	B /25	A /15	R /10	C /5	X /10	Total
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

Machine-readable data:

data/FDR-2026-02_lockin_risk_scores.csv

---

I.6 Product analyses

6.1 n8n – 17 points

[OBSERVED] n8n supports the export and import of workflows as JSON as well as CLI-based procedures. The Community Edition can be operated on the company’s own infrastructure.

That reduces two risks at once:

• Workflow definitions are exportable.
• The runtime is not tied exclusively to a third-party SaaS operation.

Limits remain:

• Credentials contain sensitive information and have to be migrated securely or created anew.
• Community nodes and versions have to be compatible.
• Database, execution history, secrets, queues, binary data, webhook domains and external services need their own migration plan.
• Self-hosting transfers operational responsibility to the company.

[INTERPRETATION] Portability is not the same as freedom from maintenance. n8n scores low because technical control is higher – not because an exit would be possible without work.

6.2 Make – 47 points

Make allows the export and import of scenario blueprints. That is a substantial advantage over purely visual systems without exportable logic.

Blueprints do not, however, replace a complete runtime:

• Connections and credentials have to be reauthorized.
• Organization, team and governance configurations are not contained in a blueprint in full.
• Modules are tied to Make integrations and their semantics.
• Execution history and operational data are not the same as the scenario definition.

[INTERPRETATION] Make offers logic portability within its own ecosystem, but not full runtime portability.

6.3 Power BI – 52 points

Power BI supports the export of certain reports as PBIX and, with PBIP/TMDL, is developing more strongly file-based ways of working. Data models, measures and report elements can thereby become partly versionable.

Limits depend on the artifact:

• not every report can be exported as PBIX in every constellation,
• service configuration, gateways, credentials, tenant policies and permissions are not contained in the report artifact in full,
• proprietary visuals or functions can complicate the migration,
• a switch to a different BI system requires semantic reimplementation.

6.4 Notion – 52 points

Notion enables workspace exports as HTML, Markdown and CSV among other formats. Content can thereby be secured and processed further in principle.

Typically not fully portable are:

• database behavior
• relations and rollups in identical semantics
• automations
• permission model
• views
• formulas
• integrations
• the interactive application as a whole

[INTERPRETATION] Notion exports content better than the complete working environment.

6.5 Salesforce – 54 points

Salesforce offers extensive data export, API and metadata capabilities. In documentation terms the platform is therefore powerful.

The switching effort arises elsewhere:

• Apex
• Flows
• Managed Packages
• object model
• validation rules
• permissions
• integrations
• reports and dashboards
• data quality rules

Many artifacts can be extracted but not translated automatically into a different CRM runtime.

[INTERPRETATION] Deep APIs reduce information loss. They do not necessarily reduce the semantic rebuild.

6.6 Zapier – 56 points

Zapier supports the import and export of Zap workflows as JSON in Team and Enterprise contexts. Account data can be exported in addition.

Limits:

• Zaps remain tied to Zapier apps, triggers and actions.
• Credentials are not transferred as a freely portable package.
• external app semantics have to be recreated in the target system.
• Task history and operational states are not the same as the workflow definition.
• an alternative runtime for the same export is not provided for.

6.7 Tableau – 58 points

Tableau workbooks can be saved as .twb or .twbx. That is useful for archiving and handover within the Tableau ecosystem.

When switching to a different BI platform, the following typically have to be rebuilt:

• calculated fields
• dashboard interactions
• data source logic
• extracts
• permissions
• server/cloud configuration
• proprietary visualization semantics

6.8 Airtable – 58 points

Airtable allows data exports and API access. Table contents are relatively accessible.

The application layer is less portable:

• interfaces
• automations
• formulas
• linked records
• views
• permissions
• extensions
• forms

CSV represents data, but not the database application.

6.9 HubSpot – 61 points

HubSpot documents exports for CRM data and various content types. APIs support numerous objects.

The reconstruction concerns:

• workflows
• lifecycle logic
• scoring
• lists
• properties
• pipelines
• marketing automation
• forms
• tracking
• permissions
• app integrations

[INTERPRETATION] A complete CRM data export is only one layer. Without a mapping of the automation and process logic it is not an operational replacement.

6.10 Webflow – 63 points

Webflow allows the export of HTML, CSS, JavaScript and assets on suitable plans. That is valuable for static frontends.

The restrictions concern, among other things:

• CMS and ecommerce functionality
• form processing
• search
• user/membership features
• editor and hosting services
• dynamic data logic
• certain platform-specific components

[INTERPRETATION] The code export can save the presentation layer without porting the complete product.

---

I.7 The central finding: data is not the system

A productive system consists of at least seven layers:

1. Raw data
2. Data model
3. Business logic
4. Integrations and credentials
5. Permissions
6. Runtime and deployment
7. Operational knowledge and history

Many exit checks look at layer 1 only. A robust exit has to inventory all seven layers.

CRM example

A CSV export can contain:

• contacts
• companies
• deals
• activities

It does not automatically contain:

• when a deal is created,
• which fields are mandatory,
• how leads are routed,
• when an SLA escalates,
• which emails are triggered,
• how duplicates are handled,
• which roles see what.

Economic lock-in therefore often sits in invisible logic.

---

I.8 Exit Readiness Model

[RECOMMENDATION] Companies should maintain an exit package for every critical SaaS system:

A. Asset Register

• data objects
• volume
• owner
• retention
• personal data
• downstream dependencies

B. Logic Register

• workflows
• rules
• formulas
• triggers
• schedules
• exception handling
• manual overrides

C. Integration Register

• APIs
• webhooks
• credentials
• rate limits
• IP allowlisting
• responsible owners
• renewal dates

D. Runtime Register

• hosting
• domains
• secrets
• queues
• workers
• storage
• observability
• backup
• recovery

E. Exit Test

At least annually:

1. run a representative data export,
2. check checksums and completeness,
3. reconstruct one critical workflow,
4. test credential rotation,
5. document time and staff effort,
6. update dependencies.

---

I.9 Procurement questions

Before signing a contract:

1. Which data is fully exportable?
2. In which formats?
3. Are attachments, histories and audit logs included?
4. Can automations be exported?
5. Is the format publicly documented?
6. Is there an alternative runtime?
7. Which objects are missing from APIs?
8. Are credentials exported, or only references?
9. How long is read-only access available after termination?
10. Which fees and deadlines apply to exit support?
11. Can a complete test export be carried out before signing?
12. Are deletion and final confirmation documented?

---

---

Part II - Export completeness and reconstitution

II.1 Research question

Which classes of operational platform state are publicly documented as exportable, automatable and restorable across ten SaaS products?

Not examined are:

• individual enterprise export services,
• support-assisted migrations,
• actual API performance and rate limits,
• data quality of a specific customer account,
• legal data disclosure claims,
• encryption and access protection of exported files,
• full target system compatibility,
• cost and duration of a migration.

---

II.2 Export, backup, restore and migration

Term	Control objective
Export	move data or configuration out of the system
Backup	secure a defined state at a point in time against loss
Restore	restore state in a usable environment
Migration	transfer operations to another platform or architecture in a controlled way
Archive	keep data unchanged and readable in the long term
Reconstitution	reassemble a business process from data, logic, permissions and integrations into a working whole

An export can be part of a backup. It only becomes robust as a recovery control, however, once the restore has been tested.

---

II.3 Methodology

3.1 Sample

The ten products cover different categories:

• CRM,
• work management,
• knowledge base,
• messaging,
• workflow automation,
• website/CMS,
• enterprise work tracking.

The selection is deliberate and not representative.

3.2 Sources

Official documents were scored:

• export and backup help pages,
• developer APIs,
• metadata and deployment documents,
• import and migration guides,
• whole-account and workspace export paths,
• Data Act classification.

3.3 State classes

State class	Weight	What a robust export would have to cover
Core Records	15	central business data and content
Attachments / Files	10	files, media and attachments
Comments / History	10	comments, versions or relevant history
Relationships	10	links, relations, parent/child and reference structure
Users & Permissions	10	roles, users, teams and access model
Automations / Workflows	15	business logic, triggers and actions
Audit Logs	10	traceable activity and change data
Metadata / Schema	10	custom fields, object definitions and structure
Machine-readable API	5	API-based, automatable export path
Restore / Import Path	5	documented route to reconstruction

3.4 N/A normalization

A criterion can be marked as not applicable if the platform surface structurally does not have this state class. The score is:

Score
= sum(fulfillment × weight)
  / sum(applicable weights)
  × 100

Scoring:

1.0 = largely covered publicly
0.5 = partial, plan-dependent or with substantial losses
0.0 = not sufficiently evidenced publicly
N/A = not meaningfully applicable to the defined product surface

[CRITICAL] Different denominators remain visible in the results table. A score without an applicable weight must not be cited.

---

II.4 Results

Platform	Score / 100	applicable weight	Classification
Salesforce	92.5	100	high public documentation maturity
Atlassian Jira	90.0	100	high public documentation maturity
Asana	80.0	100	solid public documentation maturity
Zapier	78.1	80	solid public documentation maturity
HubSpot	75.0	100	solid public documentation maturity
Slack	72.5	100	solid public documentation maturity
monday.com	72.5	100	solid public documentation maturity
Airtable	70.0	100	solid public documentation maturity
Notion	58.8	85	partial public documentation maturity
Webflow	33.3	90	limited public documentation maturity

Distribution

• [CALCULATED] Mean: 72.3
• [CALCULATED] Median: 73.8
• [CALCULATED] Range: 33.3 to 92.5
• [CALCULATED] Seven products have 100 applicable weight points; Zapier 80, Notion 85 and Webflow 90.

The wide range is factually plausible: a CRM with a Metadata API has different portability surfaces than a hosted website builder.

---

II.5 Platform observations

Salesforce - 92.5

[OBSERVED] Data Export, Metadata API and Data Loader cover large parts of data, structure and deployment.

[LIMITATION] A restore requires ordering, target compatibility, IDs, dependencies, permissions and, where applicable, product-specific tools. Marketplace components and external integrations remain risks of their own.

Atlassian Jira - 90.0

[OBSERVED] Jira documents exports, backups, APIs and broad configuration paths.

[LIMITATION] Marketplace app data, instance types and target versions can prevent an exact reconstruction. Jira Cloud to Jira Cloud, Cloud to Data Center and third-party platform are different migrations.

Asana - 80.0

[OBSERVED] Project and task data can be exported or read via APIs.

[LIMITATION] Automations, permissions, audit data and the complete team and organization model are not a single reconstitution bundle.

Zapier - 78.1

[OBSERVED] Workflow JSON, account data and run history are exportable separately. For Zapier, state classes that are not relevant were removed from the denominator.

[CRITICAL] OAuth grants, API keys and third-party credentials must not be expected as portable plaintext secrets. They have to be reauthorized in the target system or provided from a dedicated secret store.

HubSpot - 75.0

[OBSERVED] HubSpot offers extensive data and content exports as well as CRM APIs.

[LIMITATION] Workflows, permissions, audit, reports, marketing assets and custom objects do not form a single, directly restorable file.

Slack - 72.5

[OBSERVED] Depending on plan and approval, the workspace export can cover messages and files; import tools are documented.

[LIMITATION] Private channels, DMs, apps, workflows, retention, identity mapping and target platform semantics have to be handled separately.

monday.com - 72.5

[OBSERVED] Whole-account exports can capture boards and optionally files.

[LIMITATION] Integrations, automations, permissions and a full runtime reconstruction require additional work.

Airtable - 70.0

[OBSERVED] CSV and API cover records and parts of the schema.

[LIMITATION] Interfaces, automations, permissions, history and external integrations are not fully represented by table exports.

Notion - 58.8

[OBSERVED] HTML, Markdown, CSV and PDF exports preserve content and files to varying degrees.

[LIMITATION] Relations, permissions, comments, database behavior and integrations can be lost or semantically reduced. Notion was not penalized for an automation class that is not applicable.

Webflow - 33.3

[OBSERVED] Webflow offers code and CMS exports.

[LIMITATION] Hosted CMS runtime, forms, memberships, ecommerce, search and platform configuration do not add up to a fully portable runtime package.

[INTERPRETATION] The value does not show that “only 33 percent of a website” can be exported. It shows that many weighted state classes of the hosted platform are not publicly documented as a complete exit state.

---

II.6 The ten state classes in detail

Core Records

Required are:

• stable IDs,
• timestamps,
• status,
• owner,
• custom fields,
• deleted/tombstone state,
• complete pagination.

Relationships

A record without relationships can be worthless in business terms. Necessary are:

• parent/child references,
• many-to-many links,
• foreign keys or mapping tables,
• referential integrity,
• import ordering.

Users and permissions

For security reasons a direct transfer is not always possible. Even so, at least the role model, groups, ownership and object grants have to be capable of being inventoried.

Automations

To be secured:

• triggers,
• conditions,
• actions,
• schedules,
• error paths,
• dependencies,
• version,
• active state.

Audit Logs

Audit data serves more than compliance. It helps with:

• delta migration,
• conflict resolution,
• post-exit forensics,
• evidence of the most recent changes.

---

II.7 Reconstitution Drill

Phase 1: Inventory

• data classes and volume,
• schema and custom fields,
• files,
• relationships,
• users and roles,
• workflows,
• integrations,
• audit and retention.

Phase 2: Export

• full export,
• API delta export,
• hashes and manifest,
• documented errors,
• rate limits and duration.

Phase 3: Restore

• isolated target environment,
• import ordering,
• ID mapping,
• files and links,
• roles,
• automations,
• samples and reconciliation.

Phase 4: Business Validation

• central user processes,
• reports,
• integrations,
• searchability,
• permission boundaries,
• audit evidence.

Reconciliation

Record Completeness
= successfully reconstructed records
/ expected records

Relationship Integrity
= valid reconstructed relationships
/ expected relationships

Workflow Parity
= critical workflows tested successfully
/ critical workflows inventoried

---

II.8 Export Security

An export reduces platform dependency but temporarily increases data risk:

• unencrypted ZIP archives,
• local downloads,
• uncontrolled admin laptops,
• public object storage buckets,
• long retention,
• missing hashes,
• personal data outside defined systems.

Minimum controls

• export service account,
• MFA and approval,
• encrypted target,
• short-lived download links,
• hash manifest,
• least privilege,
• access log,
• retention and secure deletion,
• DLP/PII classification.

---

II.9 Architecture principles

1. stable internal IDs instead of the provider ID as the sole key,
2. event and change log for delta reconstruction,
3. an own copy of critical master data,
4. secrets outside SaaS workflows,
5. business logic not exclusively in proprietary UI flows,
6. regular machine-readable exports,
7. schema registry,
8. import and restore code in the repository,
9. independent domains, DNS and identity,
10. tested degraded mode.

---

---

Part III - API deprecation and migration readiness

III.1 Research question

How completely do nine platforms document the signals and tools a company needs in order to handle API and runtime deprecations without an unplanned production outage?

Not examined are:

• actual individual notifications to customers,
• non-public enterprise support processes,
• the historical frequency of all breaking changes,
• the quality of every single migration document,
• proprietary internal APIs,
• SDKs and versions outside the specific surfaces examined,
• causality between score and real uptime.

---

III.2 Four states that teams frequently conflate

State	Meaning
Deprecated	use is no longer recommended; a replacement or shutdown may follow
Unsupported	vendor or project no longer promises regular support
Sunset / Retired	endpoint, version or feature is switched off or removed
Breaking Change	existing behavior or schema is not compatible without adaptation

An endpoint can be deprecated but still reachable. A version can be supported even though a single field is already being phased out. An SDK can stop being maintained while the underlying API keeps running.

[RECOMMENDATION] The internal register has to record the specific object: endpoint, field, auth method, API version, SDK version, runtime, webhook version or platform feature.

---

III.3 Methodology

3.1 Selection

The sample covers different governance models:

• date-based API versions,
• release and minor versions,
• quarterly API versions,
• account-bound versioning,
• cloud SDK and runtime lifecycle,
• changelog-centered platform changes.

The selection is purposive. It is meant to show differences in control architecture, not to represent the entire API market.

3.2 Sources

Official documents were scored:

• versioning and support policies,
• deprecation and sunset pages,
• changelogs and release notes,
• upgrade and migration guides,
• runtime and SDK maintenance documents,
• HTTP and API signals,
• notification and subscription information.

3.3 Criteria

Criterion	Weight	Evidence signal
Policy and terminology	15	deprecation, retirement, sunset and support clearly defined
Version pinning	15	production use can be fixed to a stable version
Notice and support window	15	minimum notice period or release-based support traceable
Central changelog	10	changes findable in one permanent place
Sunset date	10	end date or shutdown status clearly visible
Machine-readable signal	10	header, status code, schema or feed supports automation
Migration guidance	15	replacement, breaking changes and migration steps documented
Notifications/tools	10	subscriptions, status information or upgrade tools available

3.4 Score

1.0 = clearly and substantially documented publicly
0.5 = partial, product-dependent or not consistently documented
0.0 = not sufficiently evidenced publicly in the review path

The weighted score is a documentation metric. It is not a claim about technical superiority.

---

III.4 Results

API/platform surface	Score / 100	Classification
GitHub REST API	95.0	high public documentation maturity
Kubernetes API	90.0	high public documentation maturity
Microsoft Graph	90.0	high public documentation maturity
Shopify API	90.0	high public documentation maturity
Twilio Conversations	85.0	high public documentation maturity
Stripe API	77.5	solid public documentation maturity
Google Maps Platform	75.0	solid public documentation maturity
AWS SDK & Runtimes	72.5	solid public documentation maturity
Slack Platform	62.5	partial public documentation maturity

Distribution

• [CALCULATED] Mean: 81.9
• [CALCULATED] Median: 85.0
• [CALCULATED] Range: 62.5 to 95.0
• [CALCULATED] Five of nine surfaces reach at least 85 points.
• [CALCULATED] Two of nine are below 75 points.

The values are high for a selected group of mature ecosystems. The central deficiency is rarely a missing changelog. More frequently what is missing are uniform notice periods, machine-readable signals or a lifecycle model that is consistent across all product surfaces.

---

III.5 Vendor and project observations

GitHub REST API - 95.0

[OBSERVED] GitHub documents date-based API versions, a support period, breaking changes and upgrade behavior. Deprecation and sunset headers as well as defined HTTP responses make lifecycle signals machine-readable.

[INTERPRETATION] The value comes from the combination of human documentation and runtime evidence that can be automated. A team can not only read that something is being phased out, it can detect the state in requests.

Kubernetes API - 90.0

[OBSERVED] Kubernetes has a formal deprecation policy, release-based rules and documented migration paths. The API lifecycle model is closely tied to release and version skew policies.

[LIMITATION] A cluster upgrade covers more than removed API versions: controllers, CRDs, admission webhooks, operators and third-party tools can bring dependencies of their own.

Microsoft Graph - 90.0

[OBSERVED] Microsoft Graph distinguishes stable and beta surfaces and documents versioning, retirement and migration. Public lifecycle expectations are described for generally available API versions.

[CRITICAL] Beta endpoints do not have the same stability as GA surfaces. Production systems must not tacitly treat beta as a permanent contract interface.

Shopify API - 90.0

[OBSERVED] Quarterly versions, a defined support duration and documented fall-forward behavior create a predictable cadence.

[INTERPRETATION] A fixed cadence reduces surprise but increases the need for a continuous upgrade process. “Predictable” does not mean “maintenance-free”.

Twilio Conversations - 85.0

[OBSERVED] Lifecycle stages, support expectations and migration notes are public. The signaling is more human-readable than consistently machine-readable.

[RECOMMENDATION] Twilio dependencies should additionally be monitored through synthetic API and webhook tests, because communication paths are particularly outage-critical.

Stripe API - 77.5

[OBSERVED] Stripe offers strong version pinning and upgrade tooling. Versions can be controlled per account or per request.

[LIMITATION] Not every product change can be reduced to a single universal minimum notice period. APIs, events, SDKs and dashboard features have different change surfaces.

Google Maps Platform - 75.0

[OBSERVED] A central deprecation page, migration notes and, for the core services covered, an announced minimum notice period are in place. Individual libraries and channels can have differing conditions.

[CRITICAL] Alpha and beta channels are not to be treated like stable production channels. Choosing an experimental channel is itself an architectural decision about change risk.

AWS SDKs & Runtimes - 72.5

[OBSERVED] AWS publishes maintenance policies and runtime deprecation schedules. The field under review covers many services, SDKs and runtimes, however, and is therefore less uniform than a single API.

[INTERPRETATION] For large cloud platforms the lifecycle register has to be kept at resource level: Lambda runtime, SDK major version, managed engine, operating system image and API can have separate end-of-support dates.

Slack Platform - 62.5

[OBSERVED] Slack maintains a central changelog and publishes concrete migration guides. Less clear is a uniform, platform-wide policy for minimum notice periods and machine-readable sunset signals.

[RECOMMENDATION] Teams should subscribe to the relevant changelog categories and test Slack apps regularly against current scopes, events and auth requirements.

---

III.6 The “migration runway” metric

A vendor can give twelve months of lead time and a company can still be caught out if the information only arrives internally ten days before sunset.

Migration Runway
= sunset date
- internal detection date

Example:

Vendor announces sunset:  1 January
Detected internally:      1 October
Sunset:                  31 December

Public lead time: 364 days
Internal runway:   91 days

[INTERPRETATION] Deprecation readiness is therefore at least half an internal information problem.

Additional metrics

• Detection Latency: days between public announcement and internal ticket.
• Inventory Coverage: share of external dependencies with owner and version.
• Test Coverage: share of critical API contracts with contract tests.
• Migration Lead Time: time from ticket to production cutover.
• Sunset Margin: days remaining after a successful cutover.
• Unknown Version Rate: share of production calls without a known target version.

---

III.7 Reference architecture for deprecation control

Official changelogs / feeds / emails
                    ↓
          Dependency Intelligence
                    ↓
      normalized lifecycle register
                    ↓
     Jira/GitHub issue + owner + deadline
                    ↓
 Contract tests → staging → canary → rollout
                    ↓
    Evidence: old version no longer in use

The 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 or email subscription,
• deprecation and sunset HTTP headers,
• status codes such as 410 before they occur in production,
• schema diffs,
• SDK warnings,
• release notes,
• runtime inventory,
• IaC and container scans,
• synthetic requests.

[RECOMMENDATION] A changelog subscription without an owner and a workflow is merely one more unread inbox.

---

III.8 Contract tests instead of hope

Unit tests check your own logic. Contract tests check the assumptions at the external boundary:

• field present and type unchanged,
• authentication works,
• pagination and limits behave as expected,
• webhook signature and event schema match,
• error codes are handled correctly,
• the replacement version delivers semantically equivalent data,
• rate limits and timeouts stay within the operating budget.

For critical APIs, tests should run against:

1. the currently productive version,
2. the announced target version,
3. controlled failure cases.

This way a migration does not become visible only after the first production error.

---

---

3. The FW Delta Reconstitution Drill

3.1 Objective

Not “produce an export”, but establish a controlled minimum business operation outside the original system.

3.2 Procedure

Phase	Activity	Exit evidence
1. Scope	define critical processes, data classes and RTO/RPO	signed scope
2. Inventory	record objects, files, logic, roles, integrations	state register
3. Export	pull a complete export or API snapshot	checksums, logs, timestamps
4. Validate	check counts, relations, null values, files and history	deviation report
5. Transform	version the target model and mappings	reproducible transformation jobs
6. Import	populate an isolated target environment	import log
7. Rebind	reconnect IdP, webhooks, APIs and secrets	integration register
8. Replay	repeat representative business events	business test cases
9. Parallel Run	compare old and target system for a limited period	difference report
10. Sign-off	confirm residual deviations, risks and owners	exit acceptance

3.3 Minimum success criteria

• at least 99.9 percent of the business-relevant core records verified, or every deviation explained;
• all critical relationships checked for referential integrity;
• necessary attachments retrievable;
• roles and permissions documented in the target;
• at least one end-to-end process successful;
• RTO and RPO checked against actual times;
• missing features approved as a deliberate deviation;
• deletion and shutdown plan prepared.

[LIMITATION] 99.9 percent is a proposed operational threshold, not a universal legal or industry standard.

---

4. Architecture and contract controls

4.1 During selection

• Review export and API documentation before signing the contract.
• Demand sample exports and a sandbox.
• Inventory marketplace and add-on data separately.
• Document IdP and service account dependencies.
• Check rate limits and bulk endpoints.
• Fix post-termination access contractually.
• Define migration support, fees and data deletion.
• Agree on deprecation and breaking change notice.

4.2 During operation

• Replicate data regularly into controlled systems where legally and technically sensible.
• Keep configuration as code or as versioned exports.
• Control credentials in your own secret management.
• Inventory webhooks and integrations centrally.
• Monitor API versions and sunset dates.
• Do not just document the restore, test it.
• Name the exit owner and equip them with a budget.

4.3 Before renewal

• Export drill no later than T−150 days.
• Check critical API deprecations and SDK EOLs.
• Update target systems and transformations.
• Assess parallel run duration and data dual-write.
• Document actual migration costs as a negotiation BATNA.

---

5. Visualization specification

Chart 1 - Lock-in risk by platform

• Data: FDR-2026-02_lockin_risk_scores.csv
• X: risk 0–100
• Note: higher = more modeled risk

Chart 2 - Export completeness by state class

• Data: FDR-2026-02_export_completeness_long.csv
• Type: heatmap
• Rows: platform
• Columns: state class
• Values: 0 / 0.5 / 1
• Legend visible

Chart 3 - Risk vs. export completeness

• Data: FDR-2026-02_exit_readiness_composite_shared_sample.csv
• X: lock-in risk
• Y: export completeness
• Label: vendor
• no trend line at n=6

Chart 4 - API migration runway

• Data: FDR-2026-02_api_deprecation_readiness.csv
• Presentation: score plus documented notice and support dimensions

Chart 5 - Reconstitution Chain

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

Conceptual graphic, not a measurement series.

---

6. Reproducibility

Data files

• 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

Replication protocol

1. Use only official export, backup, API, versioning, migration and terms documents as score evidence.
2. Document product plan, region and administration role.
3. Score each state class separately.
4. Do not count a feature as exportable if only a screenshot or a manual copy-paste route exists.
5. Do not equate API access with bulk export or restore.
6. Score deprecation readiness only where documented, findable evidence exists.
7. Calculate shared composites only for genuine sample overlaps.
8. Publish real drills separately from documentation scores.

---

7. Limits

1. The scores measure public documentation, not guaranteed contractual rights.
2. Enterprise plans can contain additional export and support features.
3. No complete real exit was carried out for every platform.
4. A low lock-in risk score does not prove a cheap switch.
5. A high export score does not prove a semantically identical target application.
6. API policies can vary by product or version.
7. Marketplace apps and third-party integrations are only partly visible.
8. Credentials are frequently not exportable for good security reasons; that increases operational work, not necessarily negative product behavior.
9. Scores contain editorial judgment despite open criteria.
10. Legal portability claims are not interpreted.

---

8. Citation notes

Permitted:

“FW Delta distinguishes between data export, restore and reconstitution. In the platform sample examined, core data was more frequently documented as exportable than automations, permissions and audit state.”

Not permitted:

“No SaaS vendor allows a complete export.”

Permitted:

“The shared six-vendor composite ranged between 35.5 and 64.6 points and applies only to the overlap of two transparent FW Delta modules.”

Not permitted:

“Salesforce is 64.6 percent portable.”

---

9. Version history

• 1.0 · July 2026 · Three portability modules consolidated; shared six-vendor composite; reconstitution drill and exit debt model added.
• Live version open · Before publication, review all API versions, export paths and help center pages again.

---

10. Sources

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

---

Disclosure and disclaimer

FW Delta develops self-controlled software and data infrastructures itself and can benefit economically from migration and exit projects. Criteria, sources, scores and limits are disclosed in order to make this perspective verifiable.

The report is not legal or contractual advice. A documented technical path replaces neither an individual contract review nor data protection, retention or deletion obligations.