Sometimes, users repositioning from old to new attract bugs in the very sophisticated act of converting data. This is ladyoncrmparticularly the case with customizations around things like designs of tables. A possible workaround here is to make a NAV backup of the NAV 2009 database and restore it into a new database that you’ll then be able to convert.
Often with table indexes — another territory in which errors have been known to crop up in upgrading efforts — users are told they have wrong or missing indexes or get indexes showing up as null. Solve this with the database check tool. For best results, run the command line tool and route the output to a text file. You can then search the text file for any occurrences of “Error:,” the prefix used for error messages.
Users can stumble, too, on performance variations according to the size of the database and customizations. Tackle these by, first, ensuring the existence of a maintenance plan on the older database, and by updating all indexes and statistics gradually. If you have lots of customizations and a huge database, divide the FOB into more than one package.
Beyond that, given that the duration and sync of the import are highly dependent upon the number of companies in a database, it’s clever to remove any unused and demo companies before launching the upgrade. While you’re at it, also kill any unneeded flow fields and indexes, and make sure there’s enough SQL server log space available.
Could be you encounter errors related to the naming conversion of your companies during your upgrade, particularly if a name contains a special character. An easy solution here is to rename the company before the upgrade and restore its name after you’re done.
With this latest version of Dynamics NAV comes the concept of upgrade codeunits. Here, the system advises users to employ upgrade codeunits if their instructed changes are determined to be destructive.