I have a client who’s on the verge of upgrading from SLX LAN 7.5 to 8.2, with extensive customizations to their forms and scripts. So I finally wrote down the steps involved in doing that.
A customizations upgrade starts with running the Customized Plugins Query against your current database, to get a list of your customized plugins. Then you ideally want to have two other SLX deployments, to compare your current scripts against, and find the differences: An OOTB version of 7.5 (or whatever version you’re currently on), and an OOTB deployment of the version you’re upgrading to (presumably 8.2). The rationale is that any OOTB plugins you haven’t customized won’t show up in that query, and will correspondingly go through any version upgrade without their (not-present) customizations being overwritten with the new release. Likewise, any fully customized plugins (e.g., anything prefaced with “C_”) can’t, in principle, get overwritten by anything in the new SLX. So you (and that SQL query) only care about plugins that began as OOTB, and were later customized by yourself and/or your BPs.
Then, for each of the form/script/mainview plugins returned by that query, you copy the entire current-version code out of the customized form/script into Word (or Notepad). Do the same with the corresponding 7.5 OOTB and 8.2 OOTB versions of the plugin, into separate Word or text files. You then run up to three text comparisons between those three files in Word, as explained in any of the SLX upgrade documents, using the Review tab > Compare > Compare feature. That will highlight (in red) the differences between the Original (OOTB) and Revised files. (In Word, a red strikethrough in the output file means the line has been removed from the Revised file, compared to the Original; while red code text in that output file without a strikethrough means the line has been added to the Revised file):
i. 7.5 OOTB code [Original file] vs. current code [Revised file]
ii. 8.2 OOTB code vs. current code
iii. 7.5 OOTB code vs. 8.2 OOTB code
For each plugin, you then do a human evaluation of the “changed lines of code” highlighted by Word, to determine which way of doing things (out of the three below) would be the least effort, to wind up with your custom code merged with the 8.2 OOTB code:
i. If only a small amount of custom code has been added to the 7.5 OOTB, then copying and pasting the same code into the 8.2 plugin is usually the easiest.
ii. If only a small amount of new SLX code is present in the 8.2 OOTB plugin (vs the 7.5 OOTB), esp. compared to the quantity of custom code in your current customizations, then copying and pasting the new (differential/red Infor) 8.2 OOTB code into your current 7.5 plugin is usually the easiest.
iii. If Sage/Infor have made a lot of changes between their 7.5 OOTB and 8.2 OOTB, you’d usually start with the 8.2 OOTB plugin, and copy-and-paste your current custom code into that.
A lot of those evaluations typically just come down to how much “red” is in each of those plugin comparisons, and choosing the path with the fewest changes. If Sage/Swiftpage/Infor has made changes to the form layout/controls since 7.5, based on the (not particularly reliable, in the details) change logs in the upgrade PDFs, that of course also factors into your evaluation of the “fewest changes.” Also factoring into your decision is whether Infor’s code changes “step on” your customizations, or vice versa—i.e., whether it’s easier to merge your customizations into the Infor changes, or to merge the Infor changes into your customizations. There will be some plugins where the decision is obvious, and others where it’s a tough judgment call.
For non-scripted plugins (e.g., reports, picklists, navbars, menus, toolbars, and groups), you have to rely on the upgrade PDFs, to find which of those have changed. Even there, though, SLX again can/will only update the OOTB plugins. So unless you’ve modified those without changing the names, there’s no effect on them during the upgrade. (If you have modified them, then you’ll need to do manual comparisons in Architect, to see what pieces Infor [and you] have added, and what is the easiest way of arriving at an 8.2 version with your changes merged into it.) That is half the reason why custom plugins (e.g., new menus and toolbars) are prefixed with “C_”, rather than making the changes directly in the OOTB menu plugins.
Before actually making the above changes in your plugins, upgrade a copy of your current database to 8.2, so you can make all of the above-determined changes in there. (SLX sometimes changes ActiveX control versions in upgrades, so you can’t just make the changes in your current 7.5 and know for certain that they’ll work in 8.2 … even though I’ve never yet seen them break a control interface in an upgrade. The latter is why it works to start with the current 7.5 forms, and add the differential 8.2 code to them [in “ii”, above], when that’s determined to be the easiest approach. Your current 7.5 customized-from-OOTB forms, of course, will still exist in that upgraded database, they’ll just have been unreleased by the upgrade. So for plugins where you go with the “ii” approach above, you’d obviously need to manually re-release them.)
Then create a bundle of all the plugins you’ve just changed in your upgraded 7.5-to-8.2 database, to apply to your (copy of the current 7.5) testing environment. (You can get that list just by querying the Plugin table, and ordering by descending ModifyDate or the like.)
There are no other special tools or knowledge that any BPs have, for doing upgrades.
Posted by Geoff 
GeoffLogix 