Changing WordPress developers can feel risky, especially when the website has been managed by the same person or agency for years.
You may not know how the site was built, which plugins are important, where the backups are stored, or whether any documentation exists. Sometimes the previous developer is helpful during the transition. Sometimes they have stopped responding entirely.
The good news is that taking over an existing WordPress site does not automatically mean rebuilding it from scratch.
A WordPress site takeover typically involves six steps: confirming account access, creating a full backup, auditing how the site was built, identifying urgent risks, verifying that important user actions work, and documenting everything for the business.
At MantyWeb, we have taken over websites in nearly every condition imaginable during almost two decades of WordPress work. A careful developer should first learn how the site works, determine what needs immediate attention, and create a practical plan for moving forward.
First, we make sure you control the important accounts
Before making changes to the website, we confirm that your company has access to the systems it depends on.
That usually includes:
- The domain name
- DNS settings
- Website hosting
- WordPress administrator accounts
- Backup systems
- Analytics and search tools
- Paid plugin and theme accounts
- Email delivery services
- Third-party integrations
- Code repositories, if one exists
This step is important because the website itself is only one part of the system.
A company may have full access to WordPress but no control over its domain or hosting account. In other cases, important plugin licenses, analytics properties, or backup accounts may still belong to the previous developer.
Our goal is to make sure the business controls its own digital property and is not dependent on one person’s login.
What should you request from the outgoing developer?
When the previous developer is available, ask for a complete handoff before the relationship ends.
That request should include:
- WordPress administrator access
- Hosting and server access
- Domain registrar and DNS access
- Current website backups
- Backup service access
- Plugin and theme license information
- A list of paid services and renewal dates
- Analytics, Search Console, and Tag Manager access
- Form and email delivery settings
- CRM, payment, scheduling, and other integration details
- Theme and plugin source files
- If they have version control then access to GitHub, GitLab, Bitbucket, or another code repository
- Staging-site access
- Documentation for custom features
- Contact information for any other vendors involved
You may not receive every item on the list. Many websites have never been properly documented. Gathering whatever is available still makes the transition faster and reduces the amount of investigation required.
Whenever possible, the accounts should ultimately belong to the business rather than the developer or development company.
We create a complete backup
Before updating, removing, or changing anything, we create a full backup of the website.
That should include both the website files and the database.
We also want to know whether the existing backups are actually usable. A backup system that has been running for years is not very helpful if nobody knows where the files are stored or whether they can be restored.
For more complicated sites, we may create a staging copy as well. This gives us a safe place to test updates and investigate problems without putting the live website at unnecessary risk.
We learn how the website was built
WordPress is used by approximately 41% of all websites, according to W3Techs’ current WordPress usage data. That popularity has created a large and flexible ecosystem, but it also means two WordPress sites can work very differently behind the scenes.
One site may use the standard WordPress Gutenberg block editor. Another may use a page builder such as Elementor or Divi. Another may rely on a custom theme, custom plugins, or code written specifically for the business.
We review the site’s structure and identify:
- The active theme and child theme
- Page builders and editing tools
- Custom plugins and code
- Important forms
- Ecommerce or payment systems
- Membership features
- CRM and marketing integrations
- Hosting and caching tools
- Analytics and conversion tracking
This helps us understand which parts of the site are standard and which parts require extra care.
We review the plugins and themes
A WordPress site may have dozens of installed plugins, but that does not mean all of them are needed.
Some may be inactive. Some may duplicate each other. Some may have been added for a project that ended years ago. Others may be critical to forms, search, security, ecommerce, or custom website features.
We do not begin by randomly deleting things.
Instead, we determine what each plugin does, whether it is still supported, and whether removing it could affect the website.
This deserves careful attention. Patchstack documented 11,334 new WordPress ecosystem vulnerabilities during 2025, with 91% found in plugins. The same report said 46% of reported vulnerabilities had not received a patch by the time they were publicly disclosed. You can review the figures in Patchstack’s State of WordPress Security in 2026 report.
That does not mean WordPress plugins are inherently unsafe. It means plugin selection and ongoing oversight matter.
We check whether each plugin and theme is actively maintained, whether security updates are available, and whether the company has access to any required licenses. We also look for unnecessary overlap and software that no longer earns its place on the website.
We explain more about this in our guide to choosing quality over quantity with WordPress plugins.
We check for urgent problems
Once we understand the basic structure, we look for issues that may require immediate attention.
These can include:
- Outdated WordPress software, plugins, or themes
- Known security vulnerabilities
- Malware or unauthorized code
- Broken or incomplete backups
- Failed forms or missing lead notifications
- Expired software licenses
- Server errors
- Poor performance
- Broken pages or layouts
- Tracking that is no longer working
- Unsupported PHP versions
- Spam or suspicious administrator accounts
An inherited website with an uncertain history should receive an explicit malware scan. We also review administrator accounts, important files, security logs when available, and other signs that the site may have been compromised.
Not every problem needs to be fixed on the first day.
The first goal is to separate urgent risks from lower-priority improvements. A broken contact form or active security problem deserves faster attention than a page that could load slightly faster.
Our WordPress security audit guide covers many of the checks involved in greater detail.
We check whether the website is doing its job
A technically functional website can still be failing the business.
We review the most important user paths and make sure visitors can complete the actions the company cares about.
Depending on the website, that may include:
- Submitting a contact form
- Requesting a quote
- Calling the business
- Making a purchase
- Scheduling an appointment
- Signing up for a service
- Downloading a resource
- Finding important information
We also check whether those actions are being tracked correctly.
It is common to inherit a website where the pages still work, but form submissions are going to the wrong person, analytics are missing, or conversions are not being measured.
The site does not just need to stay online. It needs to continue supporting the business.
We document what we find
One of the most valuable parts of a website takeover is creating documentation that did not previously exist.
That documentation may include:
- Where the website is hosted
- Who controls the domain
- Which plugins are essential
- Which services renew each year
- How forms and email delivery work
- Where backups are stored
- Which areas use custom code
- Known problems and limitations
- Recommended next steps
The goal is not to create a giant technical manual that nobody reads.
The goal is to give the business a clear understanding of what it owns, how the website works, and where the risks are.
We create a practical plan
After reviewing the site, we organize the work into categories like the following:
Immediate fixes
These are problems that affect security, stability, lead delivery, sales, or other essential website functions.
Stabilization work
This may include safely updating software, improving backups, cleaning up administrator access, renewing licenses, removing malware, or repairing recurring errors.
Improvements
These are changes that can make the site faster, easier to manage, more accessible, or more effective for customers.
Longer-term decisions
In some cases, the website may eventually need a larger redesign or rebuild. That does not always mean it needs to happen immediately.
A good takeover process should help you understand what can be repaired, what should be improved, and what may need to be replaced later.
Do you always need a new website?
No.
Many inherited WordPress websites can be stabilized and improved without starting over.
A rebuild may make sense when the site has major structural problems, relies on unsupported technology, is extremely difficult to edit, or no longer supports the company’s needs.
But rebuilding should be a business decision, not an automatic response to messy code or an unfamiliar setup.
Sometimes the best answer is to repair the existing website and get several more useful years from it.
What if the previous developer is no longer available?
This situation is common.
It may make the takeover slower, but it does not make it impossible.
The most important thing is to gather the access and information that still exists. Hosting companies, domain registrars, internal staff, old invoices, password managers, and previous email conversations can often help rebuild the missing picture.
The process may involve more investigation, but an experienced WordPress developer should be comfortable working through incomplete information.
What should you expect from the new developer?
A website takeover should not begin with pressure or vague warnings.
You should expect the new developer to:
- Explain what they are checking
- Protect the live website before making changes
- Separate urgent problems from optional improvements
- Avoid unnecessary rebuilding
- Document important systems and accounts
- Communicate clearly about cost and risk
- Give you a realistic order of operations
You may not need every problem fixed immediately. You do need someone who can tell you what matters most and take responsibility for moving the site forward.
Frequently asked questions
How long does a WordPress site takeover take?
A basic takeover review can often be completed within a few business days after all necessary access has been provided. More complicated sites may require several weeks of auditing, repair, testing, and documentation before the transition is complete.
How much does it cost to switch WordPress developers?
The cost varies based on the website’s size, complexity, condition, and available documentation. The initial review for a typical small-business site often involves approximately 5 to 15 hours of work, while custom or neglected sites can require considerably more.
At MantyWeb, we typically review the website and available access before recommending a specific scope. We do not assume that every inherited site needs an expensive repair project or a complete rebuild.
Ongoing maintenance is normally priced separately. For a broader explanation of recurring costs, see our guide to how much WordPress maintenance plans cost.
Do I need to give the new developer full administrator access?
The developer will usually need WordPress administrator access to properly review plugins, themes, users, settings, and integrations. They may also need hosting, database, DNS, analytics, and third-party service access.
Access should be provided through a separate account created for the new developer rather than by sharing someone else’s password. Permissions can be adjusted or removed after the work is complete.
What should I ask my outgoing developer for before they leave?
Ask for WordPress, hosting, domain, DNS, backup, analytics, staging, and code-repository access. You should also request plugin and theme license details, custom-code documentation, renewal information, integration settings, and a current full backup of the website.
The business should control these accounts whenever possible.
Need help taking over an existing WordPress website?
MantyWeb regularly works with companies that have outgrown a previous developer, inherited an unfamiliar WordPress site, or are dealing with a website that has become difficult to manage.
We can review the site, document how it works, identify urgent problems, and create a practical plan for repairs, improvements, and ongoing support.
You do not need to understand every technical detail before contacting us. That is part of what we help you figure out.