How to switch expense trackers without losing your history

Export before you do anything else

Export from the old tracker while it still exists.

Mint's shutdown in 2024 is the example everyone cites. Users who had not exported when the announcement landed had a limited window, and users who found out late had nothing. You cannot ask a shut-down app for your data later, and a subscription you cancelled may lock the export behind the tier you just left.

Export first, open the file to confirm it works, and only then start the migration. Even if you decide against switching, you now hold a backup you should have had anyway.

Read the header row before importing anything

Open the CSV in any spreadsheet or text editor and look at the first two rows. Four things decide whether an import works:

Five minutes here saves an import you have to unpick afterwards.

Map the columns explicitly

Automatic column detection is right most of the time, which is what makes it dangerous. You stop checking.

Chillar's guesses the mapping from the header row, then shows a live preview of the first rows as you adjust it, so you can see a wrong guess before it writes anything. Guided flows cover nine common apps (Ivy Wallet, Money Manager, Wallet by BudgetBakers, Spendee, Monefy, 1Money, Bluecoins, KTW Money Manager and Financisto), each carrying that app's delimiter, date convention and column names.

Confirm each mapped column against the preview. If a row shows an amount of 3 where you expect 3,000, the decimal separator is wrong. If dates cluster in the first twelve days of every month, the day and month are the wrong way round.

Import once, then check the row count

After importing, compare the number of transactions created against the number of data rows in the file.

They should match. If they do not, the importer skipped rows, and every skip comes with a reason: an unparseable amount, a missing date, or a header repeated mid-file. Read them. A handful of skips points to junk in the export, where hundreds point to a mapping problem.

You can re-run an import. Chillar's derives each imported row's id from the import and the row number, so re-running the same file updates the same rows instead of duplicating them. Start a fresh import of the same file and Chillar's treats it as a new import, because sometimes that is what you mean.

Verify three balances by hand

People skip this step, and it is the one that proves the migration worked.

Pick three accounts: your largest, your smallest, and one you rarely open. Compare each balance in the new app with the same balance in the old one. If all three agree, the import landed in full, since an error large enough to matter would have had to miss all three accounts.

If one disagrees, the difference comes down to a single category of row: transfers imported as expenses, or a currency that did not convert. You can find both by filtering that account's history to the period where the balance first diverged.

What does not come across

Every migration loses something. Expect these:

• Attachments and receipts almost never survive a CSV export, because CSV has nowhere to put them.
• Transfers often export as two separate rows, and most importers, including Chillar's' CSV importer, bring them in as an expense and an income without reconstructing the link.
• Per-row tags and currencies often get dropped by the exporting app before you ever see the file.
• Budgets, recurring rules and goals rarely appear in a transaction export. Plan to recreate them by hand. There are fewer than a dozen.

Coming from Ivy Wallet, use the backup .zip rather than a CSV. It carries accounts, categories, tags, transactions, planned payments, loans and budgets with their original identifiers, so none of the above applies.