During the AAP 2.6 Hackathon, I migrated my 2.4 cluster to 2.6, and then to containerized.

The containerized migration is essentially backing up all the artifacts of the RPM deployment, and installing the containerized platform on new systems.

There is some "magic" that happens with secrets in that process (eg: database encryption keys, etc.).  What I noticed is;  if you are missing some secrets in your initial installation, the installer will generate new ones.  This will cause various components of AAP to fail when accessing encrypted data in the restored DB.  You don't get helpful messages, just random 500 errors when, for example, you try to access the Automation Hub's Remote Registries (since they need the encrypted passwords).  The console logs dump errors like this: `raise InvalidToken", "cryptography.fernet.InvalidToken"`

Further, trying to fix this wasn't straightforward.  You can't just put the correct secrets into the installer, and run it again.  The secrets are created as podman secrets, and they won't be recreated by the installer.  If you try to delete the secret and put the correct info in there, the old secret will continue to be used because the containers don't automatically use the new secrets.  Stopping/starting the container doesn't fix this.  You need to remove the container, and then re-run the installer to have it re-created, since it's not created by the systemd .container file, just started/stopped.

I recommend documentation that helps customers troubleshoot this issue, and give solutions for it.  It is likely going to be something that happens in a lot of migrations, and it would be helpful to have documentation that explains how to recover.