Cognito user pool migration

you can check the following links for migration

1. https://stackoverflow.com/questions/42187188/can-you-migrate-aws-cognito-users-between-user-pools
2. https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pool-managing-errors.html
3. https://community.jitsi.org/t/default-timeout-for-authenticated-users/17664

in summary

Migrating users from one AWS Cognito User Pool to another one can be achieved in different ways, but it's not supported directly by AWS Cognito. One approach, as suggested on Stack Overflow, is to modify your client to do the following:

On failed sign in with the new user pool, attempt sign in with the old user pool. If the sign in with the old user pool is successful, use the username and password that was submitted to create a user on the new user pool. Optionally, do something to remove the user from the old user pool or mark the user as migrated. Regarding the "NotAuthorizedException" or "Invalid username and password" error you're encountering, it could be due to a few reasons:

Incorrect configuration: Ensure that your application's configuration to connect to user pool B is correctly set, including the Userpool ID, domain url, and client ID. User existence errors: Amazon Cognito has a feature PreventUserExistenceErrors which returns generic error responses to mask the actual cause of the error. If this setting is enabled in your user pool, it could explain why you're seeing a generic "NotAuthorizedException" error. When this setting is enabled, sign-in and forgot-password APIs return a generic authentication failure response. The error response indicates that the username or password is incorrect even if the actual issue is different​. To further diagnose the issue, you could:

Use AWS CloudWatch to review the logs of the Lambda trigger function. Check the application logs for any additional details about the error. Test the login functionality with a user you know exists in User Pool B to check if the issue is related to user migration or the login functionality itself. It's also worth noting that when a user is migrated to a new user pool, any session the user had with the old user pool will not be carried over. Depending on how your application handles sessions, this could potentially affect the user experience.

As for the Jitsi part of your question, it's possible to change the timeout for authenticated users by setting org.jitsi.jicofo.auth.DISABLE_AUTOLOGIN=true in the sip-communicator.properties file, but the exact effect of this setting seems to vary based on the application configuration and user feedback​.