We have already discussed most of these practices in other chapters, but will review them here, in the context of coding to make it easier to upgrade. We won't be able to follow each of these, but will have to choose the degree to which we can implement low-impact code and which of these approaches fit our situation (this list may not be all-inclusive):

• Separate and isolate new code
• Create functions for significant amounts of new code that can be accessed using single codeline function calls
• Either add independent Codeunits as repositories of modification functions or, if that is overkill, place the modification functions within the modified objects
• Add new data fields; don't change the usage of existing fields
• When the functionality is new, add new tables rather than modifying existing tables
• For minor changes, modify the existing pages, else copy and change the clone pages
• Copy, then modify the copies of reports and XMLports rather than modifying the original versions in place
• Don't change field names in objects, just change captions and labels, as necessary

In any modification, we will have conflicting priorities regarding doing today's job in the easiest and least expensive way versus doing the best we can do to plan for future maintenance, enhancements, updates, and upgrades. The right decision is never a black and white choice, but must be guided by subjective guidelines as to which choice is really in the customer's best interest.