Platform lock-in and data portability

reference · Scope: marketing-site · Status: current
platform-lock-indata-portabilitydomain-registration
Created 2026-06-11

Overview

Platform lock-in is the structural condition in which a small or mid-sized business (SMB) cannot produce a clean, working export of its own content, customer data, configuration, or infrastructure without the cooperation of a vendor or agency. Data portability is the inverse condition: the SMB can, at any time and without third-party permission, take the artifacts it depends on (database, media, code, DNS, mailbox, customer list) and move them to a different vendor or self-hosted environment with the relationships and structure intact.

This page consolidates the factual record across three related domains: (1) the practical state of export tooling at the major SaaS site builders and managed platforms (Wix, Squarespace, Webflow, WordPress/ACF, Shopify, ServiceTitan, Drupal, Google Workspace, and vertical SaaS); (2) the corporate-control events of 2023-2026 that made the lock-in question concrete (Squarespace's acquisition of Google Domains, the WP Engine / Automattic dispute and the forced ACF -> SCF fork, the BlackRock markdown of Automattic, Drupal 7 end-of-life, and the Shopify checkout.liquid sunset); and (3) the regulatory landscape (PIPEDA, Bill C-27, Bill C-15, Quebec Law 25, the EU Data Act, and the narrow scope of GDPR Article 20) plus the conceptual literature (Doctorow's right-of-exit framing and Tim Berners-Lee's Solid project).

The operational test that runs through the entire page, drawn from Doctorow, is the empirical predicate: if a vendor, agency, or platform cannot produce a clean export today, the client does not own that layer of the stack. That predicate, applied across the cases below, classifies every major SaaS site builder, most vertical SaaS, and many agency relationships as forms of lock-in that the SMB has accepted - usually without explicit cost accounting and often without contractual recourse at exit. See Research brief: Owning your stack — why agency-managed platforms cost more than they save (piece 4 of 15) for the parent research brief and Doctorow: "enshittification" — the three-phase decay pattern of platforms (Word of the Year 2023 + 2024) for the broader theoretical frame.

Ownership checklist at agency separation

The practical deliverable from Research brief: Owning your stack — why agency-managed platforms cost more than they save (piece 4 of 15) is a checklist of artifacts an SMB must be able to walk away with at agency separation, with no agency cooperation required. The checklist is grouped by layer:

Domain and DNS:

Email:

  • Google Workspace / Microsoft 365 tenant owned by the business (super admin = business email, not agency email).
  • At least two super admins in the business.
  • Mailbox export procedure documented (Workspace Takeout / Microsoft Compliance Export).
  • See the Google Workspace section below for why this is hard to fix after the fact.

Code:

  • Git repository hosted under business's own account (GitHub Org, GitLab Group) - not agency's.
  • Business has owner-level access to the repo.
  • README documents build/deploy steps.
  • No private/proprietary agency npm or Composer dependencies without source access.
  • License terms for any agency-developed code clearly assign IP to the business.

Content:

  • Database export procedure documented AND tested (see [[rule-require-database-export-day-one]] below).
  • Media library export (full-resolution, not optimized thumbnails) accessible.
  • Content stored in standard formats (Markdown, HTML, JSON) or a documented schema.
  • No page-builder shortcodes / proprietary JSON in critical content (or a clean export path exists).

Infrastructure:

  • Hosting account billed to the business (not the agency).
  • SSH / admin credentials transferable.
  • Backup procedure runs to a location the business controls (S3 with business's keys, not agency's).

Analytics and search:

  • GA4 property under business's Google account (with agency as delegated user, not the other way around).
  • Google Search Console verified by DNS TXT or HTML file controlled by the business - owner = business.
  • Google Business Profile owned by the business email, not the agency.
  • Meta Business Manager assets (pixel, ad account) owned by the business.

Customer relationships:

  • CRM / email-list / customer database export under business control.
  • Payment processor (Stripe, Shopify Payments, etc.) account in business's name.
  • Reviews on platforms tied to a business-controlled email.

Red flags - the business is already hostage if:

  • Domain WHOIS shows the agency name as Registrant.
  • The business cannot log into Google Search Console without the agency.
  • The hosting bill is paid by the agency.
  • The site uses an agency-proprietary CMS with no documented export.
  • The business cannot get a database dump on request.
  • Business email is on the agency's Workspace tenant.

Domain registration: ICANN registrant is the legal owner

The foundational layer of any web stack is the domain name, and the foundational legal fact about a domain name is that the registrant identified in the ICANN/registrar record is the legal owner. The administrative, technical, and billing contacts are not equivalent. This means that any time an agency lists itself as registrant on a client's domain, the client does not legally own the domain regardless of who paid for it. See ICANN: listed Registrant is the legal owner of a domain — admin/technical contact is NOT ownership for the underlying ICANN documentation.

Agency-as-Registrant 'domain hostage' pattern

The practice of agencies registering client domains under the agency name and then refusing transfer is documented as a recurring pattern, although it is rarely litigated. One referenced case in Texas involved an agency demanding thousands of dollars before releasing a domain. Sources include Domain Name Wire (multiple posts 2008-2024), Prospect Genius, Vendilli, and NetSourceMedia.

Confidence: Industry-consensus - the pattern is real and frequently described. Caveat: A rigorous frequency estimate would require ICANN UDRP and dispute data that has not been obtained. Pattern documentation is high; quantitative prevalence is unknown. Most of the available evidence is industry self-promotional blog posts rather than court records.

The practical implication is that domain registration is one of the cheapest and easiest layers to fix in advance, and one of the most expensive and uncertain to fix during a separation. The remedy is procedural: the registrant on every client domain must be the business (or the business owner), with billing in the business's name and login credentials under the business's control.

Squarespace acquired Google Domains for $180M (Sept 7, 2023) - ~10M SMB domains migrated automatically

Squarespace acquired Google Domains assets for $180 million; the deal closed September 7, 2023. Migration of ~10 million domains completed in batches through 2024. Squarespace pricing for .com domains is typically $20/year vs Google's previous $12/year.

Sources: Squarespace press release (Sept 7, 2023); Domain Name Wire; Brilliant Author 2024 analysis.

Confidence: Verified.

The event demonstrates that even the registrar layer is M&A inventory. Google Domains was advertised as durable Google infrastructure; customers had no relationship with Squarespace; the migration was automatic. The ~$8/year price increase is the visible cost; the deeper cost is the principle: infrastructure the SMB does not control can be sold to a vendor it did not choose.

Wix: officially no export by design

Wix is the most explicit of the SaaS site builders about its lock-in. The Wix Help Center currently states:

"Since Wix is a SaaS solution, your site must run on Wix's servers... the SaaS architecture does not support external hosting since it uses Wix's proprietary technology."

Source: Wix Help Center (current).

Confidence: Verified (primary).

The practical implication is that the content nominally "belongs to" the user but cannot leave. For SMB clients considering Wix, the trade is explicit: convenience and unified hosting in exchange for permanent inability to migrate. For SMB clients already on Wix who want to leave, the realistic budget is a content rebuild from scratch, not a migration. See [[rule-require-database-export-day-one]] below.

Squarespace 7.1: no XML export at all

Squarespace 7.1 does not support XML export at all. Squarespace 7.0 XML export does not include: images, products beyond CSV, custom CSS, video blocks, audio blocks, drafts, style settings, or any page type other than the first blog page and standard layout pages.

Sources: Squarespace Help Center (current); LitExtension migration guides 2026.

Confidence: Verified.

Migrating off Squarespace is effectively a content rebuild, not an import. The planning consequence: a Squarespace-to-anything-else migration is at least as expensive as the original build, and the content schema must be re-modeled. This is the second of two SaaS site builders (with Wix) where the empirical export test fails by design.

Webflow code export: brochure escape hatch, not a CMS migration path

The Webflow Help Center currently states:

"CMS, User Accounts, Ecommerce content (databases) and functionality, and localized pages, elements, and content aren't included in exported code."

Also: forms, site search, password protection, and reCAPTCHA do not function on exported sites. Code export is gated to paid Workspace plans ($24/mo+); the free tier cannot export. CMS Collections export only as CSV; relationships between items and design are not preserved.

Sources: Webflow Help Center (current); LitExtension migration guides 2026.

Confidence: Verified (primary Webflow documentation).

The practical implication is that Webflow code export is most useful as a brochure-site escape hatch - a static HTML/CSS snapshot of marketing pages. CMS-driven Webflow sites have no real equivalent: moving off Webflow with the content model intact is a content rebuild, not a portability operation.

WordPress and ACF: export tooling is conditional, not guaranteed

The WordPress ecosystem is the most-cited example of "open source so you own it." The claim is true at the code level (GPL license) and conditional at the data level. The dependency that most often breaks portability is Advanced Custom Fields.

ACF custom fields don't survive WordPress's native XML export

Advanced Custom Fields (ACF) data does not migrate cleanly via WordPress's native XML export/import. Image IDs break (they refer to post IDs that don't exist on the destination), and serialized array structures don't survive the round-trip. Practitioners commonly resort to: database dumps + search-replace tools on serialized data, or commercial tools like WP All Import Pro / WP Migrate Pro.

