Guidelines to customizations

1) Do as little modification into standard objects as possible (keep the new developed "modules" separate and use standard "interface" to connect it)
2) All changes in standard objects must be marked by some comments, if you are changing existing code, leave the original one (comment it out) and add new modified code after that block. Keep the changes to the minimum - it means just insert 1-10 lines of code, bigger block insert into some function, codeunit etc. and just call it from the correct point...
3) If you want to modify standard reports, it is better to copy them under customer IDs and modify them there

these are just the main one, I am sure, that others will add additional points...

"Standard" interface I mean posting codeunits etc...

Adding fields is not problem, you add them, they are in separate ID range, merging them when upgrading is easy. Much harder is to make correct C/AL code which is added because this new field (filling some new field during posting etc.).

I will split the changes which are done into categories:
1) C/AL code changes
2) Visual changes - adding/deleting/changing editboxes and labels on reports and forms, changing dataitems etc.
3) Data model changes - new fields, changes in existing fields (data type, size)
4) Localization (translations of strings, field captions, button captions etc.)


Class 1 changes are the main source of problems during upgrade. Must be done correctly with focuse to easy reading of the code and that the change must be easy to recognize from changes made by the upgrade (changes of code between e.g. SP2 and SP3 are not commented, it means, all uncomented changes will be recognized as changes made by the upgrade, all commented changes are customizations...)

Class 2 changes are hard to merge, because in many cases you do not know why the field was deleted from the form (if it was not there, if customer wanted it etc.) and all the changes must be rethought, if they are still needed etc. Good documentation "what+why" it was done is good source of knowledge for you when upgrading.

Class 3 are easy to merge. Fields can be transfered without problem (you will have problem if there is some bigger change between the versions of NAV - for example the value entries were added between 2.60 and 3.xx versions and this changed the application logic...). In some cases you need to do own "migration toolkit" to correctly migrate the data into new structure. All changes on standard fields must be documented to be sure, that the change was not made by mistake etc.

Class 4 changes can be upgraded through exporting and importing language module, if the ID's of texts etc was not changed. You just needs to keep all text strings for translation in Text constants (global, not local), you never knows when you will need to translate the application into another language (for example, when the company will merge with another etc. ;-)).

This documentation is useful too :
http://www.mibuso.com/dlinfo.asp?FileID=598