How to avoid new tech debt issues after platform upgrades

[KarrieDash]

We recently upgraded to Zurich and ran into several bugs that were caused because the upgrade modified a few business rules or role permissions that we had configured.

Other than tracking these "customizations" and checking for them during the upgrades, is there anything else we can do to prevent our customizations from either breaking something in a future release or being overwritten/ignored? We have lost almost a month having to redo changes that were previously working on Yokohama.

For example:

We added a few Related Items to an Authorization Package record. After the upgrade to Australia, some of these Related Items were no longer visible in the CAM workspace. But, on the BCM workspace and in the Native View, the Related Items were visible.

We created a new group that granted users access to the Authorization Package & modified an out of box group, that allowed them to make changes. After the upgrade, both groups' ACL were modified and no longer granted edit access.

[glideFather]

ahoy @KarrieDash,

if you have any customisations during your upgrade there are upgrade conflicts where you must decide whether you accept the upgrade version (de.customisation, back to OOTB) or if you want to keep your custom version (skipping OOTB).

It is applicable to anything that is customised in your environment, usually there are hundreds or thousands of these conflicts with different priority. This is an important part of the upgrade and it cannot be overwritten "itself", there must have been somebody who accepted the OOTB version over the custom one.

What you should keep in mind is that customisation brings the tech debt demonstrated in a simple example:

- imagine a default business rule that has 25 lines of codes,

- you will customised this BR, so it will later have 40 lines of codes and completely different than the original 25 ones.

- SN ootb will enhance this business rule from 25 to 30 lines,

- your customised version has 40 and complete different, so you are not aligned in this,

- upgrade is comparing the new 30 lines version against your 40 custom and you need to decide if you want to have 30 lines with SN support of 40 lines of custom and no support...

It's a leading practice to create a copy of OOTB codes, deactivate them and make the customisations in the duplicate records. It will prevent from having the upgrade conflicts, but you will still miss the new features.

Hope it makes sense, let me know if you want to discuss further