Two questions decide whether a system is worth trying: can I get my data in, and can I get it out again.
The first is a migration you do once and then remember for years. The second is the one people forget to ask until they want to leave, which is exactly the wrong moment to find out the answer.
What you can do
- Import customers and suppliers with their addresses, contacts and registration numbers.
- Import your product catalog with prices, tax codes, accounts and stock levels.
- Import a chart of accounts if you’re bringing one with you.
- Import bank statements, in your bank’s structured format or as a spreadsheet.
- Import mailing contacts for your lists.
- Download a sample file for whatever you’re importing, so the columns aren’t a guessing game.
- Map your columns to ours rather than reshaping your spreadsheet first.
- Preview before committing, and abandon an import that doesn’t look right.
- Export your customers and products, and every report, as CSV, XLSX or PDF.
How it works in practice
Start with the sample (Settings → Import). Pick what you’re importing and download the sample file. It has the columns in the right shape with the right headers, which turns “what does this system want?” into a spreadsheet exercise you can hand to somebody.
Upload, then map. Your file’s columns get matched to the fields they belong to, and where the names don’t match you say which is which. A file exported from your old system can be imported as it came out, rather than being rearranged by hand first.
Look at it before you commit. An upload is staged, not applied. You see what will be created, which is when the wrong column or the European decimal separator shows itself. Committing is a separate, deliberate step.
Do it in the right order. Customers before documents. Ledger accounts, tax codes and units before products. Products before stock. Anything a record points at has to exist first, so an import in the wrong order fails on the references rather than quietly making up the missing parts.
Bank statements are a special case, and a better one (Finance → Bank). Your bank’s structured export - the formats designed for exactly this - matches far more reliably than a spreadsheet of free-text descriptions. Either way, lines are previewed against your open invoices before anything is registered, and matched payments can be recorded as the import completes.
Getting data out is two things. Customers and products export from the same screens they import through, and every report exports to CSV, XLSX or PDF. That second route is the one most people actually want, because it carries the figures with the context that makes them mean something.
Good to know
- Not everything imports. Customers, suppliers, products, ledger accounts, bank statements, mailing contacts and document lines do. Historic invoices with their journals don’t, and neither do posted balances from a previous system.
- That shapes how you migrate. The usual approach is opening balances as a manual journal at a chosen date, master data imported, and history left in the old system for as long as you have to keep it. Agree the changeover date with your accountant before you import anything.
- Import creates, it doesn’t reconcile. Running the same file twice makes a second set of records rather than updating the first, and preview exists so that doesn’t happen by accident.
- Check your decimal separator and date format in the preview. A file written by a European spreadsheet and read as though it were American is the single most common import problem, and it’s completely invisible until you look at a total.
- Your data leaves with you, on every plan including the free one. Software that’s hard to leave stops having to be good.
- For anything large or unusual, do a trial run first. Import into a company you set up for the purpose, look at the results, then do it properly. It costs an hour and saves a weekend.