One suggestion is to do an upgrade migration to a new server in the domain (...doing an upgrade at the same time to save project costs overall, by pairing the server move with the upgrade, which involves a similar amount of effort as a pure server move).  That way you only need to get the trust relationship working server to server during the migration.  Low risk too, because you don't need to tear apart the source server to do it.

My guess for the SQL not enabled error would be name resolution... where you can use the server IP address in the Sage-SQL settings.

Thank you for the suggestion.  Unfortunately in my case I don’t think I can sell the business on an upgrade to SAGE, as a migration to SAP is on the roadmap, but security won’t let us keep the AD trust in place u til SAP will be ready.

Name resolution is a possible issue, I will need to get the network team to check it.  Would a change to IP require changes to the sota.ini on every client?

You can still do a migration to a new server, without the upgrade.  Same process, just using the old version's software installers to prepare the new server for the migration.  There are many little pieces that can go wrong, and it is best just to start fresh.  We've tried domain switches, and the amount of time spent dealing with issues... could have been greatly decreased by just doing a server change / migration.

Changing the SQL address should not involve touching clients.  Workstations connect with the Sage server, and the Sage server connects with SQL.  You have to use an address for the SQL server that can be functional for workstations though, because printing data access is done directly from SQL to the client (with SQL connection details sent runtime by the program).

Be sure you don't have any blocking firewalls between SQL/Sage/workstations... and add rules as required.  That is the other most common issue for SQL not enabled errors (in my experience).