Sources: Advanced Custom Fields support forum (2024-2025); WP All Import Pro documentation.

Confidence: Industry-consensus.

The implication is that a typical SMB WordPress site with ACF custom fields is not portable via standard WP tools. "WordPress is open source" is true; "your WordPress site is exportable" is conditional on the specific plugin and field dependencies. This is the data layer beneath the political layer of ACF, which is the WP Engine / Automattic dispute below.

ACF -> SCF forced fork (Oct 12, 2024) - first unilateral plugin takeover in 21-year WordPress history

On October 12, 2024, WordPress.org forcibly took over the Advanced Custom Fields plugin (a WP Engine property running on >2 million WordPress sites) and renamed the WordPress.org-hosted version to "Secure Custom Fields" without WP Engine's consent. Sites with auto-updates enabled silently switched plugin source.

From the ACF official statement, October 12, 2024:

"A plugin under active development has never been unilaterally and forcibly taken away from its creator without consent in the 21 year history of [WordPress]."

Source: ACF homepage statement; WordPress.org plugin directory; TechCrunch and Verge coverage.

Confidence: Verified.

The event is dated, specific, and verifiable, which makes it the punchiest single data point in the WP Engine / Automattic dispute. The full dispute timeline follows.

WP Engine vs Automattic timeline (Sept 2024 - ongoing)

