Reading this we need more details as not all is clear what and where things are done and fail on.

"when I used the token to configure, I could configure, however, I could never login as admin. Could not access database as a client user."

1) The token seems to indicate you did go to gwserver:9710/.../install which is not needed
2) The login seems not possible I believe as the gwadminservice is not running for the system you copied over, this can be a certificate issue, hostname issue or IP not the same on the new server so gwadminservice can not bind to this and therefor not load. 
3) Not sure what "Could not access database as a client user" means

"When I launched install.sh to configure, I did NOT choose the configure a new setup option. Instead, I chose to upgrade existing. Did I chose wrong?"

1) This seems correct as install.sh has two options "Install" and "Configure" but you only need to install the software so "Install" only
2) However not sure what you mean with this "the configure a new setup option" as install.sh as mentioned does not have "a new setup option"
3) The same for "I chose to upgrade existing" also install.sh does not have this
4) This all seems to point again to the gwserver:9710/.../install as mentioned thats not needed
5) As the article is saying the configure will be done by the copy of /etc/opt/novell/groupwise/gwha.conf to the new server as this means all is known when "systemctl status grpwise.service" is done ( as this uses the gwha.conf ). The domain(s) and PO(s) should show then on the new server, only then after the secondary IP (old server IP on new server) is added agents and gwadminservice can be started as they can then bind to this hostname/IP

No new system is created only the one already running is moved so the gwserver:9710/.../install has nothing to do with this, its also not mentioned in the article.

With the provided info im not sure where/what you have on the new server but there is a TID as well about moving you might have a look at as this has more steps and is more general as the article which assumes the IP/hostname stay the same and are on the new server after the data is copied. If this is not in your case the TID has more details how to handle this.

Well, your questions help. But clearly I made more mistakes than I thought.

1) I did get to gwserver:9710/.../install.  Mistake.

2) gwadminservice was running. So likely a certificate issue. I will troubleshoot.

3) Users unable to login to a running Groupwise system as usual. rcgrpwise status showed all systems running except gwias. But, users could not access anything. Likely a certificate issue.

---

2-4) if you configure using a token you get four options, first is to create a new system, second is to upgrade a system. I chose upgrade, but I need not have gone down this route as you indicated.

5) this is helpful as I copied over gwha.conf. However, I believe I corrupted it now by the mistake made in trying to configure. This may have corrupted certificates I copied over as well.

Here is probably where I went wrong. I could not use dbcopy. So I tried to manually copy everything in /grpwise to a smb network share and they copy to new server after running rcgrpwise stop.

Whenever I try to run dbcopy I get an error:

/opt/novell/groupwise/agents/bin/dbcopy -m -f /grpwise/gwpo /mnt
/opt/novell/groupwise/agents/bin/dbcopy: error while loading shared libraries: liboff_eng.so: cannot open shared object file: No such file or directory

The only way I could set a mount is with this command running from the running server:  

mount -t cifs //xx.xx.xx.xx/grpwise /mnt -o username=xxxx,password=xxxx

rsync has been my go to for such moves/migrations.  You do the big hauls beforehand, then after the agents are down, the final sync. 
It is an easy enough tool to learn, and useful in many other spots as a file syncing tool. Fairly standard on Linux, including more than a few NAS, and easy enough to get for Windows. I've been using it since NetWare days (org with 3 small offices, synced to the big one with the tape monkey).

I very much would like to know where things went off course to update that page you used.

Let's confirm a few things, that

- GW system is its own IP and FQDN, resolvable locally on both servers. Having them in the hosts file helps as well as your local DNS
- The certs were built on those FQDNs for each agent.
- the new system was restarted after GW install
- All the files referred to were copied (scp for the little bits, rysnc best for the bulk domain and PO) over the
- after or ever during the last syncing, that the GW's IP (as a secondary on each server) was deactivated on the source and then activated on the destination.

Well, I just now got DBCOPY to work. Issue with it was a combo samba permission issues and looking at old syntax posts which gave outdated info on how to run the utility. 

Now I am looking at rsync, which is another learning curve. Perhaps will be easier, but I do not like that it poses data loss risk. Seems very confusing sending files to IP address. Documentation I am looking at is SLES 15.6 administration_en.pdf. Completely insufficient in my opinion on how to use rsync.

No issues with GW system IP or FQDN resolving.

Did not use scp (not sure how it works or if it is destructive of data). However, I did manually copy every needed gwha.conf gwdva.dva and all the certificates.

I did change IP addresses on both servers.

My guess is the blog is fine as is (I just don't know enough), or could perhaps add links that are reliable on utilities like rsync and dcopy.

I prefer rsync wherever possible. In many cases I use rsync -avz --delete source target

I did a lot of GroupWise moves to new servers. It is so easy especially  if you do not have to change ip or dns. If one of the last two parts change, then it is a little bit more effort but still easy!

scp is as easy as those commands I have in the blog.  It is as about as safe a way as possible. Much safer than through a Windows box with active A/V running.   After all, scp is the 'Secure Copy Protocol'.

Yes, writing up rsync for this purpose would be useful, culling out all the way too many options and other ways of using it.   Basically having the service run on the destination, and the appropriate command on the sending/source side.

So based on trial and error, here is all I think I need using rsync from local to remote: 

rsync -avh /grpwise/ root@xx.xx.xx.xx:/grpwise/

It appears you got to have the trailing / on source and destination to copy folder and sub folder structures.

I will experiment with scp.

One final question before I try again (probably Saturday):

Since I tried to configure when I did not need to do so, will the transfer still work? [Presumably there was lesson learning in the past which lead to the reason my mistakenly ignoring your direction 'do NOT configure' caused the issue I experienced.]

If not, are there folders or files I will need to delete to get rid of bogus admin certificate or startup files I don't need or want? 

Look at each of the scp commands in the blog (opps, found a space in one of them, fixed now) and make sure the destinations have been cleared of the files being copied or newer.

Then try the scp commands to see how they work for you.

For the rsync command, you want to add '--delete' option at the end, because there will inevitably be removed files, especially in offiles, while the system has been running, and you want that synced over as well

rsync -avh /grpwise/ root@xx.xx.xx.xx:/grpwise/ --delete