I haven't heard of any PowerCenter related functionality which would have changed from 9.6.1 to 10.2. Nothing.
We also have tried the handling of LDAP security groups at several customers and haven't seen any changes in functionality between these two versions. Everything works under 10.2 as it did under 9.6.1.
As far as I understood the support statements, there shouldn't be any issue with moving from on-premise to an Azure platform.
As far as I have heard, the "danger" that a platform change from e.g. AIX or Linux to Windows (in this case, Azure) incurs any changes in behaviour (such as the need to replace shell scripts by Windows batch file, PowerShell scripts, or command scripts) is far higher than that the switch from on-premise to Azure might cause.
All in all my experience and everything I've heard so far tells me that there shouldn't be any issues with such a switch.
Of course, if they insist on getting any written material, they should raise a service request at Informatica Global Customer Support to get written confirmation. I am just 100% confident that GCS will tell your customer nothing else than you already did.
Thank you very much for your replies over the last few months. They have been extremely helpful.
My apologies as my next question should have been included in my previous email and it completely slipped my mind.
The same client is concerned if there are any changes to the Informatica repository. They have created a homegrown lineage system that is heavily reliant on the Informatica repository. I have read the release notes for 10.2, it states that changes to the repository seem to be limited to file directory locations and one other thing I can't remember off the top of my head.
Are you familiar with any other changes to the repository?
Also, seeing we are standing up a new version of Inforamtica 10.2 in Azure, they are currently on 9.6.1 HF 3.
Would you stand up 10.2 and take a backup copy from 9.6.1 or would you stand up 9.6.1 use the back up copy and then upgrade to 10.2?
Thank you again Nico!
No problem at all, I'm happy to help when I can.
Of course there are some changes in the repository structure. The big question is whether these changes affect their homegrown system, and that's a question which I simply cannot answer because I don't know how exactly they built it.
If they built it on top of the MX views and maybe XML exports (though unlikely this would solve certain problems), then the answer is simply "no danger"; the changes in the XML export structures are VERY thin according to all I've seen so far, and the MX views have been very stably for the past 16 years (with one single exception, and that was that the view REP_GROUPS has been dismissed in v8.5 when the user management has been moved from the PowerCenter repositories to the Informatica domain)
If, however, they built their lineage system on top of the tables, then I have to say: their own fault. Informatica strictly instructs its customers and all partners since at least 16 years to NEVER touch the repository tables, and even I have found not more than maybe 5 cases where repository contents are available only in the tables but neither in the views nor in XML exports. So there was barely any need to extract from the repository tables. Whoever does that always does that at their own risk.
This is one of the typical risks when not following the guidelines established by software vendors.
Again, assuming that they did follow this approach.
Should they encounter trouble with the new repository structure (though not very likely), they may consider using the Metadata Manager (MM, not to be mixed up with MDM, the Master Data Management suite) which can provide complete unbroken lineage informatica for PowerCenter mappings.
And - depending on their license - they may already be entitled to install and use MM, but that's a question for their Informatica sales representative.
Now on to your second question. Not sure whether I understand it correctly, so please bear with me if I'm on the wrong track here.
If I understand right, you want to know whether they should first move the 9.6.1 installation to the Azure server and then upgrade it to 10.2 or whether they should install 10.2 on Azure and then "copy" the repositories.
Personally I would prefer to install 10.2 on Azure, "copy" the individual repositories in 9.6.1, and then upgrade them in 10.2 (on the Azure server). That will enable parallel tests in both environments.
I am migrating my client to the cloud, Azure to be specific.
While migrating, the on premise version of Informatica will be on 9.5.1. The cloud version will be either 9.6.1 or 10.2, depending on where we are in the migration path.
I am being told that there is a possibility that the on premise will not freeze their code going into on-premise production. They want a mechanism in place to take the older version 9.5.1 workflow and get it into the newer version in the cloud.
Are you able to export an XML file in Version 9.5.1 and Import that same XML file into Informatica 9.6.1 or 10.2? I'm thinking that this won't work but need specifics.
It's not allowed. Many people have done it in the past, in most cases it worked, but not in all cases.
Definitely it's not allowed nor supported by Informatica to import a XML version x into a repository version y, not even from 9.5.x to 9.6.x
The only supported way is to set up an "interim" repository DB / schema which will be used for this deployment and upgrade; first set up a fresh repository in 9.5.1 in this schema, move the objects to be migrated, then upgrade this repository to 9.6.x or 10.x, and move the objects from the interim repository to the "final" repository. Afterwards you can remove the interim repository's contents.
Not nice but the only supported way.
In fact my suggestion is to set one final date when everything will be migrated. On this day, the 9.5.1 installation is "frozen", the repositories will be upgraded and moved to the version hosted on Azure.
That's far easier and in many cases sufficient. Of course this is not the "perfect" method either, but it won't require an interim repository (or the danger that whatever XML files you try to import into e.g. 10.2 will lead to corrupted repository contents).