The vendor dispute between WP Engine and Automattic (led by Matt Mullenweg) demonstrated that even "open source" platforms have centralized distribution choke points that can be weaponized.

Timeline:

  • September 2024 - Mullenweg calls WP Engine a "cancer to WordPress" at WordCamp US.
  • October 2, 2024 - WP Engine files suit in U.S. District Court for Northern District of California, Case No. 3:24-cv-06917-AMO.
  • October 12, 2024 - WordPress.org forcibly takes over the Advanced Custom Fields plugin (WP Engine property, >2 million installs), renaming it "Secure Custom Fields" without WP Engine's consent.
  • December 10, 2024 - U.S. federal court grants WP Engine preliminary injunction ordering Automattic to restore access.
  • January 10, 2025 - Automattic cuts weekly WordPress core contributions from 3,988 hours to 45 hours (TechCrunch), matching what Mullenweg said WP Engine contributed.
  • September 12, 2025 - Court dismisses antitrust/extortion claims but allows defamation, interference, CFAA, and UCL claims to proceed.
  • October 23, 2025 - Automattic files 162-page counterclaim.

Sources: TechCrunch (multiple); The Verge; Courthouse News; Bloomberg Law; PPC.land.

Confidence: Verified. The case is in motion through 2026; specific details should be cited "as of [date]."

