It really depends on how much you are pushing the existing box. 

What does free and top say?
 - if 'free -m' is showing lots of used Swap memory, more would be better. Especially if it gets used soon after a reboot. More is not a bad thing as mail volume/size grows, even if to cache all the DBs vs having to wait for storage.
 - running 'top'  press the number 1 to see what the existing CPUs are running at, both during a typical day, and especially Monday morning, and if you can when it is running the regular GWChecks.   Watch the 'load average' at the top as well, how high do those numbers go way up. Occasionally when something big is done, high is OK, especially if spread out on the CPUs.   It those core are all typically busy, then clearly more cores needed, unless the CPU lines show high 'wa' numbers (waiting on something)

on the RAID front, hardware is better than software, and to watch on that front as there are more than a few systems that claim RAID1 hardware, but hidden that it is only for Windows, even if the box otherwise officially supports SLES just fine.

I think you will get some more feedback. 

Most important part in my eyes is disc speed.

Tell more about your gwcheck runs! If you run a contents check on your GroupWise (which should run on regular base), how long does it take? I think that is a good part to measure your system.

do you not use virtualisation? VMware 7 or 8

Then you can configure your new server as you want

I had no experience with sles15.6, only sles15.5 or oes24.3!! OES offer clustering, also for groupwise on nss volumes

cg

Thanks much to all responding. Interestingly, out of the total memory of 15704, the amount free and available is 13187. It seems to use just 1 and sometimes 2 cores. Even running the gwcheck (which usually takes 6 minutes; the longest was 12 minutes), the system is not breaking a sweat. I am thinking that a faster disk would be the only change that would boost overall user experience. Otherwise, likely no benefit from new hardware.
 

Is that for a full PO contents check?  Seems so small/short compared to the sometime 24 hours I've had to deal with, but 11GB+ of DBs will do that ('only' 1TB of offiles)

I wouldn't recommend VMware currently. How Broadcom is handling support now is extremely problematic, especially for smaller clients, such as for this poster's office.

I'd like to throw an idea around, perhaps a refurbished system. Server consisting of 2 CPU sockets, NVME Raid 5 with server SSD read / write balanced, 256 GB RAM and 10 GB network cards that can also do 1 GBit. Plus 2 power supplies. Operating system Proxmox VE. Proxmox Mail Security and Proxmox Backup VM can then be conveniently set up on the system. Probably an acceptable solution for an SMB store

George

Well, for better or worse, I have users set to auto-archive after 30 days, so the database can get quite small. The best I can tell from analysis is to skip the hardware upgrade or possibly move to an SSD (which I don't trust right now).

Hopefully your Retain endeavour is working out, but that certainly explains the nice and tight GWCheck times.

Given the age of the hardware, a refresh might be a good thing if just for stability and repairability (parts?). Just getting to redundant drives on a new box would help a lot on that front.  

Also, a good time to think of some sort of virtualisation. There are many options out now that are worth considering. Assuming a few other servers are already in the mix, advantages are having fewer physical boxes, but with faster recover if there is a hardware failure. All my cluster services clients switched to virtualisation as easier and more flexible than the cluster services, while giving them the hardware redundancy they really wanted. 5-10 minute switch over is all they really needed, rather than the seconds of cluster services.

It sounds a little bit dangerous to me. 

DH2 said:

users set to auto-archive after 30 days

If the user is able to set it, then you are using GroupWise archives - to local discs or network drives. GroupWise archives are smart but somehow outdated. But using Retain archives is a lot smarter ...