Whether due to an inexperienced prior vendor, a severe security incursion, or both, a sufficiently broken Drupal site is almost impossible to work with. When your site is not in a known good state, the simplest bug report or functionality request can be impossible to resolve. The entire code base and database require a thorough audit and repair before your site can be deployed.
This talk will describe the process used to recover sites with no filesystem or database backups after a Drupalgeddon infiltration, and the process used to rescue a site containing multiple major unsupported core patches.
This talk will also briefly mention the related project management difficulties associated with having inherited a completely broken site, in particular one belonging to an external client.
This talk is targeted at anyone who fears they may someday be responsible for fixing a horribly broken Drupal site in production. It assumes a basic working knowledge of the Unix command line, patches, and server security audits (or an interest in learning about them).