On ServerFault, this question "Ending company IT Admin relationship" has a pretty good general checklist for taking over an existing IT system, but I'm wondering as it relates to Drupal:

  • What system access controls should I get, or confirm have been changed after the takeover?
  • What is the most effective way to assess the scope of existing custom configurations, development, etc done?

If it matters, the existing site is on Drupal 6, but talking about porting the site from 6 to 7 is beyond the scope of this question.

2 Answers 2


To save yourself access headaches:

  1. Get credentials for the "user 1" account that has full Drupal access
  2. Get database access or a copy of the most recent database
  3. Get SSH Access to the production server

To audit the site once you get access:

  1. Install http://drupal.org/project/hacked to make sure there haven't been any undocumented changes to Drupal core or contrib modules.
  2. Look in /sites/all/modules/custom to find any custom modules. If nothing is there one good way to tell if you're missing any hidden ones is by looking at http://example.com/admin/build/modules and looking for modules without a version number. They may be hiding in /modules or /sites/*site_name*/modules.
  3. Have a look at the theme and especially the contents of template.php. Often times a site will have a lot of modifications happening here.
  4. After looking at the items found in #1, #2 and #3 you shouldn't expect to have found a whole lot. The custom modules should be mostly hook implementations and 'glue code' not re-inventing the wheel or re-creating functionality found in popular contrib modules but your mileage will vary here depending on how custom the site requirements originally were.

To the first part:

  1. All access to the actual server. This may mean RDP, SSH, or other login methods, and will depend on the server and its operating system.
  2. Database administration privileges. If the server cannot be reached from outside of the system, as is most common, then server access will take care of this, but checking which accounts has high privileges on the database is still important.
  3. The admin, or "User 1", account on the Drupal site itself as well as any other "high-level" users. The permissions system in Drupal isn't very fine grained, and both user 1, as well as any accounts with permissions to administer users, roles, modules and themes, are potential security problems. A well built Drupal site will have no use for the eval function and the corresponding PHP Filter module, and as such it should be turned off completely in PHP. If not, there are unfortunately a large number of ways to subvert a site, and if it is severly misconfigured, possibly even the server. Try disabling eval in a test environment and see if the site breaks. (Anyone further interested in this part of Drupal security should checkout http://drupal.org/sandbox/balint.kleri/1119750)

As for the second part of your question, I don't think there is any good answer, unless the previous developers has actually documented their work. This could be in code, as user stories written with a client, or just a text document in the root directory of the sites repository. Drupal allows for to many development paradigms for there to be a clear cut answer otherwise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.