Hi, Eduardo. Unless you somehow accounted for that, your new Gluu Server has a different salt value used to reversibly encrypt clients' secrets (what includes oxTrust's client's secret as well, so you won't be able to login if you substituted it with the one migrated from the old instance). So unless you decrypted and re-encrypted these before importing your client, it won't be possible for oxAuth to read them properly. Salt is stored here: `/etc/gluu/conf/salt` To encode and decode the secrets you can use this tool: `/opt/gluu/bin/encode.py` (add `-d` for decoding) So one way is decode each secret running the tool inside original container and then re-encode it running the tool in the destination container - then updaing the LDIFs with new values. You could also try to install your destination Gluu Server using `setup.properties.last` file from your previous installation (it must be decrypted first as well in 4.x). For that you run `setup.py` with `-f` option to provide the file, as explained [here](https://gluu.org/docs/gluu-server/4.2/installation-guide/setup_py/). That should produce the same environment as original ones - but mostly useful when you need to create a copy of the same version. Using it for upgrade is very experimental. For your case, I would try next: 1. Take `setup.properties.last` from your current destination 4.2 instance (decrypt it) 2. Find "encode_salt=" parameter in it, and update it with salt you extracted from `/etc/gluu/conf/salt` file in your 4.1 instance 3. Install a new 4.2 instance using the updated `setup.properties.last` Then you should be able to migrate your clients into this new instance without further efforts.

Also, I would advice to migrate only clients you created, or at least modified. Don't migrate pre-packaged/system clients, like oxTrust's and IDP's clients, or SCIM or UMA related clients. I'm pretty sure that at least oxTrust's and IDP clients are referenced from other parts of configuration, so you would need to do a few more surgical updates, which are not covered by Community Support Also it's quite possible some small changes to layout of client's LDAP entry were introduced between 4.1 and 4.2, which may make them incompatible, so you may need to do a attribute to attribute comparison to figure this out. Excluding pre-packaged clients in this case will help you to at least keep access to admin console.