I think that this allows us to piece together an explanation of what you're experiencing.
Around the beginning of this year a security problem was found with the TLS-SNI-01 validation method (which uses port 443). This has to do with certain large shared hosting providers' configurations and might allow one user of a hosting provider to inappropriately obtain a certificate for a different user, in some circumstances.
Because of this, the use of this method was restricted by Let's Encrypt:
TLS-SNI can be used for revalidating and reissuing certificates for domain names that have previously-issued Let’s Encrypt certificates. This is limited to the account that issued the most recent certificate for any given domain name. It applies whether or not the certificate used TLS-SNI for validation. It applies only to fully-qualified domain names, not subdomains.
Since you have a new server, you presumably have a new Let's Encrypt account (the account is automatically generated the first time you use a Let's Encrypt client on a particular machine). That new account isn't eligible to use TLS-SNI-01 validation on port 443 because it isn't the most recent account that issued a certificate for your domain.
Your options are:
Find the account file in /etc/letsencrypt/accounts on the old machine and install it on the new server (removing the account that was automatically created on the new server)
Permanently unblock port 80
Temporarily unblock port 80 and issue a certificate, then re-block it (because then the account would be the most recent account to have issued a certificate for that name) (per @jsha's observation below, this method is not suggested because it may make your renewals fail again at some point in the future)
Temporarily or permanently use the DNS-01 challenge method instead to issue your certificate)
Note that -a webroot always uses exclusively port 80, not port 443. This has always been true for the whole history of the project. If port 80 has always been blocked on your server, you were presumably previously using -a apache, -a nginx, or -a standalone, which could have used TLS-SNI-01 on port 443.
Sorry, I meant to add a note discouraging this solution (because of the possible future stronger deprecation of TLS-SNI-01) and then I forgot to. I’ll refrain from suggesting this option in the future.
As it turns out, it appears, that the only reasonable solution is to the DNS challenge (I tried copying over the backup directory… but the renew relies on port 80) … To that end I’ve added the text record to my Godaddy DNS… it seems to have propagated to some servers but not others… the link that their tech support gave me shows the propagation… but mxtools does not… and Letsencrypt is not finding it… https://mxtoolbox.com/SuperTool.aspx?action=a%3Agregorigroup.com&run=toolpage#
When I follow the "Godaddy Verification Link" here, it has an extra %0d%0a at the end of the name, but anyway it doesn't return a particular Let's Encrypt challenge (whether or not I delete the spurious %0d%0a). Was there a particular challenge value that you were trying to post? Did Godaddy tech support tell you that that challenge value had been posted in your DNS zone?