Keep the original export untouched
Make a working copy before you change a single cell. Give the original a clear date and store it in an approved, secure location for your practice. Do not email it to yourself, drop it into a personal drive, or leave it in a downloads folder shared with other people.
Treat that original as a reference, not a draft. If a cleanup choice goes wrong, you need a reliable source to return to. The working copy is where you can remove columns, standardize dates, and correct obvious formatting problems without losing what the old system actually produced.
This is also a good time to reduce the number of copies. One protected original and one active working file are easier to account for than five versions called final, final-new, and final-really-new.
Decide what this import is meant to move
A client import should have a defined job. Are you moving contact details only? Active clients and their appointments? A full chart history? Those are different projects, even when the old system exports them together.
Write the scope in one sentence before you edit the file. For example: "This file creates client records with names, contact details, and addresses." That sentence helps you judge every column.
Treat communication consent as a separate migration requirement. Stillpoint's client CSV mapping does not include email or SMS preference fields, so an opt-out column in the source file will not carry over through this import. Record those preferences securely and confirm the supported migration path before any automated messages are enabled. Do not assume that an unmapped column will follow the client record.
If a column does not belong to the job, move it out of the working file rather than hoping the importer ignores it. Keep any separate source files secure and available for the later stage they belong to.
Do not quietly delete historical or clinical records because they look old. Record-retention obligations vary by profession and location. Decide what must be retained with the appropriate professional guidance, then make the migration plan match that decision.
Make names and contact details consistent
Importers can map a column called First Name more confidently than a column called Client Info. Clear headings matter, but the values underneath them matter too.
Scan the file for the patterns that usually create duplicate or incomplete records:
- a full name in one column for some clients and separate first and last names for others;
- nicknames mixed into legal-name fields without a clear rule;
- several phone numbers in one cell;
- email addresses with spaces before or after them;
- blank rows left between groups of clients; and
- a family email reused across several records without another way to distinguish them.
Do not invent missing information to make the sheet look complete. A blank phone number is more honest than a number copied from another family member. Correct what you can verify and leave the rest for a deliberate follow-up after the move.
If several people share contact information, keep their individual records distinct in the working copy. Shared details are not proof that two rows belong to the same person.
Before uploading those rows to Stillpoint, separate them from the main batch and confirm how each record should be handled. The CSV importer treats a repeated email within one batch as a duplicate and automatically skips later rows with that email. Do not invent replacement email addresses or upload the family group together and hope to correct it afterward.
Treat dates and numbers as data, not decoration
Spreadsheets are eager to be helpful. They remove leading zeroes, convert long numbers into scientific notation, and change dates to match the computer's regional settings.
Choose one unambiguous date format for the working file, such as 2025-04-03. Then inspect dates that could have been read two ways. Birth dates and appointment dates deserve particular care because a swapped month and day may still look plausible.
Format phone numbers and postal or ZIP codes as text when a spreadsheet might alter them. Check a few rows after saving and reopening the CSV. If the leading zeroes disappeared only after the file was reopened, the problem is in the file, not the importer.
Also look for totals, formulas, coloured cells, and hidden columns. A CSV keeps plain values, not the full behaviour of the spreadsheet you were looking at. If a value matters, make sure it exists in the cell itself and does not depend on a formula or visual cue.
Keep clinical detail out of catch-all columns
Old exports often contain a column called Notes. That heading tells you almost nothing about what is inside it.
Read a small sample before you map it. It may contain harmless administrative context, clinical observations, payment discussions, referral information, or a mixture of all four. Do not pour a mixed notes column into the first open text field in the new system.
Separate information by purpose when the destination supports it. Clinical material belongs in an appropriate protected clinical record. Scheduling preferences belong with scheduling. A reminder about which entrance to use belongs with arrival information. If the destination does not have a safe and accurate place for a column, pause and ask how it should be migrated.
This is one of the places where a smaller import is easier to reason about. Moving contact records first gives you a clear result. Clinical history can follow through a path designed for clinical history rather than arriving as an accidental attachment to a general client profile.
Review possible duplicates one by one
Duplicate detection is a prompt to make a decision, not permission to merge automatically.
Two rows with the same email may be one client entered twice, two family members sharing an inbox, or a client and a guardian. Two rows with similar names may be the same person after a name change, or entirely different people.
Use several details together. Compare the name, contact information, dates, and any stable identifier your old system provides. If you cannot tell, leave the records separate and flag them for review. It is usually easier to merge a confirmed duplicate later than to untangle two people who were combined too early.
Keep a short count as you work: clear duplicates, possible duplicates, and unresolved rows. That count gives you something concrete to compare with the import preview.
Run a small rehearsal before the full file
Build a tiny preview file with two or three obviously fictional clients and contact details controlled by your practice. Include field patterns you actually use, such as a preferred name, an international phone number, an accented character, or a blank optional field.
Run those rows through the same mapping and preview you plan to use for the real file, but stop before committing the import. The goal is to test the file and mapping without creating fictional clients that need to be removed later.
- Does each source column map to the destination you expected?
- Does the preview flag the rows you expected it to flag?
- Are required values, dates, phone numbers, and accented characters displayed correctly?
- Does the previewed row count match the number you intended to include?
Once the fictional preview is correct, import a small, representative group of real records that you intend to keep before committing the entire list. Choose examples that are useful for verification, not just the easiest rows. Check a client with an international phone number, one with a missing email, one with an accented character, and one who may already exist in the new system.
If the sample is wrong, stop and correct the mapping. Do not plan to repair the full client list by hand afterward.
Keep a record of the decisions you made
Write down the source file name, export date, fields included, date format, columns excluded, duplicate rule, and the person who reviewed the preview. This can be a short migration note kept in your approved practice documentation.
The note is useful if you discover a problem a week later. Instead of guessing what happened, you can see whether a field was excluded on purpose, whether a duplicate was left unresolved, and which file produced the imported records.
Once the migration is verified, handle the working files according to your practice's retention and security process. A successful import is not a reason to leave client exports scattered across local folders.
Stillpoint's import workflow accepts client CSVs and guided exports from several common practice platforms. You can map columns, validate rows, review a preview, and decide how to handle possible duplicates before committing the import. Explore Stillpoint integrations and data import.
