Nobody signs up for Wix thinking about how hard it will be to leave Wix. That's not an oversight on your part — it's the point. The signup flow is optimized entirely around getting you building, and the platform's most important structural fact about your future relationship with it doesn't come up until the day you actually try to go.
What does 'you can't export your site' actually mean in practice?
It means exactly what it sounds like, and it's not a secret — it's documented across independent migration guides, Squarespace's own community forum, and years of small-business owners discovering it the hard way. Wix and Squarespace don't generate standard, portable HTML and CSS the way a typical website's code would look if you built it yourself. There's no clean export button that hands you your site's design in a format any other host could run. Squarespace offers a limited export — blog post text, in an RSS-style format — but the visual design, the layout, the styling choices that took real time to get right, stay on Squarespace's servers, tied to Squarespace's account. Where I stop at the implementation of what does vendor lock-in actually cost you, carries on into running it. Where I stop at the implementation of what does vendor lock-in actually cost you, the XenGrowth practice carries on into running it.
One migration-focused site put the practical consequence plainly: if you ever decide to leave, for performance, for SEO, for design control, for any reason at all, you are paying to rebuild from scratch. Images have to be manually downloaded and re-uploaded. Blog posts, where they export at all, land in an awkward format that needs cleanup on the other end. Three years of accumulated work becomes, functionally, a fresh project.
What you built | What actually moves if you leave | What you have to redo |
|---|---|---|
Page layout and visual design | Nothing — no portable export exists | Rebuild the entire design from scratch on the new platform |
Blog post text | Basic text, in a limited RSS-style export | Reformat, re-tag, and manually reinsert images |
Images and media | Files can be manually downloaded one at a time | Re-upload every image individually to the new host |
Domain name | Fully portable, per the ownership argument covered elsewhere in this cluster | Nothing — this is the one part of the setup that was never actually locked in |
Is this specific to website builders, or does it happen everywhere?
It's close to universal, at every scale. Flexera's 2020 CIO Priorities report, surveying 302 CIOs and senior IT executives, found 68% specifically worried about vendor lock-in with public cloud infrastructure — the same anxiety, at enterprise scale, that a small business feels about a website builder. And cloud wasn't even the top concern in that same survey: 78% of respondents cited lock-in worry around SaaS products, and 76% around on-premise software. This is not a fringe concern limited to indie web builders. It's the dominant anxiety across nearly every category of vendor relationship a modern organization has, at every size of organization. A parallel discipline for avoiding this at the infrastructure layer is covered in Terraform vs Pulumi vs CDK for Infrastructure as Code, which is about keeping infrastructure definitions portable rather than locked to one provider's console. covers the the operations side of this side of this. The XenGrowth resource library covers the the operations side of this side of this.
What if the vendor itself is the one that leaves?
This is the version of lock-in nobody plans for, because it doesn't require you to make a bad choice at all — it just requires the vendor to make a business decision on its own timeline. On June 15, 2023, Google announced it was selling Google Domains, then hosting roughly 10 million domains, to Squarespace. The deal closed that September, with final migrations completing by July 2024. Every one of those 10 million domain owners had their registrar relationship handed to a different company entirely, on Google's schedule, without a vote.
Squarespace, to its credit, committed to honoring existing customers' renewal pricing for at least 12 months — a better outcome than many acquisitions produce. But the underlying point stands regardless of how gracefully this particular transition was handled: you can do everything right, choose a large, seemingly permanent vendor, and still end up locked into a relationship you never chose, because the vendor's own exit decision becomes your migration project whether you wanted one or not.
Vendor lock-in isn't only the risk that you'll want to leave and can't. It's also the risk that the vendor leaves the business, and hands your relationship to whoever bought the assets — a decision you have exactly as much input into as a subscriber has into who buys their cable company.
Lock-in category | Flexera 2020 survey concern rate | What actually creates the exposure |
|---|---|---|
SaaS products | 78% | Data formats, integrations and workflows built around one vendor's specific API and UI |
On-premise software | 76% | Custom configuration, licensing terms and integration work tied to one vendor's stack |
Managed service providers | 75% | Operational knowledge and processes that exist only inside the provider's tooling |
Public cloud | 68% | Proprietary services (managed databases, serverless functions) with no equivalent elsewhere |
What's notable in that ranking is that public cloud, the category most people associate with the term 'vendor lock-in,' actually scored lowest among the four. SaaS products, the fifty small subscriptions the average business quietly accumulates, worried CIOs more. That tracks with the Wix and Squarespace pattern exactly — a SaaS product's lock-in is often less about technical difficulty and more about the sheer volume of accumulated, non-portable configuration and content sitting inside it by the time anyone thinks to check. works through AI agents and marketing automation in more operational detail. XenGrowth on AI agents and marketing automation works through AI agents and marketing automation in more operational detail.
So is using a platform at all a mistake?
There's also a slower, quieter version of platform exit that doesn't involve a company being sold or shut down at all: a pricing model change. A platform can simply decide, unilaterally, that its next tier costs three times as much, or that a feature you built your workflow around is now gated behind a higher plan. This isn't a hypothetical corner case — it's the normal life cycle of venture-backed software, where an early, generous pricing tier exists specifically to build a user base that later absorbs a price increase with much higher switching costs than it had on day one. The lock-in cost here isn't a rebuild, exactly — it's a captive audience for whatever the vendor decides to charge next, precisely because leaving was made expensive by design while you weren't looking.
No — and this is worth being direct about, because the argument here isn't 'avoid platforms.' For most people and most small businesses, Wix or Squarespace's speed and polish is a completely reasonable trade against the real cost of building and maintaining a custom site. The point isn't that the trade is wrong. It's that most people make the trade without knowing its terms, because the terms only get disclosed, structurally, at the point of exit rather than at the point of entry.
There's an honest counter-consideration worth naming: switching costs aren't purely a vendor's manipulation — some of it is just the ordinary cost of any specialization. A tool that does one thing extremely well will always be somewhat harder to leave than a generic alternative that does everything adequately, because the specialization itself is the value you paid for. The distinction that matters is whether a vendor's difficulty-to-leave is a byproduct of genuinely useful specialization, or a deliberately engineered absence of an export feature that would cost the vendor almost nothing to build. Wix and Squarespace's lack of a design export leans heavily toward the second category — the underlying page rendering already exists; what's missing is only the willingness to hand it to you in a portable form. For the AI search, GEO and discovery angle, see . For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
What should you actually check before you commit?
Before building anything substantial on a platform, search specifically for '[platform name] export' or '[platform name] migrate away' and read what current users report, not just what the vendor's marketing says
Separate what's genuinely portable (your domain, in almost every case) from what isn't (design, layout, and often content formatting), and weigh how much of your value sits in the non-portable part
For anything with real commercial or brand value, keep an independent, periodic backup of your own content — the raw text and images — even if the platform's own export tools are limited, so you're not starting from literally nothing if you ever do leave
Assume any vendor, however large, can exit its own business line on a timeline you don't control, and don't treat 'it's a big company, it'll be fine' as a substitute for actually checking their track record on customer transitions
Weight lock-in risk in proportion to how hard the thing would be to rebuild — a simple brochure site is cheap insurance either way; years of blog content, a large product catalog, or a customer database is a different order of exposure entirely
It's worth noticing how much of this cluster keeps returning to the same underlying test: can you take it with you, on your own initiative, without the provider's cooperation? A domain passes that test. A registrar relationship passes it with friction. A website builder's actual design and content, by the evidence in this post, usually fails it outright. That single question — not price, not features, not brand reputation — is the one that actually predicts how a vendor relationship ends when you're the one who wants out.
The honest version of this argument isn't that lock-in is avoidable. It's that it's priceable, if you look at it before you commit rather than after. Almost nobody does the pricing exercise up front, because the platforms whose business model depends on you not leaving have no incentive to make that pricing easy to find. On the operational side of vendor selection specifically for marketing and growth infrastructure, is a useful companion to this.
Further reading from XenGrowth
Where this work meets go-to-market
Evaluating whether a marketing platform is worth the lock-in it carries? publishes operator guides on choosing infrastructure with the exit already priced in.
Further reading from XenGrowth
Where this work meets go-to-market
The operational playbooks that sit alongside what does vendor lock-in actually cost you live with .
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
The operational playbooks that sit alongside what does vendor lock-in actually cost you live with XenGrowth's growth engineering practice.
Five questions on documented lock-in patterns across platforms, cloud vendors, and the domain industry.
