Migrating from Old Software Without Losing a Single Rial of History

Every exchange that has operated for a few years holds an invisible asset that doesn't appear on the balance sheet: its history. A decade of trades, transfers, settlements, and balances sitting behind every business relationship. When the talk turns to switching software, the first question in a money changer's mind isn't the list of new features; it's: "What happens to my records?"

That fear is justified. A bad migration burns the history. And burned history cannot be rebuilt.

Why "transferring the balance" is not enough

The simplest and most common mistake in migration is this: move only each account's balance as of today into the new system and say "from here on." On paper it looks clean. In practice it is a disaster.

Suppose a customer's balance today is 12,000 dollars in credit. You transfer just that one number. Three months later that same customer says "you counted that Esfand remittance twice." Now, to check, you have to go back to the old system, which is either shut down or nobody knows how to open. Was the number you transferred right or wrong? You don't know, because you didn't bring its backing.

A balance is the summary of a history. If you carry only the summary and leave the history behind:

• No dispute with a customer can be resolved, because the original document isn't available.
• The profit-and-loss report and currency position of prior periods become meaningless.
• Every audit or internal review hits a wall.
• The trust of a long-standing customer who believes "everything is in your hands" breaks.

A balance without history is a claim, not a fact. A proper migration transfers the fact, not the claim.

A proper migration has three conditions

A migration that preserves history has these three traits together:

1. Full history transfer, not a snapshot

Every document — from the first trade years ago to today — must come into the new system: trades, transfers, expenses, settlements, cheques. Each account's balance must be the result of summing its documents, not a number entered by hand. When it's like this, every balance is traceable back to its first document.

2. A provable rial-by-rial match

Migration must not be left to "a good feeling." After the transfer, you must be able to prove that the new system's balances are exactly equal to the old system's — account by account, currency by currency. This means a verification whose output is definitive: green or red. If even one account is off by a few cents, it must turn red and be found, not lost among thousands of records.

The mental verification table looks something like this:

If the second row doesn't match the first in every column, the migration is not finished.

3. A reference from every new voucher to its old one

After migration, every document in the new system must know what number it had in the previous system. This bridge is exactly what saves you three months later: when a customer disputes an old transaction, you open the document in the new system and see its original number. The argument closes in seconds, not with a dig through a dead archive.

A real example of scale

This isn't theory. The largest real migration done with Nexto exchange accounting software transferred more than 70,000 documents and 23,000 trades from an old system, and at the end the balance verification came out completely green — meaning every single account, in every currency, matched the previous system rial by rial.

The important point about scale is this: when a system can transfer 70,000 documents without a single rial of discrepancy, transferring the 5,000 documents of a mid-sized exchange is no longer a risk, it's routine. Migration should be something done right once and done, not a project whose discrepancies you chase for months.

To make automatic migration smoother, customer names and currencies can also be translated into several languages with AI on import, so that every customer's file is clean in the multilingual system from day one.

A checklist before any migration

Before you say "yes" to any software, ask these:

1. Is the entire history transferred, or only the balance? If the answer is "only the balance," stop right there.
2. After the transfer, how is balance equality proven? See the verification output, not a verbal promise.
3. Does every new voucher reference its old one? Without this bridge, future disputes are incurable.
4. After migration, whose data is it? Is the database in your possession without an exclusive lock, with a downloadable backup? If the new software also locks you in, you've only changed prisons.
5. How long does it take, and how many days does the exchange go dark? A good migration shouldn't shut down daily work.

Why data ownership is part of migration

Migration isn't only about entering the new system; it's also about being able to leave easily next time. If you're separating from your old software with difficulty today, the reason is that system held your data hostage.

The health criterion is this: software that relies on its own quality keeps your data open and exportable — a database without exclusive encryption, an automatic downloadable backup, and Excel and PDF output of every report. A customer who can leave at any moment but stays does so because of the quality of the balance, not a lock. To go deeper on this, see data ownership and backup in an exchange.

And if you're still working on Excel and thinking about migrating to a real system, first read why Excel doesn't work for a currency exchange so you know exactly what you're migrating from.

The general ledger report in Nexto — from any balance down to the raw entry

Conclusion

Your records are an exchange's biggest invisible asset, and migration is the moment you either preserve them or burn them. A proper migration has three pillars: full history transfer not just the balance, a provable rial-by-rial match, and a reference from every new voucher to its old one. When these three come together, switching software turns from a frightening risk into a painless upgrade.

Want to see what a migration with full verification looks like in practice? Build a dedicated demo with sample data and follow the path of a document from the old system to the new one.