In this video, I show why there are no excuses for not using upgrade codeunits. Check it out:
You can upgrade from one major version of Business Central to the next. However, minor updates are regularly made available for each major release, like 18.11 or 19.6. Whether you’re upgrading from one on-premises version to another, or you’re migrating to Business Central online, it’s important to target an update versions that are compatible with your current version.
One of the things I spent most of the september month on was to find and document a way to make upgrades from NAV to Business Central easier.
The good news is that we found a way to make upgrades up to 80% cheaper and to almost completely eliminate the dependency on highly skilled developers which in our ecosystem is the resource type that is the most difficult to find.
Recently, in our product, we enabled support for the new “Item References” in Business Central. Basically meaning: when upgrading to the new version of our product, we wanted to:
-Make sure our code supported the new “Item Reference” table in stead of the old “Item Cross Reference” table
-Automatically enable the “Item Reference” feature” (necessary, because when your code depends on this new feature, it has to be enabled ;-)).
-Automatically trigger the data upgrade (which basically transfers all data from one table to the other)
Obviously, this is all done using an upgrade codeunit. And this made me realize that there are some things that might not be too obvious to take into account when doing things like this
Recently, we have been going through upgrading our 65 apps to the newest release (v17). You might wonder: upgrade? Wasn’t this supposed to be seemless?
Well, let me explain what we did, how we handle stuff internally – and then maybe it does make sense to you why we take the steps we took for upgrades like this.