How to verify successful migration of NAV using SQL

Our company is migrating our NAV using SQL db from one hosting company to another. After we have successfully backed up and restored our data (NAV custom code, and NAV itself) how can we check (verify) if everything migrated correctly? For example, how can we verify if all the data came through, and the custom code we created in NAV all migrated correctly?

Are their built in tools in NAV and/or manual checklists that are best practices?

You create a SQL backup on the old machine and restore it to the new machine. Why would it be different? If you can’t trust your backup procedure (which I assume you have done every day since you started with Navision) you have problems far more serious than this to worry about.

As David said if you are creating a backup and restoring, upgrading or moving the database, the data and objects would not have changed as everything is saved within the database including new code and objects, but this type of auditing question does come up from the Finance Director or Finance Department, so you need to put it back to your end client to run the checks on their data.

They can run any number of General Ledger, Bank, Customer and Vendor reports, trail balances, statements, they can export, copy and paste into Excel etc, just before and just after the move, which will give the same values providing they run the same reports again after the move and before any new transactions are created.



Thanks for the answer. I was looking for verification metrics I could use to make sure the database was backed up and restored properly. Your report suggestion will do.


A SQL Backup copies the occupied “Pages” of the database 1:1 to the backup-file. Thus, a restore copies the BAK data 1:1 into the new database files; hence, both databases must be identical!

If you run a “verification” when the backup was created and no errors were reported, then the BAK equals the database for sure.

Of course you could compare the table content, but this shouldn’t realy be necessary (if you google “compare sql databases” you’ll find several tools for database compare). Anyway, you could/should run a DBCC CHECKDB after the restore to check the physical integrity of the database.


Hi Jörg, it is great as a technical answer and if the Finance department has full faith in the IT/IS department.

The answer may not be enough to satisfy the Finance Department as they are interested in the data and may require proof that no data was lost or altered during the move, so numbers is what they will understand, printing reports and reconciling these after is a good safegaurd for the people doing the move.

If anything did go wrong even if it was not as a result of a move or upgrade then who gets the blame, as this is an accounting system then the different departments should take responsibility for auditing the financial data before and after, even if it is not really required.

Financial Controller, AR, AP, Stock, Operations managers should run before and after reports for their departments and reconcile these before trading, thus taking resposibility for their departments data.

G/L Trial Balance, Aged Debtors, Aged Creditors, Inventory Availibility and Inventory Valuation reports are a few that may be required.


True. “Financial Guys” tend to be somewhat paranoid - no offence [8-|] - not trusting only in the “technology”. I agree that further reporting would probably give them the confidence and trust they need …