Your export is one zip archive named after the software it came from, like vagaro-export-2026-07-19.zip. Inside is a folder for every client, holding their profile, notes, treatment records, and photos, plus a copy of each source page exactly as it looked when it was captured. Nothing in it needs an account, a login, or an internet connection to open.

You can look inside it yourself: unzip it and open any client folder. The page.txt files are plain, readable text.

The file contains your clients' personal and health information, so treat it like a paper client file: store it somewhere you control, and don't email it around.

A good setup is two copies: one on your computer and one on an external drive or an encrypted cloud folder you already trust. Re-export every so often so your backup stays current; imports are built so that bringing in a newer export won't duplicate your clients.

Any software with the OSD Import label can read your file. You hand it the zip; it brings in your clients, notes, treatment records, and photos. You don't need to convert, rename, or edit anything first.

SpaSphere supports OSD imports today. Other platforms can add support at any time; the format is open and free for them to use. If your new software doesn't support OSD yet, ask them — the specification is one page, published at openspadata.org/spec.

An importer never needs vendor-specific code. The steps:

1. Unzip. Read manifest.json — check schema_version (current: 2).
   Refuse versions you don't understand.

2. Walk clients/*/client.json — each carries a canonical "record"
   block (kind: "client") with name, emails, phones, birthday,
   address, tags. Raw vendor identity rides alongside it.

3. For each client, walk sections/*/metadata.json — the "records"
   array holds canonical notes (kind: "note") and treatments
   (kind: "treatment"). Bodies are full text; provenance fields
   (id, created_at, author, template) are normalized.

4. Resolve attachments through assets/assets-index.json — records
   reference assets by id; binaries live at files/<sha256>.<ext>.
   Verify the hash if you want integrity checking for free.

5. Tenant-level data (services, inventory) lives under tenant/
   with the same metadata.json pattern (kind: "service" | "product").

6. Dedupe on (source, source_client_id) so re-imports are
   idempotent.

Two rules matter more than the rest. First, normalized values can be null: a birthday without a year is { "text": "October 3", "iso": null } — when the parsed field is null, the text form is authoritative, so import it as text rather than dropping it. Second, ignore what you don't recognize: section names and optional fields grow over time without a schema version bump.

The raw page.html / page.txt captures are evidence and recovery fallback. You don't need them for a normal import, but keep them accessible to the user — they're the proof of what the source system showed.