Taking over a WordPress site from a previous agency
When a relationship with an agency ends, the website has to move with you. This is the order I use when taking over a WordPress site: access, a backup, an inventory of what is actually installed, and what has to happen before anything is updated.
Most WordPress sites change hands at some point. The agency closes, the freelancer takes a permanent job, or the relationship simply stops working. The site still runs, but nobody knows exactly what is on it, and the person who built it no longer answers email quickly.
This is the order I use when I take over. It also works if you are handling the handover yourself and just want to make sure nothing is lost.
1. Get the access before the relationship ends#
Access is easiest to get while the previous supplier still replies. The list is longer than most people expect:
The WordPress admin. Your own administrator account with your own email address, not a shared login.
The hosting. Control panel, SFTP or SSH, and database access. Check who the hosting company has on file as the customer. If the agency owns the account, either the account or the site has to move.
The domain. A .dk domain is registered with Punktum dk, and the registrant should be your company. If the agency is the registrant, get it changed now.
DNS. Where it is hosted and who can change it. Email depends on it too, so a DNS mistake breaks more than the website.
The code repository. If the theme or custom plugins live in Git, you need access to it.
Paid licences. Premium plugins such as ACF Pro, Gravity Forms, WP Rocket, Elementor Pro or WPML are often bought on the agency's account. When the licence lapses, updates stop, and some of them stop working.
External keys. Payments, newsletters, maps and CRM are connected with API keys that may have been created in the agency's name.
2. Take a full backup and prove it restores#
Before anything changes, I copy both the files and the database and store the copy somewhere other than the hosting. Then I restore it on a test server. A backup that has never been restored is one you do not know works, and it is the copy you will need if an update goes wrong.
3. Take stock of what is actually running#
The handover document, if there is one, rarely describes the site as it is today. I look at:
WordPress and PHP versions. PHP 8.1 had its last security release at the end of 2025, and 8.2 gets them through 2026. A site on an older version has to move forward, which can mean changes to the theme and plugins.
Plugins. Which are active, which are switched off but still installed, which have not been updated in years, and whether there are copies of paid plugins that did not come from the publisher. Those last ones are a known way in for malware.
The theme. Were changes made directly in the theme's files, or in a child theme? Edits to the theme itself disappear with the next update.
Custom code. Code in
functions.php, inmu-pluginsor in a custom plugin. That is usually where the integrations and the special rules live.Users. Old administrator accounts from the agency and from former staff.
4. Close the old access#
Once you have your own access, close the old: change the hosting, database and WordPress passwords, delete the agency's users, and replace the API keys that were shared. Turn on two-factor authentication for administrator accounts.
The agency has had access to personal data such as orders, form submissions and newsletter lists. Ask for written confirmation that their copies are deleted, and check that you have a data processing agreement with the hosting company the site is with now.
5. Update a copy first#
With the inventory done, I update WordPress, the theme and the plugins on a test copy, go through the important pages (home page, contact form, and basket and checkout if there is a shop) and only then move the updates to the live site. A plugin that cannot be updated without breaking something becomes a separate task.
What it costs to leave it#
A site that nobody takes responsibility for does not get updated. After a year or two it has plugins with known security holes, a PHP version without updates and a lapsed licence. It usually shows only when the site is hacked or stops sending its forms.
I take over WordPress sites for businesses across Denmark and meet in person in Vejle and the rest of the Triangle Region. If you want an overview first, a technical review is the place to start. If someone should keep the site updated afterwards, that is operations.
Was this useful?
More notes
Why is my WooCommerce shop slow?
A slow WooCommerce shop rarely has a single cause. These are the places I look first when a shop has become heavy, from hosting and the database to images and third-party scripts, and how to measure before changing anything.
What a technical SEO check actually finds
Not keywords. Mostly pages Google cannot see, pages it sees twice, and pages that are too slow on a phone to matter. The findings that come up again and again on small Danish business sites.