Informatica Migration/Implementation in production - common issues

I work in a medium sized company where everything is fast paced with little chance for error. In my first week at work, I had to implement some Informatica code. One of the guy who joined me got booted out because one of his implementation went a bit wrong. Can you sense the amount of pressure I had to go through? I feel it even after close to 2 years with that company.

Implementation of Informatica code or in general any code to production is very stressful. Having to work over the weekends, having to work with implementation folks, pressure to get issues fixed faster, etc all add to the stress that a developer has to go through. Every company has its own way of release management and deploying code. We have a system where the developer creates implementation document and the production support folks deploy it in production reading the instructions. If any error in the instructions, then pretty much the developer is screwed. If any changes have to be done, then we have to raise separate change tickets, get approved, etc. Very hellish. If the migration involves putting new code and not working with existing critical systems, then we get a bit of room to work around but if it involves critical systems then we have zero chance for any thing going wrong. So, I thought of writing this article to list common issues with implementing Informatica code to production. The assumption below is that you are not using deployment groups and doing a step by step migration by copying the objects to be migrated to the destination/production environment.

Version control- Thank god we do not have version control in our prod environment. We back up the informatica objects as xml before every migration. Version control makes migration even more difficult. If you migrate a mapping and if the source/target is not checked in then those source/targets wont make it to the destination machine. Make sure to check in all the objects that need to be migrated. Also, in the destination machine make sure those objects are checked in too.

Not creating proper source or target shortcuts in target environment- If you copy a mapping that has source or target shortcuts, and if those shortcuts are not created prior to copying the mapping in the destination then the mapping gets copied with the shortcut removed. Whenever you are working with mappings that have shortcuts, please make sure to create those shortcuts in the target environment before migrating the mappings.

Impacting other mappings- It is always necessary to do a thorough dependency check on all the source/targets that are getting updated from a migration. The changes to source/target might make other mappings that use the same source/target to fail after the update is done. Also validate all the mappings that are impacted by the source/target definition changes.

Not validating impacted sessions- after a mapping change has been migrated make sure to refresh the session that was impacted. Otherwise the session will bomb when it runs in production.

Not having proper connections set up in production- If a matching database connection is not in production/target environment then most likely when you migrate the session it will show the non existence of the connection in the source environment. Most likely you have to create this connection in target environment or change the connection to match with a connection in the target environment. Also, some sessions are sensitive to the type of database connection.
Also proper permissions have to be set up for the connection objects. Otherwise it will fail with no permission to use the connection object. Have the right database drivers set up in the destination machines with all the correct tnsnames.ora or .odbc.ini entries.

Object Permissions- The folders in the destination should be set up with proper permissions so that the admin or the users of the destination machine can run the workflows and make changes if necessary.

Setting up the parameters/variables: Make sure to check if all the mapping/workflow variables were migrated properly. Also, make sure that the parameter file was migrated and accessible to the informatica workflows.

Scripts- Make sure all the unix/perl or whatever script you have going along with your informatica workflows are migrated, and Informatica can access and execute/read/write it.

Not having the database changes done correctly - If you migrate the mappings/sessions but the database changes are not done to reflect the new informatica code, then the sessions will fail. This could also include recreating some of the views of which the base tables where modified.

Copying reusable session that have overides in the workflows--If the reusable session has overrides, we have observed that sometimes these overrides are gone when the reusable session is copied again from dev/non prod environment. So better check all the overrides such as data base connection, and other sessions properties are not changed after sessions are copied.

In my recent migration, I copied the mapping and just refreshed the session that was using this mapping in the destination. However, this mapping had a new lookup and the session did not have connection configured in the destination. I should have migrated the session too. Anyhow, had to set up this connection in the destination session. 

In another migration, I copied a reusable session to the destination and was hoping the non reusable session in the destination machine will automatically pick this reusable session. But it did not. Had to remove the session that previously existing and add the reusable session. Very naive error.

Scheduling conflicts- You will get every thing correct but then you realize that there is backup job running and your database is not available. WTF??? or some other informatica workflow is writing to the same table or using up all the database resources. Check the scheduling conflicts with other jobs.


Impact to downstream process- Lets say you are generating a file for some downstream process to consume but made changes that the downstream process cannot process anymore then it will be a major issue. Check if all the downstream or upstream processes are working as expected.

I'm sure there are lot more that is not on top of my head. Will update this post whenever I remember.