What do we check before taking over a WordPress project from another developer?

Taking over an existing WordPress project doesn’t necessarily mean rebuilding the entire website from scratch. In most cases, it makes sense to start with a brief technical audit to identify which parts of the solution are stable, which risks require immediate attention, and what information is still missing for long-term maintenance.

The purpose of the audit is not to find faults with the previous developer. The goal is to establish a fair starting point for both parties: you know what you’re paying for, and your new partner knows what they’re taking responsibility for.

Why can’t maintenance be assessed just by looking at a website?

A public website can function properly even if there are several risks in the background. A backup may be set up, but restoration has never been tested. Plugins may be out of date because a custom modification breaks with a new version. The domain may still be registered to a former employee or developer.

These circumstances do not automatically mean that the project is flawed. They mean that the situation needs to be clarified before a permanent maintenance budget is approved. Based on the audit results, a decision can be made on whether to continue as is, carry out limited repairs first, or plan a major technical upgrade.

1. Access, Ownership, and Liability

The migration starts with the accounts, not the code. We’ll check who they’re 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;
• Licenses for plugins and themes.

The company should have independent access to these accounts even if a partner handles day-to-day management. During the handover process, it is not advisable to forward passwords via email. It is safer to create separate user accounts for the new partner and remove the old access rights only after the handover has been confirmed.

2. Backups and Truly Effective Recovery

Having a backup and being able to restore data are not the same thing. We check what is backed up, how often it is done, where the copies are stored, and how long they are retained. For an e-store or an active portal, the backup frequency must correspond to the amount of data the company is prepared to lose in the worst-case scenario.

The official WordPress backup guide recommends backing up both the database and the files, and always creating a backup before updating or migrating. During the audit, we’ll also check whether at least one copy can be restored in a test environment. Only a successfully restored copy ensures that the backup isn’t just a checkbox in the settings.

3. Security, Users, and Updates

Next, we’ll look at the versions of WordPress, the active theme, and plugins, as well as user roles, file permissions, and production environment settings. The goal is not to achieve an abstract “100% security,” but to reduce clear and avoidable risks.

The WordPress Site Health dashboard provides a useful initial overview of critical issues, the server, the database, and software versions. It does not replace an audit, as it is not aware of the project’s business logic or the history of customizations, but it helps identify some obvious shortcomings.

We also check for outdated administrator accounts, weak or shared accounts, plugins of unknown origin, and whether updates can be tested securely. WordPress’s official security hardening guide emphasizes the importance of up-to-date software, trusted sources, restricted access, backups, and monitoring.

4. Theme, Plugins, and Technical Debt

In a WordPress project, custom logic can be located in the theme, in a separate plugin, in the page builder settings, or directly in the database. During the audit, we identify which parts of the solution are standard and which are project-specific.

Some important questions include, for example:

• whether the code is under version control and whether its revision history is available;
• Do the production and test environments match each other?;
• Will the customizations be preserved when the theme or plugin is updated?;
• Do the critical work flows depend on a single outdated add-on?;
• Will error messages and logs help identify the cause of the problem?

Technical debt does not necessarily mean that something needs to be rewritten immediately. The value of an audit is to distinguish between inconvenience and risk. A file with an inconsistent name might be expected, but a payment or authentication solution that prevents updates requires a more urgent plan.

5. Integrations and Scheduled Tasks

Integrations may not be visible on the public web, but they are critical to a company’s operations. We map out which systems WordPress exchanges data with, where access keys are located, how errors are reported, and who responds to them.

We also monitor scheduled tasks: data imports, report submissions, order processing, and other background processes. If an API connection is critical to the project, a separate article on WordPress integration will help you understand the actual scope of work involved and why the mere existence of a connection does not guarantee its reliability.

6. Performance and Traceability

A slow website can’t always be fixed with a single caching program. The cause may be a large database, a slow external service, images that are too large, or a poorly optimized query. During the audit, we assess the initial situation and distinguish between issues that can be quickly resolved and larger architectural issues.

Let’s also see if the website itself alerts us to any problems. Error logs, availability monitoring, and checks on critical forms or the checkout process help reduce situations where the first notification comes from the customer.

7. Content, SEO, and Administrative Logic

Migration isn’t just about the server and the code. We check to make sure that content types, URLs, languages, forms, and user roles are clear. If the website receives search traffic, we must avoid a situation where technical maintenance changes important URLs or metadata for unknown reasons.

A successful handover also involves understanding how content is managed on a day-to-day basis. If a routine content change requires a developer, the audit may recommend ways to simplify management without having to rebuild the entire solution.

What happens after the audit?

Maintenance based on the existing infrastructure. If backups, access controls, and the technical architecture are sufficiently in order, we can begin routine maintenance and further development.

Stabilization before maintenance. Often, a limited number of tasks need to be completed first: clear access paths, set up a test environment, update critical software, improve backup procedures, and document key workflows.

Plan for a new technical foundation. If a solution cannot be securely updated or if its core functions depend on discontinued software, it may be prudent to plan for a phased migration. This does not necessarily mean an immediate large-scale project; a good plan prioritizes risks and actions in the correct order.

Once the situation has been assessed, it becomes easier to evaluate the work ahead more accurately. This article on comparing WordPress quotes is helpful here, because when it comes to maintenance, the responsibilities, assumptions, and pricing model must all be equally clear.

What should you gather before the takeover?

• domain, hosting, and WordPress access;
• existing technical documentation and previous bids;
• information about the code repository and the test environment;
• a list of licenses and third-party services;
• known bugs and updates that have been postponed so far;
• The most important development needs for the next 6–12 months.

If any of these are missing, it does not prevent the audit from beginning. The missing information is itself an important finding, and restoring it can be part of the action plan.

What is a useful audit output?

A useful outcome is not a long list of technical notes. It is a prioritized overview in which each major finding is accompanied by its impact, recommended action, and time sensitivity. In addition, it must be clear whether the website can be restored, under what conditions maintenance can begin, and which issues require a separate quote.

Codeteam’s WordPress maintenance and development service also includes taking over existing projects. For long-term projects, our goal is to keep the technical foundation understandable and updatable so that every subsequent change does not require a new risk assessment.

A successful handover ensures that responsibility no longer rests solely on one person’s memory. Access rights, recovery procedures, critical dependencies, and next steps are documented and clear to both parties.