It happens to us all the time - perhaps every few weeks. A new customer comes knocking and they have an existing application that needs help or support. Sometimes the system has simply outgrown the current developer or the skill set of a contractor and it needs a team. Other times the application has evolved over time and has reached it's peak for performance and is beginning to degrade. Sometimes a rift has developed between the site owner and the previous developer or company. Whatever the reason, taking over third party code can be a daunting task. I have a few tips on how to make the transition more smooth.
In the word's of Gandalf at the gates of Minis Tirith, "Remember, whatever comes through that door... you are men of Gondor!" Of course immediately after he said that trolls burst the door and started throwing them like pillows at a sorority party. I doubt you will face anything quite so intense. Still, it is important to remember that it is just code after all. You are going to be able to read it and figure it out. If a customer has settled on you or your team as a solution it is probably because you are equipped to do it.
Especially if you are replacing a former team or a former developer, you will need to be able to provide assurances to the site owner that you are in control of the site. One of the first things to do is to review the usernames and passwords for low level items like datasources, the CF Administrator, Active Directory, services etc. Don't forget to go through the site's "admin section" (wherever they do their work) and review all the accounts to make sure they are what the site owner intends for them to be. I usually start with a checklist that works through all the servers and applications I know about. Be prepared. After making these changes you will find out about other applications that you have "broken" by changing passwords or usernames and you will have to fix these as well. Make sure that the site owner knows that this process is messy.
Many sites do not have a developement or staging environment with which to work. Sometimes the site has just not had the attention it needed as it grew, or perhaps it has evolved from something small to something much bigger. One of the most important things you can do to increase the level of confidence is to rehost the code to a dev box and use subversion or some other form of source control. Your customer will love being able to test and approve changes without affecting the live server.
Every site that has been alive for more than a month has at least one or two of these. Take a look at the directories and open files that have names like "fixcategories.cfm" or "tmpSetUser.cfm". You might find DB routines or file routines that handle some bulk task or another. Don't delete these files since they may be global fixes for problems you will run into later (ha). But you might want to gather them into a single folder and put a "cfabort" at the top of each of them.
If the customer (the site owner) has just gone through getting rid of a team or developer in favor of you or your team, they probably had some good reasons to do it. If the previous relationship was strained you might find yourself on the backside of a messy breakup. The site owner may be prone to fears that would never occur to you about code ownership, mis-use of customer data, and general integrity. Your job will initially consist of smoothing out the rough edges of the process and building a relationship. Yes, I said building a relationship. You may have to do some-hand holding (metaphorically speaking of course). You will have to assuage fears, build confidence and "over-communicate" until his or her trust is rebuilt. If the customer has gone through a messy breakup with a former developer or team, here is some specific advice.
Finally, in regard to taking over third party code it is important to do triage. You are not going to fix everything or bring it up to your coding standard in a weekend (you do have a standard don't you? And please tell me it includes a note about the proper use of pound signs:). It may pain you to hear it, but there may be sections of code that you never change. It's true. Sometimes bad legacy code is more cost effective to leave in place.