Retrieving and committing update sets between different versions or patch levels - Support and Troubleshooting

Retrieving and committing update sets between different versions or patch levels Issue This article offers guidelines for how to retrieve and commit update sets between different versions or patch levels. Resolution For best results, always attempt to move update sets within at least the same family version, if not the same patch version, only. Since code changes between family versions, and sometimes quite drastically, it is highly recommended that admins keep updates created in Family A to being committed to Family A; otherwise, unexpected results can and often occur. If you need to move update sets between versions or patches, there is some amount of backward compatibility built into the platform that allows for the movement of updates from an older version into a newer version, including moving from an older family to a newer family (for example, from Calgary to Eureka). When attempting to link older version instances to the latest version instances, admins do receive warnings indicating the versions do not match. This is a warning only; the admin could pull the update sets over if the warning is ignored. Keep in mind that some updates may not commit properly because of code changes, so the admin should fix forward in these cases. Anytime an admin is trying to move updates from newer family versions into older family versions (for example, Eureka into Calgary), be aware that this is not supported by ServiceNow in any circumstance. Because of the same code changes mentioned above, the older instances do not know what to do with the new code. This results in the majority of the updates being ignored during commit. Additionally, those updates that do commit may overwrite the original code with functionality not supported by the older instance.