Drupal project takeover and partner change

When this helps

• the previous developer or agency no longer works on the project;
• the current development partner responds slowly or gives no clear overview;
• the project is unfinished and decisions are undocumented;
• documentation is missing or incomplete;
• Git, hosting, backups or deployment are unclear;
• the site works, but nobody is confident changing it;
• updates have not been done and development quality is uncertain;
• you need to know whether the system is maintainable before ordering new work.

What we check

• Drupal admin, server, domain and database access;
• Git repository, Composer files, deployment workflow and backups;
• Drupal core, modules, PHP and server state;
• custom modules, theme layer, cron jobs and integrations;
• security risks, data protection risks and critical user journeys.

What you get

• a takeover checklist;
• a list of risks and missing access points;
• a recommendation on what to fix immediately and what can wait;
• an assessment of whether the system fits maintenance, upgrade or migration work;
• an initial work plan for budget discussion.

Takeover process

1. Collect access — domain, hosting, server, Drupal admin, Git, database, files, email and external services.
2. Technical audit — check versions, modules, custom code, configuration, backups and release process.
3. Map risks — separate critical security and reliability risks from issues that can wait.
4. Start a test environment — where possible, establish a local or staging environment so changes are not made directly in production.
5. Fix critical issues — access, backups, security updates and broken workflows come first.
6. Continue maintenance or development — after the review, decide between Drupal maintenance, upgrade or custom development.

What we do not do

We do not start by rewriting the system. First the current state must be secured, backed up and understood. Only then does it make sense to change code or plan larger work.