I would check with your Sage 500 Partner to make sure that your 3rd party software and other add-ons are all compatible.

The biggest problem is going to be getting support if something breaks in 7.4. If you never upgrade the people who wrote your add-ons and APIs will have moved on and find it hard to support you. I do like the customizer improvements that you'll get but other than that there is not a lot of reason to upgrade (at least for us). There is one reason to not upgrade and that's the reduction in use of temporary tables for reporting. This caused us a few problems because we use some of the reporting stored procedures to build some of our cube data.

If it is one version to upgrade to (e.g. 7.4 to 2013) I would agree John. However, they are contemplating moving to 2014 or 2016, which is a bit more significant in regards to upgrading. First, there may be issues that were addressed in the current versions of Sage 500 that were not included in a Product Update for 7.4 that could be beneficial to have to avoid issues or improve performance. Upgrading also gives a level of confidence knowing the current version of Sage 500 will run on the currently supported operating systems and SQL Server. On April 12th, Microsoft support for SQL 2005 ends, so those companies who are running Sage 500 7.4 on this version of SQL would need to either upgrade SQL Server to a version supported by 7.4 or simply upgrade both SQL Server and Sage 500 to be as current as possible.

On the development side of things, if any custom tasks were built using the SDK, these would need to be presto'd through each version separately. The more separation between versions, the more work involved in this. A side benefit to upgrading is that if you build your own .NET tasks for Sage 500, you will be working with a more current version of the framework and can take advantage of its capabilities for new tasks or when you upgrade existing ones you might've built for previous versions.

Companies also run the risk of higher costs the longer they wait to upgrade to the current version of Sage 500. It is much easier to upgrade from a version that is supported by the current version of Sage 500. For example, a company is still using MAS 500 6.3 which has customizations built using the SDK and decided it wants to upgrade to Sage 500 2016. MAS 500 6.3 is no longer supported as part of the database upgrade. To upgrade from 6.3 you would have to upgrade to a version of Sage 500 that supported 6.3 as part of the database upgrade. Once this was successfully completed, the next step would be to upgrade that database to Sage 500 2016. As I mentioned before, any custom tasks built using the SDK would have to be Presto'd to each version between 6.3 and Sage 500 2016 which would take time and add to the costs.

Joe's suggestion is correct that they should check with their partner concerning the Add-ons and 3rd party add-ins. I would also suggest sitting down with their partner to discuss mapping out a strategy and a road map for upgrading that includes a pros and cons for doing so as well as potential costs for each version they are looking to upgrade to. This will give them idea what is involved, how long it will take, and if the potential ROI makes sense.