System dependency mapping is one thing.
True environmental settings, uid's, passwords, impersonation settings, database names, and other data which change from development to qa to uat to production is the real challenge.
Who stores/remembers them all?
The developer knows not which production server(s) his application will reside on.
He only documents the name of his development database, uid's, pwd's and describes his database tables, conn strings, etc.
Once it's checked into the code repository, and migrated to the QA environment, who is the keeper of the data required to update those config file with the proper values?
Again when migrated to QA and UAT, who?
Who's responsibility is it to inform the next migration group of what needs to be changed?
In my company, this is what causes us the most headache. By the time it gets approved by the internal change control process and a migration request is created to migrate the application into the production environment, all it takes is one config setting to be forgotten to ruin the whole implementation, and it happens all the time because clear lines of responsibility are not drawn (in my opnion).
Beyond responsibility I think is a central repository for this information.
ie. A system that stores all configuration settings for all projects/applications, and based on your "role" you can/can't see the actual values.
The developer finishes his build, and creates a migration request in the "system".
The QA person receives notification that build ### is ready.
The QA person logs into the "system" and retrieves the migration instructions.
Now they clearly know what needs to be done, and they beging the code-check out and migration process.
Repeat for UAT and ultimately prod.
When someone builds this Migration system let me know, because THAT will help many people.
Maybe I'll build it myself... Who wants to contract me?