how to migrate from tpam to pam

For me the most successful migrations use the migration process to actually carry out a full review of what the customer has and what they actually need. There can be a lot of baggage in an old PAM deployment.

If a review is carried out of what they have and this is tidied up to provide an accurate picture of what they actually require then you are in a good place to make sure that the new implementation actually contains good data.

The biggest issue that you face is that the TPAM and Safeguard models are very different. As an example. A TPAM partition is very different to a Safeguard partition. There is no concept of a collection in Safeguard. The TPAM discovery model is no where near as advance as the Safeguard one.

So while you can use data extracts/lists and scripts to get the data out of TPAM for things like users and groups, systems and accounts (great for a review process) you cannot directly migrate the permission model.

You can also script a full Password release from TPAM and upload these to Safeguard. Ok I guess if you want to go for a "Big Bang" change over but I have never found these to be successful.

Again for me a better approach is to build the Safeguard model, import the clean data you have identified that you can use, test with new the new Safeguard model you have created BUT with Safeguard not able to manage passwords and then work out your strategy to migrate. the users over. Maybe by platform type group, application etc..Then as users are migrated to the new solution their password are changed by Safeguard and most important password management for the migrated assets is disabled in TPAM.

If you have session capture in the mix then there are considerations around how this will be diploid as well. The Join between SPP and SPS works very well but once again there is no concept of this in TPAM so you have to build the correct access model for SPS into your Safeguard solution.

There was a scripted tool written by somebody from within One Identity floating about and I am not sure if it still is or if it has been updated. .

My experience of it was BAD! Some how the customer had got hold of it..I also found out after I used it that it was not supported by the One Identity support team either. This was not a great migration experience for me or the customer.

Again it was also limited in what it could achieve.

So to sum up, you more or less start a new installation of Safeguard from scratch. It is jut that you already have the benefit of a lot of discovered data to base your design on and a customer who actually understands what PAM is and what the requirements are.

A good understanding of both TPAM and Safeguard will help this process as well.

I suspect not what you were wanting to hear but I hope this helps a little.

Best regards

Tim

For me the most successful migrations use the migration process to actually carry out a full review of what the customer has and what they actually need. There can be a lot of baggage in an old PAM deployment.

If a review is carried out of what they have and this is tidied up to provide an accurate picture of what they actually require then you are in a good place to make sure that the new implementation actually contains good data.

The biggest issue that you face is that the TPAM and Safeguard models are very different. As an example. A TPAM partition is very different to a Safeguard partition. There is no concept of a collection in Safeguard. The TPAM discovery model is no where near as advance as the Safeguard one.

So while you can use data extracts/lists and scripts to get the data out of TPAM for things like users and groups, systems and accounts (great for a review process) you cannot directly migrate the permission model.

You can also script a full Password release from TPAM and upload these to Safeguard. Ok I guess if you want to go for a "Big Bang" change over but I have never found these to be successful.

Again for me a better approach is to build the Safeguard model, import the clean data you have identified that you can use, test with new the new Safeguard model you have created BUT with Safeguard not able to manage passwords and then work out your strategy to migrate. the users over. Maybe by platform type group, application etc..Then as users are migrated to the new solution their password are changed by Safeguard and most important password management for the migrated assets is disabled in TPAM.

If you have session capture in the mix then there are considerations around how this will be diploid as well. The Join between SPP and SPS works very well but once again there is no concept of this in TPAM so you have to build the correct access model for SPS into your Safeguard solution.

There was a scripted tool written by somebody from within One Identity floating about and I am not sure if it still is or if it has been updated. .

My experience of it was BAD! Some how the customer had got hold of it..I also found out after I used it that it was not supported by the One Identity support team either. This was not a great migration experience for me or the customer.

Again it was also limited in what it could achieve.

So to sum up, you more or less start a new installation of Safeguard from scratch. It is jut that you already have the benefit of a lot of discovered data to base your design on and a customer who actually understands what PAM is and what the requirements are.

A good understanding of both TPAM and Safeguard will help this process as well.

I suspect not what you were wanting to hear but I hope this helps a little.

Best regards

Tim

Thank you so much Tim, i perfectly understand your analisys and i agree. So thank you so much for all the informations and details that are so helpful!! 

Have a great we

best regards