What tends to happen in cases like this is that your old setup has Jira connected to a specific IP/Address for Crowd in order to handle all the authentication. And since that address is likely changing due to this migration, the settings that handle this in Jira need to be updated to let these users login.
For this reason, I would recommend that you leave the Jira internal user directory enabled, AND have a Jira system admin level account in that user directory that is uniquely named (ie a username that does not exist in Crowd, LDAP, or other user directories). By having this kind of configuration, you can at least then ensure that you have at least 1 admin that can login even if Crowd fails or is unreachable for any reason.
One way through this would be make this change on your old system now, create the backups again, and restore these changes to the new platform.
However the more direct solution at this point would be to follow the steps in Retrieving the Jira Administrator. This document explains how you can find all the group(s) that have this Jira system admin permission. In your case, I would look for a user that exists in the Jira internal directory (has a directory_id value of 1). If you can't find an internal Jira administrator, the guide also has steps on how you can insert such a user account via SQL directly.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.