The lesson for SMB clients: WordPress's openness is real at the code level (GPL license) and conditional at the distribution level (the wordpress.org repository, plugin update channels, trademark enforcement). The argument that "WordPress is safe because it's open source" is incomplete - the safe part is the code, the unsafe part is the distribution infrastructure.

BlackRock marks down Automattic shares 67.4% to $27.74 (June 30, 2025)

BlackRock marked down Automattic shares from $85 (2021 Series E) to $27.74 as of June 30, 2025 - a 67.4% devaluation that leaves the shares worth only 32.6% of their 2021 Series E valuation.

Source: The Delta blog by Sam Sidler, August 27, 2025, citing BlackRock SEC filings.

Confidence: Verified (BlackRock filings are public).

The implication is that institutional investors are signalling that the dispute has materially damaged Automattic's valuation. The figure should be used carefully: share markdowns happen for many reasons (broader tech multiples, growth assumptions, etc.) and a one-quarter snapshot is not a complete thesis. But the timing aligns with the WP Engine litigation, and the magnitude is meaningful.

Drupal 7 end-of-life: 291,386 sites and a forcing function

Drupal 7 reached end-of-life on January 5, 2025 - "no longer receive official security updates." Approximately 291,386 sites were still on Drupal 7 as of September 2024.

From the Drupal community:

"Drupal 7's Core, modules and themes don't exactly have a clear upgrade path to higher versions" - migration is functionally a rebuild.

Source: https://drupal.org/about/drupal-7/d7eol/migration-resource-center ; https://orionweb.uk/blog-posts/drupal-7-end-of-life-migration-options

Confidence: Verified.

Drupal 7 EOL is the canonical platform-EOL forcing function: ~291k sites had to choose between (a) running unpatched software indefinitely, (b) paying for extended commercial support, or (c) rebuilding. The pattern pairs with Shopify checkout.liquid sunset (Aug 2024 → Aug 2025 → June 30 2026) — unmigrated customizations will be DELETED (47k Plus merchants forced to migrate by Shopify) and the Squarespace / Google Domains acquisition above (10M domains migrated automatically). Every platform sunsets eventually.

Shopify: checkout.liquid sunset and the cost of forced migration

The Shopify checkout.liquid sunset (see Shopify checkout.liquid sunset (Aug 2024 → Aug 2025 → June 30 2026) — unmigrated customizations will be DELETED for the full timeline) is the second canonical 2024-2026 forced-migration event. The customer-side cost of that migration has been characterized as follows.

Shopify checkout customization rebuild: $2k-$10k per shop, 4-8 weeks for complex Scripts

Custom Shopify Function migrations (rebuilds of checkout.liquid / Scripts customizations as Checkout UI Extensions) typically cost $2,000-$10,000 per shop depending on logic complexity (SANOMADS, 2026). "A complex Scripts setup takes 4-8 weeks to migrate" (Revize.app, 2026).

Sources: SANOMADS 2026 migration analysis; Revize.app migration guide 2026.

Confidence: Industry-consensus.

Per Shopify Help Center, unmigrated customizations "will be lost" in the January 2026 auto-upgrade. This is not a "consider migrating" recommendation - it is a "your code will be deleted on this date" event.

ServiceTitan: Open Data Pledge vs reported exit friction

ServiceTitan publishes an Open Data Pledge:

"We pledge to enable the seamless export of customer data to a CSV format."

Source: https://www.servicetitan.com/features/open-data-pledge

ServiceTitan also contractually positions the customer as "data controller" and itself as "data processor" - https://help.servicetitan.com/faq/servicetitan-service-contract-faq .

Practitioner reality (flagged as needing verification): BBB / Reddit complaints aggregated by Projul describe contractors paying $24,000-$39,375 to exit multi-year contracts: "the termination fee would be $24,000 - the full remaining contract value."

