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

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.

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

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.

Regards

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.

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.