Imagine a creator switching content services. The new platform imports articles but leaves their images behind. The account name stays the same, yet existing followers cannot find the new profile. A bookmarks export exists, but every item still points to the old site. Having an export file and having a complete experience after migration are two things that need separate acceptance checks.
This is what makes open publishing worth attention: it brings “what happens when users leave?” into product design early, instead of treating export as just another button in settings.
Open publishing is finding concrete applications
In June 2026, Bluesky introduced blogging applications associated with Standard.site and discussed writing and migration experiences built on a shared technical foundation. This offers a useful case study: one protocol can serve different content products, not merely multiple interfaces to the same application. Bluesky’s introduction
An example within one ecosystem does not, however, establish interoperability across all content platforms. Developers still need to check the data types, extension fields, and migration processes supported at both ends. Sharing a technical label cannot replace an actual import and recovery test.
Treat identity continuity and content preservation separately
The W3C DID Core specification describes decentralized identifiers and related control mechanisms. An identifier can help systems recognize the same entity, but “I can still prove this account is mine” does not automatically preserve historical content, media copies, or application state. W3C DID Core
Product teams can ask separate questions: can users continue to prove control of their identity, how is the new service location discovered, how do historical links remain associated, and what can be recovered if the old service becomes unavailable? These questions translate into concrete features more readily than a broad promise that “users own their accounts.”
Recovery methods also need to be understandable. Keys, recovery credentials, and provider-assisted mechanisms each have conditions for use. Describing an ideal process only in developer documentation is insufficient if ordinary users first encounter these concepts during migration.
An export package must explain its boundaries
The AT Protocol migration guide discusses user repositories, media blobs, and private preferences separately, and provides steps for switching identity-related service information. It also notes that some state may reside in other services. Even an ecosystem with an explicit migration mechanism therefore requires item-by-item verification. AT Protocol migration guide
For branded content applications, this table can help define the delivery scope:
| Data category | What users care about | Suggested acceptance check |
|---|---|---|
| Accounts and identity | Remaining recognizable after changing services | Verify sign-in, identity association, and discovery of the new location |
| Articles and records | Preserving text, timestamps, and references | Compare record counts, fields, and representative content |
| Images, audio, and video | Attachments that actually open | Reconcile the media inventory and retrieve the files |
| User relationships | Continued resolution of follows and references | Check supported relationship types and target identities at both ends |
| Private settings | Preferences, messages, or state that may be omitted | List inclusions, exclusions, and recovery methods explicitly |
This is a design recommendation, not a universal data format for every protocol. Follows, recommendation settings, and private messages in particular must not be declared “fully migrated” merely because some public posts can be imported.
Use migration rehearsals to expose hidden dependencies
We recommend creating a dedicated test account containing different kinds of content: plain text, articles with attachments, records referring to one another, and clearly identifiable user relationships. Verification targets then come from known samples, without experimenting on real users’ data.
During the rehearsal, record mappings before and after migration, including original identifiers, destination identifiers, attachment locations, and unsupported fields. The number of successful imports is only one result. Open the content, play media, inspect references, and confirm that failures can be handled individually.
Also simulate an interrupted migration. Can it resume when the export is complete but only half the attachments have uploaded? Does a repeated import create duplicates? If a setting is unsupported, does the tool report it clearly or silently discard it? These questions often determine whether a migration is suitable for real users.
Until verification is complete, retain a usable old copy and a recovery path. Switching the service location and deleting old data should be separate actions. Users should know when returning is still possible and when they face irreversible consequences.
Acknowledge differences instead of hiding them
Open protocols do not require every application to have identical features. One may emphasize long-form writing; another may focus on short messages or media libraries. Developers should explain which shared capabilities can migrate, which unique features can only be retained as supplemental data, and which can only be archived.
A migration report therefore needs more than “success” or “failure.” A useful report lists verified items, unsupported items, and items requiring user action separately, allowing creators to decide whether to proceed before they discover that important material has disappeared.
AlphaBiz’s public material offers an entry point for developing branded applications. For such applications, data portability is a product-design question worth evaluating: when branding and interfaces change, how can the content and relationships users have accumulated retain their value? AlphaBiz project information
This article does not describe AT Protocol or Standard.site as existing AlphaBiz integrations. The more useful next step is to define an application’s own data boundaries and verify them through reviewable migration rehearsals. Start with “what must users not lose when they change services?” and share your requirements in the project discussions.