Getting your existing clients in

You already have the data. It's in a spreadsheet, and probably in more than one. Getting it into a new system is the part that decides whether you ever really switch.

How it works

1. Export what you have to CSV. Excel, Google Sheets, or whatever your current system exports. No particular format is required.

2. Map your columns. Tell BeornNotes which column is the surname, which is the matter number, which is the review date. Your column headings don't have to match anything.

3. Preview. This is the important step. Every row is checked against your rules — the fields you made required, the formats you set, the uniqueness you asked for — and you get a list of exactly what's wrong and in which row. Nothing is written during a preview.

4. Fix and re-run, as many times as you like.

5. Commit. All rows are written in a single transaction — so either every row goes in, or none does. A file that fails halfway cannot leave you with a half-migrated database and no idea where it stopped.

What it checks

The import runs your records through the same rules the entry form uses. That isn't an implementation detail — it means an import can't quietly become a back door for data your own rules would have rejected, and rules you add later apply to imports automatically.

So it enforces:

• Required fields — a row missing one is an error, not a blank record
• Formats and masks — a matter number that doesn't match the pattern you set
• Lengths, ranges and date limits
• Email addresses that aren't addresses
• Uniqueness — including duplicates within the file itself, which is where most spreadsheet exports hide their problems

It also warns about likely duplicates on a column you choose — surname plus date of birth, say — so you can look before you commit rather than deduplicating afterwards.

Things that must already exist

Some values are references to other things, and the import will not invent them:

• Dropdown values — your custom list values must be set up first
• Owners and assigned managers — matched by name to real users in your firm
• Tags — matched by name

A row referring to something that doesn't exist is reported as an error with the row number, so you can either fix the spreadsheet or create the missing value and re-run. This is deliberate: silently creating a user or a dropdown value because a spreadsheet mentioned it is how lists end up with four spellings of the same thing.

What it won't do

Being straight about the limits saves a wasted afternoon.

It adds records; it doesn't update them. The import is insert-only. It's for bringing a list in, not for syncing an outside system against BeornNotes on an ongoing basis. Re-importing a corrected file means the earlier rows are still there.

It's administrators only. Bulk-creating records isn't something to hand to everyone.

It brings in record data, not documents. Your files stay where they are until someone attaches them to a matter. In practice this is fine: bring the client and matter list across, and let documents move as they come up in the ordinary course of work. Nobody needs to spend a weekend on it.

A sensible order

1. Decide what you call a record, and set your fields — see customization
2. Create your dropdown values and add your users
3. Export your spreadsheet to CSV
4. Preview, fix, preview again
5. Commit

Steps 1 and 2 first matters. Importing before your fields exist means importing into the wrong shape and doing it twice.

---

Try it before you commit to anything. The preview writes nothing, so you can point it at your real spreadsheet during a free trial and see exactly what it makes of your data — including the problems your spreadsheet has been quietly carrying.