What we check before taking over a WordPress project from another developer
Contents
- In short: what should a takeover audit clarify?
- Why can’t you judge maintenance needs just by looking at the website?
- Access, ownership, and responsibility
- Backups and restores that actually work
- Security, users, and updates
- Theme, plugins, and technical debt
- Integrations and scheduled tasks
- Performance and monitoring
- Content, SEO, and site administration
- What happens after the audit?
- What should you gather before the takeover?
- What does a useful audit report look like?
Taking over an existing WordPress project does not mean rebuilding the whole website from scratch. In most cases it makes sense to start with a short technical audit. It shows which parts of the solution are stable, which risks need attention right away, and what information is still missing for long-term maintenance.
The purpose of the audit is not to find fault with the previous developer. The goal is a fair starting point for both sides: you know what you are paying for, and your new partner knows what they are taking responsibility for.
In short: what should a takeover audit clarify?
- whether access rights and accounts are under the company’s control;
- whether there is a working backup that can actually be restored;
- whether the software is secure and can be updated;
- how the customizations and integrations were built;
- which licenses and third-party services are needed;
- whether maintenance can start right away or the site needs to be stabilized first.
Why can’t you judge maintenance needs just by looking at the website?
A public website can work fine even when there are several risks behind it. A backup may be set up, but a restore has never been tested. Plugins may be out of date because a custom change breaks with the new version. The domain may still be registered to a former employee or developer.
None of this automatically means the project is badly built. It means the situation needs to be clarified before an ongoing maintenance budget is approved. Based on the audit, you can decide whether to continue as is, do a limited set of fixes first, or plan a larger technical upgrade.
1. Access, ownership, and responsibility
A takeover starts with the accounts, not the code. We check who the following are registered to and who has access to them:
- domain and DNS management;
- web hosting and server;
- WordPress administrator accounts;
- code repository and test environment;
- analytics, email, payments, and other external services;
- plugin and theme licenses.
The company should have its own access to these accounts, even if a partner handles day-to-day management. Passwords should not be sent by email during the handover. It is safer to create separate user accounts for the new partner and remove the old access only after the handover is confirmed.
2. Backups and restores that actually work
Having a backup is not the same as being able to restore it. We check what is backed up, how often, where the copies are stored, and how long they are kept. For an online store or a busy portal, backups should be frequent enough to match how much data the company can afford to lose in the worst case.
The official WordPress backup guide recommends backing up both the database and the files, and always making a backup before an update or a migration. During the audit we also check that at least one copy can be restored in a test environment. Only a successful restore shows that the backup is more than a checkbox in the settings.
3. Security, users, and updates
Next we look at the versions of WordPress, the active theme, and the plugins, as well as user roles, file permissions, and production settings. The goal is not some abstract “100% security”. It is to reduce clear risks that can be avoided.
The WordPress Site Health screen gives a useful first overview of critical issues, the server, the database, and software versions. It does not replace an audit, because it knows nothing about the project’s business logic or the history of its customizations. It does help spot some obvious gaps.
We also look for old administrator accounts, weak or shared accounts, and plugins of unknown origin, and we check whether updates can be tested safely. The official WordPress security hardening guide stresses up-to-date software, trusted sources, restricted access, backups, and monitoring.
4. Theme, plugins, and technical debt
In a WordPress project, custom logic can live in the theme, in a separate plugin, in page builder settings, or directly in the database. During the audit we identify which parts of the solution are standard and which are specific to the project.
Important questions include:
- whether the code is in version control and its history is available;
- whether the production and test environments match;
- whether customizations survive a theme or plugin update;
- whether critical workflows depend on a single outdated add-on;
- whether error messages and logs help find the cause of a problem.
Technical debt does not always mean something has to be rewritten right away. The value of an audit is in telling an inconvenience apart from a risk. An oddly named file can wait, but a payment or login solution that blocks updates needs a more urgent plan.
5. Integrations and scheduled tasks
Integrations may not be visible on the public website, but they can be critical to how the company runs. We map which systems WordPress exchanges data with, where the access keys are stored, how errors are reported, and who responds to them.
We also review scheduled tasks: data imports, report sending, order processing, and other background jobs. If an API connection is critical to the project, our separate article on the real scope of WordPress integration work explains why a working connection alone does not guarantee that it is reliable.
6. Performance and monitoring
A slow website can’t always be fixed with a caching plugin. The cause may be a large database, a slow external service, oversized images, or an inefficient query. During the audit we assess the current state and separate quick fixes from larger architectural issues.
We also check whether the website reports its own problems. Error logs, uptime monitoring, and checks on critical forms or the checkout help avoid situations where the first warning comes from a customer.
7. Content, SEO, and site administration
A takeover is not only about the server and the code. We check that content types, URLs, languages, forms, and user roles are clear. If the website gets search traffic, technical maintenance must not change important URLs or meta data without a clear reason.
A good handover also means understanding how content is managed day to day. If a routine content change needs a developer, the audit may suggest ways to make management simpler without rebuilding the whole solution.
What happens after the audit?
Maintenance on the existing setup. If backups, access, and the technical architecture are in good enough shape, we can start regular maintenance and further development.
Stabilization before maintenance. Often a limited set of tasks needs to be done first: sort out access, set up a test environment, update critical software, improve backups, and document key workflows.
A plan for a new technical foundation. If a solution can’t be updated safely, or its core functions depend on discontinued software, it may be wise to plan a phased migration. This does not have to mean a large project right away. A good plan puts risks and actions in the right order.
Once the situation is clear, the work ahead is easier to estimate. Our article on comparing WordPress quotes is useful here, because for maintenance too the responsibilities, assumptions, and pricing model must be equally clear.
What should you gather before the takeover?
- domain, hosting, and WordPress access;
- existing technical documentation and previous quotes;
- details of the code repository and the test environment;
- a list of licenses and third-party services;
- known bugs and updates that have been put off so far;
- the most important development needs for the next 6–12 months.
If some of this is missing, the audit can still start. Missing information is a finding in itself, and recovering it can be part of the action plan.
What does a useful audit report look like?
A useful result is not a long list of technical notes. It is a prioritized overview where each major finding comes with its impact, a recommended action, and how urgent it is. It should also be clear whether the website can be restored, on what conditions maintenance can start, and which issues need a separate quote.
Codeteam’s WordPress maintenance and development service also covers taking over existing projects. In long-term projects, our goal is to keep the technical foundation understandable and easy to update, so that each new change does not need a fresh risk assessment.
After a good handover, responsibility no longer depends on one person’s memory. Access, restore procedures, critical dependencies, and next steps are documented and clear to both sides.
