Sage CRM Upgrades - Non Longtail

Over the years I have performed numerous Sage CRM (including Sage 200 CRM) upgrades and have frequently come across the following situation.  The client will be running an older server O/S, for instance Windows Server 2016.  On that server they will also be running the latest release of Sage CRM which is supported on that server, for example Sage CRM 2022 R1.

Sage CRM Version Windows Server
2016 2019 2022
2022 R1 X X  
2022 R2   X X
2023 R1   X X
2023 R2   X X

We encourage our clients to take regular upgrades, although it can be difficult to persuade them as an upgrade involves downtime and cost, both in terms of our time to perform the upgrade and in many circumstances a cost to upgrade their server to be compatible with the latest release of Sage CRM.  It should be possible to perform a direct upgrade from Sage CRM 2022 R1 to 2023 R2, no longtail upgrade required

You can use the Sage CRM 2023 R2 installation package to upgrade from versions 2023 R1, 2022 R2, 2022 R1, 2021 R2, and 2021 R1.

If a client is running Sage CRM 2022 R1 on Windows Server 2016 we would advise them to purchase a new server to run Sage CRM 2023 R2.  The client would then opt for Windows Server 2022 as this is the latest release of Windows Server.  However, In this situation there is no common server O/S support for both Sage CRM 2022 R1 and 2023 R2, even though a direct upgrade is supported.  As Sage CRM upgrades require an in place upgrade in order to upgrade the data either the current installation has to be upgraded and the data transferred to the new server or Sage CRM 2022 R1 has to be installed onto the new server, the data restored and then upgraded.  Neither of these options is supported.

The only supported mechanism is to have an intermediary upgrade server running Windows Server 2019.  So the upgrade process is

  1. Install Sage CRM 2022 R1 onto an intermediary server running Windows Server 2019
  2. Restore the Sage CRM data onto the intermediary server
  3. Perform the upgrade from Sage CRM 2022 R1 to 2023 R2 on the intermediary 
  4. Install Sage CRM 2023 R2 onto the Windows Server 2022 environment
  5. Restore the data from the intermediary server onto the Windows Server 2022 environment

The result of this is that an upgrade from Sage CRM 2022 R1 to 2023 R2 becomes quite a major project.  Any thoughts on this process and how to make it more efficient would be most welcome.

