Deploy a new 23.4 and then use the iprintconfig.zip  from 4.2.13 appliance method to migrate from 4.2.13.

1. • Copy the iprintconfig.zip to the new server
     • When prompted to go to the https://<address>:9443 page:
       • enable SSH
       • log in at the terminal session as root, and type:
         • rcsshd start
       • connect to the server using WinSCP
       • browse to the /vastorage directory.
       • create a folder named:
         • backup
       • copy the iprintconfig.zip file to the /vastorage/backup directory using WinSCP
   • Go to https://<address>:9443
     • Because the iprintconfig.zip is copied to the /vastorage/backup directory, a message will read:
       • Previous appliance configuration detected
         
         Go on with migration. Once migrated, you can upgrade to 24.4 thru product upgrade menu.

So I went through and did this but now when I try to print it is saying submission failed.

install the latest support plug in:

zypper in -f supportutils-plugin-iprint

The type:

iPrintInfo -b

authenticate using admin.iprintappliance user

This will create a txt file on current directory with all config and logs and probably the error will show there.

as you're coming from an old version, verify if your Root CA is not using sha1 algorithm. for that, type at console:

keytool -list -v -keystore /vastorage/conf/certs/keystore -storepass "changeit" > /tmp/jetty.txt

this will put the info over the CA into the jetty.xt file. Check if it is using the SHA1 signature algorithm, then follow this document to recreate it:

https://portal.microfocus.com/s/article/KM000021381?language=en_US 

 assume that your new appliance has been deployed using the same hostname and ip address as the old 4.2.13 as this is a requirement when migrating the appliance.

So our root CA is a wildcard cert that we purchase and not the default one that comes with the appliance, does that matter? 

For those commands you suggested I run, do I connect with ssh and run them or in cmd of the vm?

Yes it matters.  The external ca is only used in browser/console communication.  Internal secure communication still uses the self-signed certs. But check as well that your external root ca and intermediate ca do not use sha1 as well as certs from gooddady and digicert are being sent to customers with old ca using sha1

Does not matter.  I feel more comfortable using ssh but it is a personal preference 

They are about the same.  So it is more a matter of preference. The advantage of SSH is that we have more options to logging what you do.  I use PuTTY, and set it to save all printable characters to a file with a date-time stamp for each server.  Makes checking back on "what was that command?" or when did I do that thing?" so much easier.

This is what happnes when I try to run the command to check the sha1 but when I connected with filezilla it says the fingerprint is sha25

The message is normal,  nothing te be worried. The created jetty.txt file should show if sha1 is used. It is the signature algorithm using sha1, not the fingerprint. It is a different thing