Move business off spreadsheets: a practical map
Most businesses that say they have "no system" actually have four: a price list, a customer list, an expense log, an order history — each a spreadsheet, each trusted by exactly one person, each one bad autocomplete away from a wrong number nobody questions for a month. What stops people replacing them is rarely attachment; it's the fear of a single all-or-nothing cutover. So don't do one.
Start with the one causing the most pain
The textbook order — catalogue first, then customers, then history — is fine advice if nothing is actively hurting. If something is, start there instead: the version-behind price list two people edit in parallel, the expense log a month of receipts behind on a good week. Momentum from fixing a felt problem carries you through the setup effort in a way that starting with the "correct" but painless spreadsheet never does.
What actually has to be true for an import to work
Underneath any real import tool, three decisions do all the work:
Mapping — telling the destination that your spreadsheet's "Item Name" column and its own name field mean the same thing.
A dedupe key — a stable identifier that survives between imports, so re-uploading a corrected file updates three rows instead of duplicating 2,000. Names change; an external reference, order number or email doesn't.
Per-row handling — each row succeeds or fails on its own, so one malformed line doesn't block, or silently corrupt, the few thousand that were fine.
The parts that usually move cleanly
A handful of categories tend to import well with a properly mapped file, because the destination fields are well-defined and the data itself doesn't usually require much interpretation:
Catalogue — a price list becomes real product or service records, each one then editable normally afterwards rather than staying a frozen import.
Customers — a contact list becomes customer records, matched or created by a stable identifier like email, without silently opting anyone into marketing they never actually agreed to — that consent has to be a genuine, separate yes, not an artefact of having once been in a spreadsheet.
Historical orders or transactions — a past-sales log becomes read-only history you can report against, without it pretending those are live orders that still need fulfilling, capturing payment, or being eligible for a refund.
Expenses — categorised spending becomes structured records with a vendor and a category attached, so a profit view can use them immediately rather than waiting for someone to re-key a year of receipts by hand.
The part that never moves automatically: judgment calls
No importer can decide that "Misc", "misc.", "Other" and "Uncategorised" are one category — merge them before the import or you'll get four. The same goes for what counts as cost-of-goods versus operating expense (get that split wrong once and every margin figure afterwards inherits it silently), and for which three-year-old "customers" are worth bringing along at all. Migrating bad data faster isn't a win.
A practical order of operations
1
Clean the spreadsheet first
Fix obvious errors, agree on category names, remove test and duplicate rows — all of this is faster to do once, in the spreadsheet, than after it's spread across live records.
2
Import the smallest, safest slice first
A fresh month rather than five years of history, to prove the column mapping actually does what you think before committing the rest to it.
3
Check the result before trusting it
Spot-check a handful of imported records against the original spreadsheet by eye — right price, right category, right customer — before importing anything else.
4
Import the rest once the mapping is proven
With the small batch verified, the same mapping and dedupe key handle the remaining history safely — re-running is safe because the dedupe key means a repeat import updates existing records rather than duplicating them.
How Olmira handles this
Olmira imports by CSV, not by a single "migrate everything" wizard — deliberately, since the judgment calls above are exactly the ones a fully automatic tool shouldn't make for you. Catalogue, customers, historical orders and bookings map through the same field-mapping engine with a dedupe key, so re-running a file is safe; new catalogue items land as drafts and imported contacts are never auto-consented to marketing, so nothing goes live or gets emailed by accident.
Expenses import separately: categories and vendors are created from the names in your file, and each imported expense lands as a draft awaiting the same receipt-and-approval step as one entered by hand. The back office these imports feed is Management; the connector platform underneath is Integrations.
If it can export to CSV — and almost everything can — you can map it in. There's no per-vendor one-click connector to keep up to date — one mapped CSV import, with the same dedupe safety, covers every source system.
With a stable dedupe key in place — an external reference, order number or email, rather than a name — a repeat import updates or skips the records that already exist instead of duplicating them.
No — imported historical orders are kept out of revenue analytics specifically so a sales log brought in for reference can't inflate what actually sold through the live system.
Yes — up to 10,000 rows per file. A longer history just means splitting it into a couple of files rather than one, which also happens to make the "small batch first" step above easier.
No — that all-or-nothing framing is exactly the fear this guide is trying to talk you out of. Start using the parts you've already moved while the rest of the spreadsheets keep running; there's no rule that catalogue, customers and history all have to land on the same day.