Import & export
Move core practice data between SmileLine accounts, import CRM CSVs, or export clearly labelled entity CSVs.
By the end of this page you'll know which transfer to use: Core Practice Transfer for a quick SmileLine-to-SmileLine account migration, or entity CSVs for selective portability and migration from another CRM.
Everything on this page happens under Settings → Import & export. Owners and managers can use entity CSVs. Core Practice Transfer is owner-only.
CSV uploads can be up to 20 MiB, 500,000 data rows and 64 KiB per row. Split a larger export into separate files before uploading it.
Move a SmileLine practice without a database snapshot
Core Practice Transfer packages the supported CRM relationship graph behind an authenticated API. It does not need direct database access and it does not copy a database snapshot.
The package includes:
- practice display settings, locations, boards and stages
- treatments, lead sources, lost and cancellation reasons, contact methods, tags and referrers
- appointment types, operatories and practitioners
- patients, channel-specific contact preferences and their evidence history
- journeys, safe normalized attribution touches and stage history
- tasks, appointments and appointment participants
It deliberately excludes authentication and practice memberships, billing, subscriptions, agreements, conversations, messages, files, audit logs, automations, templates, campaigns, booking and provider operations, payments, credentials, webhooks, PMS state, Reputation state, referrals, reports, chat, knowledge-base and dialer state. Staff references are matched to existing destination members by exact email; unmatched staff assignments become unassigned.
Core Practice Transfer is a structured migration, not a point-in-time backup or disaster-recovery archive. The source remains live while the export runs, so use a quiet migration window and stop making source changes before the final export.
Before you start
Create the destination as a new, otherwise unused SmileLine practice. Complete onboarding with the same legal country and accounting currency as the source, but do not change the generated CRM configuration or connect integrations. The source and destination must be different practices.
Export and import
Create the source package
As a source owner, tick the best-effort export acknowledgement and click Create transfer package. You can keep using SmileLine while the background job runs, although a quiet window gives the cleanest result. SmileLine verifies row counts and relationship closure before marking the package ready.
Download it
Click Download under Recent jobs. The private package expires after seven days. Keep it secure: it contains patient and practice data even though capabilities and credentials are excluded.
Upload it to the destination
Switch to the destination practice, choose the .smileline-transfer.zip package, and click Upload transfer package. Packages can be up to 80 MiB. SmileLine checks the manifest, policy version, file list, sizes, hashes, row shapes, duplicate identifiers and complete foreign-key graph before offering the import.
SmileLine uploads the package in fixed chunks. Retrying the same chunk is safe, but an accepted chunk cannot be replaced with different bytes; cancel the transfer and start a new upload if the selected file changes.
The destination is locked as soon as validation starts. Other members can switch to another practice, but only an owner can finish or cancel the transfer.
Import and verify
When the job says Ready to import, review any unmatched-staff count and click Import. SmileLine replaces the generated seed CRM rows, creates deterministic destination IDs, regenerates appointment identities, verifies every imported table count and then unlocks the practice.
Reconnect integrations and rebuild excluded automations after checking the migrated data. If a recoverable queue step fails and Retry is available, use it while the job's finite processing window remains. If SmileLine says the import can no longer resume, click Cancel instead. Cancellation completely resets and reseeds a partially imported destination before unlocking it.
The destination reset also has a finite retry window. If the job tells you to contact support, the destination stays locked to preserve the failed import evidence. Do not recreate the practice or upload another package until support has reviewed it.
Import from DenGro or Boxly
Both platforms get a one-click path: their export columns are recognised automatically, so you skip straight to choosing a board.
Export from the other platform
- DenGro — go to Contacts → Leads, filter to what you want to migrate, then click Download leads. Tick "I understand" and download the CSV.
- Boxly — open a box, click Export → Comma Separated Values (.csv). Boxly emails you the file; repeat per box you want to bring over.
Upload it
Click Import data, pick DenGro or Boxly, choose the file and continue. The columns arrive pre-mapped — review the list and adjust anything that reads "Don't import" that you'd like to keep.
Choose a board and map their stages
Pick which journey board the imported leads land on, then match the other platform's stage names ("Consultation Booked", "Follow Up"…) to your board's stages. Treatments you don't have yet default to Create, so "Implants" arrives as a treatment automatically.
Run the check, then import
The dry run reads every row without writing anything and tells you how many patients would be created or updated, how many need review, and which rows have problems (a broken phone number, a missing name). Rows with errors are skipped — everything else imports when you click Import.
A DenGro row brings the whole picture across: the patient's details, their journey (stage, status, potential value, lost reason), marketing consent with its original date, and the attribution trail — channel, source, UTMs and click ids all land on the lead's touch history. Consent is recorded separately for every populated, unblocked contact channel, so SMS, WhatsApp and email remain independently auditable.
Leads DenGro has GDPR-erased ("Forgotten at" has a value) are skipped automatically — erased people must stay erased.
Import from any other CRM
Choose Other CRM / CSV instead. You'll additionally pick what the file contains:
- Leads (patients + journeys) — one row per lead, the shape most CRMs export
- Patients — demographics and contact details only
- Journeys, Appointments, Tasks — child records matched to existing patients by email or phone
- Vocabularies — treatments, tags, lead sources and the other settings lists
The mapping step recognises common column names ("Surname", "DOB", "Postcode"…) and shows sample values next to each column so you can verify the guess. Every row needs at least a first name and an email address or mobile number.
Dates and phone numbers vary by platform, so the values step has two dials: the date format (detect, day-first, month-first or ISO) and the default country for phone numbers without a prefix.
Money values must use the practice's locked currency. A matching EUR, GBP
or USD code, or €, £ or $ symbol, is accepted; a different or
unsupported currency is reported as a row error rather than converted. Amounts
must be zero or positive; negative or implausibly large values are reported as
row errors rather than imported.
How duplicates are handled
When an imported row shares an email address or mobile number with an existing patient:
- Strong agreement (name and date of birth line up too) — the row merges into the existing patient automatically. Merges only fill blanks; nothing you've typed is overwritten. Notes are appended.
- Anything weaker — the row is held for review rather than guessed at. The job shows Needs review; click it to see each held row next to the patient it resembles and choose Merge into existing or Import as new.
Re-running a DenGro import is safe: each lead's DenGro id is remembered, so a second run updates the same patients instead of duplicating them.
Export
The Export section downloads any entity as a CSV that opens straight in
Excel or Sheets — patients, journeys, appointments, tasks and every settings
vocabulary. Money cells include the locked EUR, GBP or USD code so they
cannot be re-imported as another currency. Downloads are capped at 10,000 rows;
anything bigger automatically becomes a background job and appears under
Recent jobs when ready.
A background entity export fixes an upper creation-time boundary when it
starts, then walks rows by (created at, id) rather than mutable page offsets.
Rows created after that boundary belong to the next export, and a redelivered
completed job does not rebuild its file. This is a bounded high-water export,
not a database snapshot: a row that already existed may contain an edit made
before the worker reached it.
Entity CSVs are data-portability files, not a lossless backup or a whole-practice disaster-recovery archive. Use Core Practice Transfer for the supported SmileLine-to-SmileLine CRM graph, and keep your own approved retention and backup process.
While an import runs
Imports run in the background in batches — you can leave the page. The job row under Recent jobs shows live progress, and the counts (created, updated, errors, to review) update as it goes. Cancel stops the job at the next batch; rows already written stay.
Every import and export is recorded in Settings → Activity log.
Uploaded CSV files are removed after a terminal job's download/review window. Row-error and possible-match snapshots are redacted 30 days after the job is finished. Unresolved snapshots have a hard 90-day limit, so an abandoned review cannot retain raw patient details indefinitely.