Source: https://projul.com/blog/servicetitan-pricing-analysis-2026/

Confidence: Open Data Pledge verified. Specific dollar figures are single-source aggregation two steps from primary - verify against an original BBB complaint before quoting any specific number in published writing. The gap between the Pledge and practitioner experience is the substantive point regardless of exact dollar figures.

Pricing context: ServiceTitan typical $245-$400 per technician per month + $5k-$50k implementation + 2-3 year contract (industry-consensus across Full Stack HVAC, Pipeline On, DinoQuote). At ~$78k average revenue per customer, that is the platform-side cost; the exit cost is the customer's.

Vertical SaaS export portability comparison (May 2026)

A field comparison of vertical SaaS data portability practices, current as of May 2026:

Platform Captures well Captures poorly Portability reality
ServiceTitan Dispatch, invoicing, payments, marketing attribution, customer history Custom equipment registries; multi-site commercial account quirks Open Data Pledge promises CSV - practitioner reports cite real exit friction (see ServiceTitan section above)
Jobber Quoting, scheduling, basic CRM, payments Multi-site accounts; complex contract pricing CSV/vCard export; capped at 1,500 rows per file, "select plans" only, admin-only. GraphQL API available.
Housecall Pro Booking, payments, dispatch, basic marketing Equipment serial registries; membership tiers Native CSV import/export for Customers/Jobs/Price Book on all plans; API and webhooks gated to MAX plan ($329/mo, 8 users)
Clio Manage Matters, time/billing, trust accounting, document mgmt Knowledge management; engagement profitability CSV export for contacts/matters/activities. Quote: "Data that cannot be exported from the original source in CSV format cannot be imported into Clio." CSV is the lingua franca.
Karbon Workflow, client communication, capacity planning Per-engagement profitability Marketing claim "With Karbon, your data always belongs to you" - practical bulk export pathway is Practice Intelligence BI/data-warehouse integration, not native one-click CSV
Tekmetric RO management, parts, customer history, integrated payments Cross-shop benchmarking Documents inbound migration ("data pull") workflows; no equivalent self-serve outbound - re-migration requires a support ticket

Sources: ServiceTitan / Jobber / Housecall Pro / Clio / Karbon / Tekmetric official help/feature pages (all verified May 2026).

The pattern: Every major vertical SaaS supports some export. None makes bulk historical relational export trivial. The gap between "CSV export exists" and "queryable warehouse of historical data" is where independent data infrastructure earns its place.

Google Workspace: no cross-tenant file ownership transfer

Google Workspace forbids transferring file ownership to external accounts (cited as "user and company data" protection). When a client's email and Drive live in an agency's Google Workspace, separation requires:

  1. Create a new Workspace under a temporary domain.
  2. Migrate mailboxes via IMAP with app passwords.
  3. Transfer Drive file ownership internally before account deletion.
  4. DNS cutover.

Without the agency's cooperation at every step, the practical outcome is data loss.

Source: https://support.google.com/a/answer/1247799 (current Google Workspace admin documentation).

Confidence: Verified (primary Google documentation).

Workspace ownership is one of the most under-discussed ownership layers. If a client's email is on an agency Workspace, plan a multi-week separation BEFORE the engagement ends. This is the layer referenced in the email section of the ownership checklist above.

Conceptual frameworks: enshittification, right of exit, Solid

Doctorow's right of exit: interoperability, not just open source

Cory Doctorow's prescription against enshittification (see Doctorow: "enshittification" — the three-phase decay pattern of platforms (Word of the Year 2023 + 2024)) is a "right of exit" - guaranteeing users can leave a platform without losing access to their data, which requires interoperability (not just open-source licensing).

Source: Enshittification: Why Everything Suddenly Got Worse and What to Do About It, Doctorow (Verso Books, October 2025); Pluralistic posts 2023-2025.

Confidence: Verified.

