Who actually controls your company website?
š§ Listen to every article back to back
A partner-managed website is not a problem as long as your company can take control of all critical access and assets when needed. Gaps usually become visible only when you need to change developers or restore the website quickly.
Your company may own the domain while someone else controls access
The first things to check are the domain and DNS. Your company should know who the domain is registered to, where it is managed and which email address receives renewal notices and other important messages.
The same applies to DNS. If only the current development partner or a former employee can access it, even a simple server migration can become difficult. DNS can affect services beyond the website, so records should not be changed blindly during a partner transition.
The point is not that a board member should personally manage DNS. The company should be able to recover access and grant it to a new partner when necessary.
Files copied from the server are not a substitute for source code
The next question is where the website actually runs and where its source code is stored. Hosting can be managed by a development partner, but the company should know which environment the site runs in and who controls the hosting account.
A Drupal project's source code should be kept in version control. Git gives a new developer not only the files but also the change history and helps them understand how the project has been developed and deployed.
If a partner transition produces only a copy of the files from the production server, that may not be enough to continue development. The project history, deployment configuration and information about which code should actually be running on the server may be missing.
The developer should not be the only one with administrator access
The company should control at least one way to recover Drupal administrator access. This does not mean content editors should use administrator privileges for their daily work.
The same principle applies to Google Analytics, Search Console, Tag Manager and other services connected to the website. A partner can manage them, but the company should not lose years of data or control of a service simply because cooperation with one provider ends.
More complex websites also involve API keys and integrations. A payment solution, CRM, authentication service or external registry can be just as important to the website as Drupal itself. During a partner transition, it should be clear which systems the website communicates with and who manages access to them.
A backup proves its value when you restore it
Being told that the server is backed up does not yet tell you whether the website can actually be restored. You need to know what is backed up, how long backups are retained and how the restoration process works.
Basic technical documentation matters too. A new developer should be able to determine where the source code is stored, how deployment works, which environments are in use and which external systems communicate with the website.
A useful practical test is to ask: if the current development partner became unavailable tomorrow, could another competent partner take over using the existing information and access?
A partner transition should not begin with a search for passwords
Changing development partners is a normal part of a website's lifecycle. In a well-managed project, the new partner receives the necessary access, starts the project in a test environment, reviews its technical state and continues the work.
If the status of the domain, server, Git repository, Drupal accounts or backups is unclear, these should be mapped before making major changes. The goal is not to rebuild the entire system immediately, but to understand what exists, what is missing and which risks need attention first.
As part of WebPro's Drupal project takeover and development partner transition, we can assess the existing system's technical state, access, source code, backups and integrations, and define the next steps.
Need Drupal help?
Send the website URL and a short context. We will tell you whether the sensible next step is an audit, maintenance, an upgrade or a migration.