With other applications, for instance Sage 200, the process would be to install the latest release on the Windows Server 2022 environment, restore the data from the previous system into the environment and then upgrade it.  No intermediary server required, even if there is no commonly supported server O/S between the versions.

  • 0

    Hi Alison

    Admittedly I don't follow Sage's rules and perform an unsupported route. In the example given I would have installed 2023 R2 on the new server (this itself checks that the new environment is ready - I.e. Is IIS properly set up)

    I then overwrite the WWWRoot folder with the original, edit the registry to put in the Company / Key / Version of the original and then overwrite the database (and change the server name within it) 

    From this point I perform the upgrade. 

    I have pushed my luck before, going from 7. 3 to the latest at the time. Where once IIS was back up CRM 7.3 refused to work, but the installer could still recognise it existed and allowed me to put on the highest version I could jump to, then from there upgrade again to where I needed to be.

    In all cases the Upgrades have been successful (well for my last 17 years anyway) . So have stuck with this. And boiled it down to key versions to upgrade to if doing to long tail upgrade. The outcome is reduced time and need for intermediate servers. 

    My cavalier like attitude came from Sage 200 CRM days where we were suppose to do an upgrade step - link to Sage 200 to sync - do the next upgrade step.

    This was impossible to do logistics wise and we just sorted out the integration once all upgrades had been performed.

    One of the key things Sage have always said is that the supported software is only what it has been tested on. Not what it works on. Thus providing - whilst highly unsupported - a little wiggle room when upgrading

  • 0 in reply to Matthew Shaw

    My experience of Sage CRM upgrades is that if you don't carry them out as per the documentation then issues can occur.  This was especially true for Sage 200 CRM where the sync with 200 makes changes to the metadata.  So for instance if you had an installation of Sage 200 CRM which had never been linked to Sage 200 then if you tried to perform an upgrade of that instance of Sage 200 CRM then it would fail as some of the metadata was missing.  In addition if an upgrade is carried out in an unsupported manner then if there are issues and those are escalated up to Sage technical support then you may not receive any assistance.

    We have inherited a number of systems for other business partners where upgrades had not been carried out correctly which has resulted in major issues performing the next upgrade.  Often what happens is that when an upgrade is not completed correctly the upgrade itself appears to be successful.  It is then the next upgrade which fails as it is expecting the Sage CRM database to be in a certain state.  My advice would be that when performing an upgrade, especially a long tail upgrade, to fix any issues which occur even if they seem trivial as they have a habit of escalating the more upgrades you perform and then become a non trivial issue.  To that I would add that I always perform a test upgrade first as Sage CRM upgrades have a habit of producing errors and it is far better to understand these errors in a test environment and have a fix for them rather than trying to fix a live upgrade.  

    It would be good if there was a way to upgrade the data independently of the installer.  From what I understand the installer runs a number of es files against the database, why not have a separate utility which can run es files?  Upgrade complexities might seem to be only an issue for business partners but these complexities increase the time it takes to perform an upgrade which increases downtime and costs for the client.  This in turn makes then less likely to agree to an upgrade.

  • 0 in reply to AlisonA

    I love the idea of being able to upgrade just the database and not the application. Handle them as separate items. 

  • 0

    Hi Alison,

    For Sage CRM, the OS and SQL Server versions in the installation guide indicate the versions on which the release has been tested on. This doesn't mean that there are the only versions that may work - just it hasn't been tested. 

    It is possible to used older versions, but these may be out of support from Microsoft, and could lead to non CRM related problems.

    What is advised, is what Sage has tested and found to work. 

    I'm sure, as Matthew has indicated, there may be other routes that other BPs have used, but It would be impossible to test all possible route.

    Looking at matrix above, CRM 2022 R1 tested on Windows 2016/2019. Microsoft release Windows 2022 before CRM 2022R2 was release, so it was tested on Windows 2019/2022. Both release of CRM will actually work on all three versions of window, but as Widows 2022 wasn't released when the R1 version was tested, it was used and hence not 'Supported'.

    As going for 2022R1 to 2023R2 on the same server is permitted, it would be logical to assume a similar update using differ machine is also possible.


  • 0 in reply to Mario.Brazil

    In the past I have been bitten by "not supported means not tested", if it hasn't been tested then it is not guaranteed to work reliably in a live environment.  In an ideal world I'd like to install the latest release of Sage CRM onto the latest O/S then take the data from an older release on another machine, restore the data and then upgrade.  I suppose the complication here is also the wwwroot directory which also needs to be upgraded.

    I'm sometimes involved with Sage 200 upgrades and my process here is to install the latest release of 200 onto a new server, copy across the data and Sage share then simply perform the upgrade of the data on that new server.  This process works even if the data is from a version of Sage 200 which is many years out of date.  The important difference is that upgrading the data is a separate process to the upgrade / installation of the application.

    In the situation I descripted originally I use an intermediary upgrade machine which supports both the version of Sage CRM which is being upgraded from and to.  This works perfectly but is not very efficient.  There can be complications with longtail upgrades from ancient versions of Sage CRM where multiple intermediary servers are required.  From the thread above it seems that I am not the only person who would like to see the data upgrade as a separate process to the software installation.

  • 0 in reply to AlisonA

    Whilst I might bend the rules slightly during the upgrade process. I would always have the live environment within the supported products by the end of the process. 

    If I do use intermediary servers. It is only for CRM, as mentioned before if Sage 200 is involved it is upgraded on the new server. Where as I might take the CRM onto the intermediary server to upgrade it and move it onto the new server to complete the process - all without Sage 200 being on the intermediary server. We only then reconfigure the integration at the end - knowing it will reset lots of screens / lists (really hated this about the 'Classic Integration') and so part of the tidy up would be to put screens / lists back to how the customer wanted them after the upgrade.