Tip of the Week #145 – How to Take Care of Data Upgrade Errors – Before You Upgrade
This week Developer Peter Tijsma shares a newfound method for preemptively finding and correcting those errors which so often occur during an upgrade; Errors that lead to downtime for the customer, and tedious overtime for you.
How to be prepared for any data upgrade errors way before you do the actual upgrade
When doing an upgrade of a customer from version NAV2013 or higher to NAV 2017 or NAV 2018, you have to – at one point – run the CmdLet Sync-NAVTenant. This process will process table schema changes that happened during the Application Code Upgrade.
Even though you’ve probably prepared your Upgrade Toolkit very thoroughly, you’ll find out during this process that there will be synchronization issues, because you by accident for example missed one custom field in a standard NAV table, or a deleted custom table.
These kinds of issues are especially not the ones you want to encounter during the Upgrade Process. The customer is pushing you to do the upgrade as fast as possible – preferably yesterday instead of today… And so you’re scr*wed and have to work late hours to get all done.
But don’t be afraid, there is a way of preventing this from happening on beforehand!
These are the steps needed to find any issues beforehand that might occur during the Sync-NAVTenant process:
1. Make an export of all objects from the original database to a fob file
2. Restore those objects in a new database created with the Development Environment of the new NAV Version (Sync Later)
3. Attach a NAV service-tier to the new database
4. Run Sync-NAVTenant on the new instance with Mode ForceSync
Sync-NAVTenant -ServerInstance Working110 -Mode ForceSync
5. Delete all objects from the database (Sync Later)
6. Import all objects from the Upgraded Application Code database into the new database (Sync Later)
7. Import the Standard NAV Upgrade Toolkit based on the original version into the new database (Sync Later)
8. If the source and target databases include PrintVis: Import the PrintVis Upgrade Toolkit for the correct version in the new database (Sync Later)
9. Import your own Upgrade Toolkit (based on what you found in the old database) in the new database (Sync Later)
10. Run Sync-NAVTenant on the new instance with Mode CheckOnly
Sync-NAVTenant -ServerInstance Working110 -Mode CheckOnly
If you did the job of creating your Upgrade Toolkit correctly, PowerShell will not report any issues and you’re good to go.
But chances are it might find that one custom field in a forgotten NAV Table or that one forgotten custom table.
This way you can now modify your custom Upgrade Toolkit to handle these missing fields / tables the correct way before doing the actual upgrade.
The beauty of this method is that you don’t actually need to have the customer database with all data to check it. A simple fob file with all objects from the customer is fine!
We’re now using this method to upgrade existing PrintVis customers to NAV 2018 and move all the modifications to Extensions V2. Since all custom fields and tables will also be part of the Extension and not of the base product anymore, we need to handle all those deletes in a quick and easy way.
This way of working provides us with a complete list of all we need to build our Upgrade Toolkit to:
- Create a Codeunit to handle the Table Synchronizations required to move all data to temp tables
- Create an extension Codeunit to run after the Extension is published so all data can then be copied back from the temp tables to the extension tables
Thank you Peter!
Are you a print company running an old print MIS from the Stone Age? Are you a PrintVis Partner with customers still running NAV 2009? Upgrading is much easier than it used to be – and now upgrading will potentially save customers significant money – not to mention all the powerful new functionality they’re missing… Get in touch with us today and let’s make 2018 the Year of the Upgrade!