I can see where your concern with the migration is coming from, however it is slightly misguided.
In fact, user database migrations between IAM and authentication providers are commonplace.
Let’s start with the GDPR mandate.
There should be no way for any external threat actor to access the data of your users on either side. And, if they did it would be useless because your hashing algorithm is not available to them.
Despite the fact you comply with this ruling, your team could theoretically access this database of users and extract them in plain text at any time, just by virtue of having access to your environments and knowing any encryption keys.
As such, a migration creates no new threat of breached PII.
How to achieve this?
So, if your team or the vendor have some way to know the salt/hash mechanism from (a), you should be able to use that as a secondary mechanism on (b) and migrate the encrypted list of users (passwords and all) in the new solution.
And If we assume the following:
- Your team will act with integrity
- Any vendor will act with integrity
- You do not expose the data to the world (S3 bucket) during migration...
You should be good to go!
Actuating the change
At a high level I can think of a couple options such as a csv export, database migration or a script to pump through your existing DB and update each record in the upgraded solution.
My personal preference would be to do a complete DB migration to the upgraded solution, then a separate change to migrate the hashing mechanism.
I suggest engaging that vendor for their suggestion on how to best approach this.