Upgrading GN4 system to a newer build may be very simple, or very complicated operation. Mostly, it depends on three factors:
•The time frame since the last upgrade / the first installation: the longer is the period between two upgrades, more changes are to be expected in the new build, and therefore, more potential issues during and after the upgrade.
It is highly recommended not to postpone the upgrade very much. The best practice would be to keep your system aligned with the new versions with not more than 6 months delay.
•The percentage of customizing of your system: heavy customizations of your system (schema, custom scripts, workflows, XSL stylesheets) may cause issues during upgrade. The most typical case is that your old code uses the GN4 functionalities that changed in the meantime, so it won't perform in the new build as it did in the existing one. This also applies on custom add-ins: have in mind that if you're able to compile your custom add-ins with the new build, it doesn't necessary mean that they will work ok.
The testing of the custom parts before the final upgrade is essential for the success of the upgrade.
•The level of the testing of the new build before installing it on the production system: the best approach to avoid production problems after the upgrade is to test thoroughly the new build on a test bed with the copy of the production database. The testing should follow a complete sheet of the basic operations: data import, data entry, the most important operations on articles and pages, including wires, printing and publishing, using templates, and so on.
About changes in the software and configurations
The changes that can cause issues are:
•Changes in the standard functions (change of number of parameters, type of parameters, return values etc): they can cause your custom add-ins to stop to work at all or to work incorrectly, or can cause undesired variations in the standard operations.
•Removal of some standard functions: that can cause your custom add-ins, workflows and XSLs to stop to work, or to work incorrectly;
•Changes in user preferences (number of, syntax etc): they can cause that you have to update many users with the new preferences;
•Changes in standard variables, e.g. for file names or PostScript names: they can cause your naming conventions for the output files to become invalid;
See also