The operational version for SMB clients is: "If the agency / platform / vendor cannot produce a clean export today, the client does not own that layer of the stack." This is the empirical test that turns the framing into a checkable predicate, and it is the test that underlies the rules at the end of this page.

Solid project (Tim Berners-Lee) - data-pod architecture

Tim Berners-Lee launched the Solid project at MIT (solid.mit.edu) to re-architect the web around user-owned data pods. The Open Data Institute took stewardship in October 2024. Inrupt (Berners-Lee's commercial arm) raised $30M Series A in December 2021. Documented pilots include the Government of Flanders and NHS Digital.

Sources: solid.mit.edu; Wikipedia "Solid (web decentralization project)"; tech.eu (Inrupt Series A); ODI announcement October 2024.

Confidence: Verified.

The status for SMB use: Solid is real, has institutional backing, but adoption is slow. It is not a 2026 recommendation for an SMB client. File it as background context for "the data-ownership conversation is broader than a Postgres on a VM" - and as a forward-looking signal for the agentic-web direction.

Counter-argument: managed platforms buy a security team

The honest steel-man against the owned-stack thesis is that WP Engine, Shopify, and Squarespace each employ security teams larger than most agencies. A self-hosted VM with no patching discipline is more vulnerable than a managed platform, not less. A small business paying $200/month to WP Engine is buying a security team, not just hosting.

Source: Honest gap H1 in Research brief: Owning your stack — why agency-managed platforms cost more than they save (piece 4 of 15).

Confidence: Industry-consensus.

The implication is that the argument for an owned stack depends on operational competence that an article cannot assume. Self-hosting is not free. The right comparison is total cost of ownership (license + dev time + security + on-call + backup ops), not just license fees. This is where a maintenance retainer line item in agency pricing earns its keep, and it is the reason the rules below do not say "never use managed platforms" - they say "name the trade and document it."

Regulatory landscape: PIPEDA, Bill C-27, Bill C-15, Quebec Law 25, EU Data Act, GDPR Article 20

The regulatory frame for data portability is fragmented and moving. The current state, as of May 2026:

PIPEDA and Bill C-27 (Canada federal)

PIPEDA applies to any private-sector organization in Canada engaged in commercial activity using personal information. Maximum fine: $100,000 per knowing violation.

Source: Office of the Privacy Commissioner of Canada - https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/pipeda_brief/

Bill C-27 (Consumer Privacy Protection Act) died on the Order Paper on January 6, 2025, when Parliament was prorogued. In June 2025, Minister Evan Solomon confirmed it "will not return in its old form." As of May 2026, Canada remains governed by PIPEDA - no monetary fines under the current regime, only findings, recommendations, and compliance agreements.

Confidence: Verified (Fasken legal analysis January 2025; OPC enforcement record consistent).

Ontario-specific: Ontario does NOT have a private-sector privacy law deemed substantially similar to PIPEDA, so PIPEDA applies to most commercial activity by Ontario service businesses. PHIPA (Personal Health Information Protection Act) governs Ontario healthcare providers separately.

The implication for the data-ownership thesis: owning structured data is easier for PIPEDA compliance, not harder - an organization cannot honour an access request it cannot fulfill from spreadsheets scattered across five clouds.

Bill C-15 (Canada federal, tabled Nov 4, 2025)

Federal Canadian Bill C-15 (tabled November 4, 2025) proposes adding a data-mobility framework to PIPEDA - bringing federal Canadian privacy law in line with Quebec Law 25 and the EU Data Act.

Source: McCarthy Tetrault Bill C-15 analysis, November 2025.

Confidence: Verified (legislative record).

Status (as of May 2026): Tabled; not yet passed. Track through 2026-2027. If passed, the data-portability conversation with Ontario / BC / Alberta SMB clients becomes the same conversation already happening in Quebec.

Quebec Law 25 (data portability effective Sept 22, 2024)

Quebec's Law 25 (formerly Bill 64) is fully in force as of September 22, 2024 (data portability phase). The Quebec government recommends CSV / XML / JSON as portable formats and advises against PDFs, images, or proprietary formats.

Penalty schedule:

  • Administrative monetary penalties: up to C$10M or 2% of worldwide turnover (whichever is greater).
  • Penal fines: up to C$25M or 4% of worldwide turnover for serious violations.
  • Private right of action: individuals can sue with minimum $1,000 damages.

Phased rollout:

  • Sept 2022: DPO + breach notification.
  • Sept 2023: PIAs, consent, most rights.
  • Sept 2024: data portability.

Sources:

Confidence: Verified.

Scope for Ontario service businesses: Law 25 applies extra-territorially to any business serving Quebec residents. Practical obligations: designate a Privacy Officer, conduct PIAs before new systems or cross-border transfers, support data-portability requests in structured/machine-readable formats (CSV/JSON/XML - NOT PDFs), respond within ~30 days.

Compliance gap: Per Axeptio (a consent-management vendor), "fewer than 5% of Quebec's 255,000 SMEs are currently in compliance with Law 25" and "60% express no genuine intention to comply" as of the September 2024 deadline. Single-source caveat - vendor-published, directional. But the gap matches the GDPR rollout pattern.

The implication for SMB clients in Quebec: a Quebec SMB has stronger portability rights than an Ontario SMB does - until federal Bill C-15 catches up. This matters for any client with QC customers or operations.

EU Data Act (Regulation 2023/2854)

The EU Data Act (Regulation 2023/2854) became fully applicable September 12, 2025. It mandates cloud/SaaS switching procedures and eliminates switching fees by September 27, 2027. Extended interoperability requirements take effect September 12, 2026.

Sources: Digital Samba 2025 EU Data Act overview; Legiscope 2025 compliance guide; EUR-Lex Regulation 2023/2854.

Confidence: Verified (EU primary law).

The implication for non-EU SMBs: the Data Act applies to services offered in the EU regardless of provider location. Even a Canadian SMB using AWS or Shopify gets covered. The enforcement record is short - file this as a forward-looking signal, not a current lever. It pairs with Quebec Law 25 and Bill C-15 as evidence that regulators are catching up to platform lock-in faster than the US is.

GDPR Article 20: portability is narrower than rhetoric suggests

GDPR Article 20 grants a right to data portability in a "structured, commonly used and machine-readable format" - but only for data:

  • Processed by automated means.
  • Under consent OR contract (not other lawful bases).
  • That the subject provided (not derived data).

Practical exclusions: SEO rankings, server logs, platform analytics, derived insights, and a website's own content/configuration are not legally portable under GDPR. The right covers personal data, not the website's business assets.

Sources: gdpr-info.eu; eur-lex.europa.eu (GDPR full text).

Confidence: Verified.

The implication is that GDPR is often invoked rhetorically as "you have the right to your data" - but for the lock-in scenarios that matter most to SMB website owners (content, SEO rankings, plugin config, customer database structure), GDPR does not reach. The EU Data Act above goes further. Canadian Quebec Law 25 also covers more ground for personal data.

Operating rules

The three rules below are the operational distillation of everything above. They are intended to be applied as standing policy in client engagements, not as case-by-case decisions.

Rule: treat no-export as a hostage situation

When evaluating a platform / vendor / agency for a client, the empirical test is: can the client get a clean, working export of their content and data today, without vendor cooperation? If the answer is no, classify the situation as hostage in slow motion - there will be a forced migration event, and the cost will be on the client.

Three live 2024-2026 case studies prove forced migrations happen:

Add the SaaS-export-impossible cases (Wix; Squarespace 7.1) and the pattern is clear: platforms that cannot export will eventually impose a migration the client does not want.

How to apply:

  • During platform selection: weight portability as a primary criterion alongside cost and capability.
  • For existing clients on non-portable platforms: schedule a migration proactively to a portable stack, on the client's timeline, not the vendor's.
  • The 18-month / 5-year audit cadence (see editorial direction in Research brief: Owning your stack — why agency-managed platforms cost more than they save (piece 4 of 15)) catches these before the vendor forces the issue.
  • The honest counter-position (managed platforms buy a security team) still applies: some clients should be on managed platforms despite the lock-in. The rule is not "never" - it is "name the trade and document it."

Rule: require a working database export on Day 1

Every client engagement must have a working, tested database export procedure documented within the first week. The export runs end-to-end at least once during onboarding. The procedure is re-tested quarterly as part of the maintenance retainer.

Why: A database export that has never been run is theoretical. Doctorow's "right of exit" requires interoperability, not licensing. The empirical test of platform ownership is: can the client produce a clean export today? If not, the client does not own that layer. Wix and Squarespace 7.1 are cases where this test fails by design.

How to apply:

  • Day 1: identify the source-of-truth database (or content store) for client content.
  • Week 1: run the export, store the artifact in a business-controlled location (S3 bucket with business keys, or similar).
  • Document: command/procedure, expected size, format, what it includes and excludes.
  • Quarterly: re-run; diff against prior export; verify schema has not changed under the agency.
  • For SaaS-platform clients (Wix, Squarespace 7.1, etc.) where export is impossible: explicitly flag in the engagement contract that portability is not achievable on the current platform.

Rule: document exit transition in the contract

Every client contract includes an exit-transition clause that specifies, in writing:

  1. What artifacts the client receives at end of engagement (database dump, media library, repo handover, documentation).
  2. The format of each artifact.
  3. The transfer process (account transfers, super-admin reassignments).
  4. The timeline (e.g., "all artifacts delivered within 14 days of termination notice").
  5. The cost (e.g., "no additional fees for standard exit transition").

Why: Exit terms negotiated at engagement start are friendly. Exit terms negotiated during a separation are adversarial. The agency-domain-hostage pattern exists because most agency contracts are silent on exit, leaving practical leverage with whichever party currently holds the credentials.

How to apply:

  • Standard contract template has the exit clause. Don't custom-negotiate per-client unless the client requests stronger terms.
  • The clause references the ownership checklist above as the deliverable list.
  • This is also a prospecting tool: ask prospective clients to show you their current agency's exit clause. If there isn't one, that is the opening for the contrast.

Sources and confidence

Verified (primary documentation, legal text, or published company press release):

Industry-consensus (multi-source practitioner agreement, but not primary documentation):

  • ACF custom fields breaking on native XML export (ACF support forum 2024-2025; WP All Import Pro documentation).
  • Shopify Custom Function migration cost $2k-$10k per shop and 4-8 weeks for complex Scripts (SANOMADS 2026; Revize.app 2026).
  • ServiceTitan typical $245-$400 per technician per month + $5k-$50k implementation + 2-3 year contract (Full Stack HVAC; Pipeline On; DinoQuote).
  • The managed-platforms-buy-a-security-team counter-argument (honest gap H1 in Research brief: Owning your stack — why agency-managed platforms cost more than they save (piece 4 of 15)).
  • Agency-as-Registrant 'domain hostage' pattern - Domain Name Wire (multiple 2008-2024); Prospect Genius; Vendilli; NetSourceMedia. Caveat: most evidence is industry self-promotional blog posts rather than court records. Pattern is real; quantitative prevalence is unknown without ICANN UDRP and dispute data not obtained.

Single-source, directional (flag for verification before use in published writing):

  • ServiceTitan exit cost $24,000-$39,375 - Projul aggregation of BBB / Reddit complaints, two steps from primary. The gap between the Open Data Pledge and practitioner experience is the substantive point regardless of exact dollar figures.
  • Quebec Law 25 compliance gap: "fewer than 5% of Quebec's 255,000 SMEs are currently in compliance" and "60% express no genuine intention to comply" - Axeptio, vendor-published, directional. Pattern matches the GDPR rollout.

Raw JSON: /api/kb/platform-lock-in