Migration cost determines community stability
Aliases: platform switching · community migration · platform lock-in · three sources of lock-in
What it is
Community switching cost is what members lose when leaving or moving: relationships, history, reputation, content, tool familiarity, and shared norms. Stability can reflect satisfaction, but also that departure is difficult.
Why it happens
Community value sits in network and accumulated record. Friends, searchable knowledge, identity history, and collaboration habits do not fully travel. High cost resists short shocks but locks dissatisfied members in and reduces governance pressure.
The second-order mechanism splits switching cost into three sources that come from different places, can vary independently, and need different remedies: network lock-in (relationships and connections stay behind — a new community means re-meeting everyone), data lock-in (published content and accumulated history are hard to export and carry over intact), and learning lock-in (familiarity with this tool, these operating habits, these tacit rules was built up specifically on the original platform — switching means starting from scratch). These three respond completely differently to the same class of "portability" improvement. Exportable data, open standards, and interoperability protocols effectively reduce data lock-in but do almost nothing for network lock-in — an exported chat history arrives on the new platform, but the people you knew are still not there. Network lock-in can only be eased by a group migrating together or by cross-platform identity interoperability; individual-level data portability alone cannot solve it. Conversely, solving only network lock-in (say, syncing friend relationships across platforms) without solving learning lock-in still costs a user some engagement when they arrive with friends but find the new tool unfamiliar. Diagnosing which lock-in a community's switching cost is actually stuck on determines where investment should go.
Studying it
- Paradigm: interview movers and analyse exits, cross-platform activity, and exports; specifically design questions that separate the three — asking "would you switch if your friends stayed put," "would you switch if all your content and history came with you intact," and "would you switch if the tool worked identically" — and compare each one's marginal contribution to the decision to stay.
- Variables: strength of network lock-in (measurable via the correlation between staying and friends' willingness to migrate), data portability, tool familiarity, exit intention, retention, satisfaction, and sense of lock-in.
- Methodological caution: low migration is not high satisfaction; ask about barriers and alternatives directly. All three lock-ins usually act on the same person simultaneously, so a single-variable interview tends to overstate any one lock-in's independent contribution; use joint analysis or a scenario experiment that controls the variables separately.
Where it stops holding
Persistent identity, privacy, and safety requirements can limit portability but should not be used to justify opaque lock-in; very low switching cost can also weaken long-term care and commitment. The relative weight of the three lock-ins varies by setting: in relationship-centred communities (social networks of acquaintances, interest-based groups), network lock-in is usually the strongest, and improving data portability has limited effect. In communities whose core value is accumulated content and knowledge (Q&A sites, creator platforms), data lock-in tends to dominate — what members cannot leave behind is really their own published history and the visible record built from it. In highly specialised collaboration settings with a steep learning curve (a community built around professional software), learning lock-in can be the hardest to break — even if friends and data both travel, the cost of relearning a whole set of operating habits is enough to keep people in place.
Applying it
- Offer exportable personal content, relationship explanation, and a clear account-closure path, targeting data lock-in directly, even though this alone will not solve the other two.
- Support links, open standards, and multi-community participation while protecting privacy; if diagnosis shows network lock-in is the dominant factor, additionally consider cross-platform friend or identity interoperability rather than stopping at data export.
- Treat retention as a combination of satisfaction, trust, and exit difficulty rather than one success metric, and report it broken down by the three lock-in sources instead of a single blended retention rate.
- Verification: test whether members understand and can safely complete migration, and whether staying reflects genuine value rather than inability to leave; use the scenario questions above to periodically track whether the strength of each of the three lock-ins shifts with product changes.