tuxwise<p>If you'd like to migrate your <a href="https://infosec.exchange/tags/AddressBooks" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AddressBooks</span></a> and <a href="https://infosec.exchange/tags/calendars" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>calendars</span></a> from somebody else's platform to a self-hosted or self-managed one, but there's no "migration assistant":</p><p>Check whether both platforms support the <a href="https://infosec.exchange/tags/CalDAV" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CalDAV</span></a> and <a href="https://infosec.exchange/tags/CardDAV" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CardDAV</span></a> standards. If they do, look into <a href="https://infosec.exchange/tags/vdirsyncer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>vdirsyncer</span></a> <a href="https://vdirsyncer.pimutils.org" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">vdirsyncer.pimutils.org</span><span class="invisible"></span></a></p><p>We'd recommend to test-migrate your existing data to a local filesystem storage first, and swap in your new storage only when syncing to the test storage worked without errors.</p><p>To protect yourself against migration blunders, mark your source storage (platform) as <code>read_only</code> and let it "win" in your <code>conflict_resolution</code> setting.</p><p>For address book pairs, you can also sync the "displayname" and "description" metadata – for calendar pairs, additionally "color" and "order".</p>