Een maker stapt over op een andere inhoudsdienst. Het nieuwe platform importeert artikelen maar laat afbeeldingen achter. De accountnaam blijft gelijk, maar bestaande volgers vinden het nieuwe profiel niet. Er is een export van bladwijzers, maar alles verwijst nog naar de oude site. Een exportbestand hebben en na de verhuizing een volledige ervaring hebben vragen afzonderlijke acceptatiecontroles.
Daarom verdient open publiceren aandacht: het neemt de vraag ‘wat gebeurt er als gebruikers vertrekken?’ vroeg mee in productontwerp, in plaats van export als nog een knop in instellingen te behandelen.
Open publiceren krijgt concrete toepassingen
In juni 2026 introduceerde Bluesky blogapps rond Standard.site en besprak schrijf- en migratie-ervaringen op een gedeelde technische basis. Dat is een nuttig voorbeeld: één protocol kan verschillende inhoudsproducten ondersteunen, niet uitsluitend meerdere interfaces voor dezelfde app. Introductie door Bluesky
Een voorbeeld binnen één ecosysteem bewijst echter geen interoperabiliteit tussen alle platforms. Ontwikkelaars moeten nog steeds ondersteunde gegevenstypen, uitbreidingsvelden en migratieprocessen aan beide kanten controleren. Een gedeeld technisch etiket vervangt geen echte import- en hersteltest.
Behandel identiteitscontinuïteit en inhoudsbehoud apart
De W3C-specificatie DID Core beschrijft decentrale identificatoren en bijbehorende controlemechanismen. Een identificator helpt systemen dezelfde entiteit te herkennen, maar ‘ik kan nog bewijzen dat dit account van mij is’ bewaart niet automatisch historische inhoud, mediakopieën of applicatiestatus. W3C DID Core
Productteams kunnen apart vragen: kunnen gebruikers controle over hun identiteit blijven aantonen, hoe wordt de nieuwe dienst gevonden, hoe blijven historische links gekoppeld en wat valt te herstellen als de oude dienst verdwijnt? Zulke vragen worden makkelijker concrete functies dan de algemene belofte ‘gebruikers bezitten hun accounts’.
Herstelmethoden moeten eveneens begrijpelijk zijn. Sleutels, herstelgegevens en door aanbieders ondersteunde mechanismen hebben eigen voorwaarden. Alleen in ontwikkelaarsdocumentatie een ideaal proces beschrijven volstaat niet wanneer gewone gebruikers deze begrippen pas tijdens migratie tegenkomen.
Een exportpakket moet zijn grenzen uitleggen
De migratiehandleiding van AT Protocol bespreekt gebruikersrepositories, mediablobs en privévoorkeuren apart en legt uit hoe identiteitsgebonden dienstinformatie wordt gewijzigd. Ook vermeldt zij dat sommige toestand in andere diensten kan liggen. Zelfs een ecosysteem met expliciete migratie vereist dus controle per onderdeel. Migratiehandleiding van AT Protocol
Voor inhoudsapps onder een eigen merk helpt deze tabel het leveringsbereik vast te leggen:
| Gegevenscategorie | Wat gebruikers belangrijk vinden | Aanbevolen acceptatiecontrole |
|---|---|---|
| Accounts en identiteit | Herkenbaar blijven na overstappen | Aanmelding, identiteitskoppeling en vindbaarheid van de nieuwe locatie controleren |
| Artikelen en records | Tekst, tijdstippen en verwijzingen bewaren | Aantallen, velden en representatieve inhoud vergelijken |
| Afbeeldingen, audio en video | Bijlagen die echt openen | Media-inventaris afstemmen en bestanden ophalen |
| Gebruikersrelaties | Volgrelaties en verwijzingen blijven oplossen | Ondersteunde relatietypen en doelidentiteiten aan beide kanten controleren |
| Privé-instellingen | Voorkeuren, berichten of toestand die kunnen ontbreken | Inclusies, uitsluitingen en herstelmethoden expliciet opsommen |
Dit is een ontwerpadvies, geen universeel gegevensformaat voor ieder protocol. Vooral volgrelaties, aanbevelingsinstellingen en privéberichten mogen niet ‘volledig verhuisd’ heten alleen omdat sommige openbare berichten kunnen worden geïmporteerd.
Migratieoefeningen tonen verborgen afhankelijkheden
We adviseren een speciaal testaccount met uiteenlopende inhoud: platte tekst, artikelen met bijlagen, onderling verwijzende records en duidelijk herkenbare relaties. De controledoelen komen dan uit bekende voorbeelden, zonder te experimenteren met echte gebruikersgegevens.
Leg tijdens de oefening koppelingen vóór en na migratie vast: oorspronkelijke en nieuwe identificatoren, bijlagelocaties en niet-ondersteunde velden. Het aantal geslaagde imports is maar één resultaat. Open inhoud, speel media af, bekijk verwijzingen en controleer of fouten afzonderlijk kunnen worden afgehandeld.
Simuleer ook een onderbreking. Kan het proces doorgaan als de export klaar is maar pas de helft van de bijlagen is geüpload? Levert opnieuw importeren duplicaten op? Meldt het hulpmiddel een niet-ondersteunde instelling duidelijk of verwijdert het die stilletjes? Dit bepaalt vaak of migratie geschikt is voor echte gebruikers.
Bewaar totdat de controle klaar is een bruikbare oude kopie en een herstelroute. De dienstlocatie wijzigen en oude gegevens verwijderen horen aparte handelingen te zijn. Gebruikers moeten weten wanneer terugkeren nog kan en wanneer gevolgen onomkeerbaar worden.
Erken verschillen in plaats van ze te verbergen
Open protocollen eisen geen identieke functies in iedere app. De ene richt zich op lange teksten, de andere op korte berichten of mediabibliotheken. Ontwikkelaars moeten uitleggen welke gezamenlijke mogelijkheden kunnen meeverhuizen, welke eigen functies alleen als aanvullende gegevens bewaard kunnen worden en welke slechts te archiveren zijn.
Een migratierapport heeft dus meer nodig dan ‘geslaagd’ of ‘mislukt’. Een nuttig rapport onderscheidt gecontroleerde onderdelen, niet-ondersteunde onderdelen en punten die actie van de gebruiker vragen. Zo kunnen makers beslissen vóór zij ontdekken dat belangrijk materiaal verdwenen is.
Het openbare materiaal van AlphaBiz biedt een ingang voor apps onder een eigen merk. Gegevensoverdraagbaarheid is daarin een relevante productvraag: hoe behouden opgebouwde inhoud en relaties waarde wanneer merk en interface veranderen? AlphaBiz-projectinformatie
Dit artikel beschrijft AT Protocol of Standard.site niet als bestaande AlphaBiz-integraties. De nuttige volgende stap is de eigen gegevensgrenzen bepalen en via controleerbare migratieoefeningen verifiëren. Begin met ‘wat mogen gebruikers bij overstappen niet verliezen?’ en deel eisen in de projectdiscussies.