Website Maintenance Takeover Checklist: Switching Providers Safely

Changing website maintenance provider should be a transfer of responsibility, not a rebuild.

A safe takeover is mainly about control: who owns the domain, where the site is hosted, whether a recent backup can be restored, which premium licences belong to the outgoing provider, how forms and payments work, and the exact moment the new provider becomes responsible.

The biggest risk is cancelling the old arrangement before the new provider has proved they can operate and recover the site independently.

Website maintenance takeover checklist

1. Make sure the business controls the domain

The domain is the first asset to verify because losing control of it can affect the website, business email and connected services at the same time.

Confirm:

• registrar;
• account owner;
• renewal email;
• renewal date;
• 2FA/recovery method;
• whether the business can independently renew or transfer.

The domain should not depend on a former freelancer’s personal email account.

2. Export DNS before changing anything

Record current:

• A/AAAA;
• CNAME;
• MX;
• TXT;
• SPF;
• DKIM;
• DMARC;
• verification records;
• subdomains.

A maintenance-provider change does not automatically require a DNS or hosting move.

Avoid creating migration risk unless there is a genuine technical or commercial reason.

3. Confirm business email will not be affected

Website providers often manage DNS while email is hosted by Microsoft 365, Google Workspace or another provider.

Changing the wrong DNS records can break email even when the website remains online.

4. Verify hosting ownership and access

Record:

• hosting company;
• control panel;
• billing owner;
• server IP;
• PHP version;
• database access;
• storage;
• CDN/Cloudflare;
• server backups;
• scheduled tasks.

5. Do not move hosting just because the maintenance company changed

If the existing hosting is fast, supported and suitable, the new provider can often maintain the site where it is.

Hosting migration should be a separate decision.

6. Create a named WordPress administrator account

Each provider should have their own account where possible.

Avoid sharing one generic admin login because:

• changes cannot be attributed;
• password sharing increases risk;
• offboarding becomes harder.

7. Audit all existing administrator users

Do not delete old accounts immediately.

First identify:

• current staff;
• outgoing provider;
• old developers;
• automation/service users;
• unknown accounts.

Remove unnecessary access after the handover is accepted.

8. Check premium licences

Common dependencies include:

• Elementor Pro;
• premium theme;
• WooCommerce extensions;
• booking plugins;
• security tools;
• form plugins;
• SMTP;
• backup software;
• image/performance tools.

For each one, document:

• licence owner;
• renewal date;
• whether it stops updates/support if disconnected;
• replacement cost.

9. Capture a full backup before the first major change

Take files and database.

Keep an independent copy where possible.

Do this before:

• updates;
• host migration;
• licence replacement;
• DNS changes;
• cleanup work.

10. Prove the restore route

A backup archive is not enough.

The new provider should know:

• where the backups live;
• how to access them;
• how the site would be restored;
• what recovery time is realistic.

For high-value sites, use the WordPress backup restore test before the old provider disappears.

11. Establish a technical baseline

Record the current:

• WordPress version;
• PHP version;
• theme/child theme;
• plugins;
• known warnings;
• custom code;
• storage use;
• performance baseline.

Note any component deliberately held back because of compatibility.

12. Document pre-existing faults

Test the site before changing it.

If a form already fails or mobile layout is already broken, write it down.

That protects both business and incoming provider from arguing later about when the fault began.

13. Test every business-critical function

Depending on the site:

• contact forms;
• quote forms;
• booking;
• login;
• WooCommerce checkout;
• payments;
• transactional email;
• CRM/webhooks.

14. Verify email/SMTP access

Form delivery may depend on:

• SMTP account;
• mail API;
• DNS authentication;
• provider-owned licence.

15. Verify analytics and Search Console

The business should retain access to:

• GA4;
• Google Tag Manager;
• Search Console;
• Google Ads where relevant;
• call tracking;
• other analytics.

16. Verify Cloudflare/CDN/security access

A provider can be locked out of critical DNS/cache/security controls even with full WordPress access.

17. Review scheduled tasks and automations

Document:

• cron jobs;
• webhooks;
• Zapier/Make;
• feeds;
• external sync;
• payment webhooks.

18. Review privacy-sensitive access

A maintenance provider may have access to customer data through:

• orders;
• form submissions;
• memberships;
• backups;
• databases.

Make sure access follows the business’s privacy/security requirements.

19. Classify the takeover before changing anything

20. Do not let a new provider turn takeover into an automatic rebuild

Changing support company is not by itself a reason to rebuild a functioning website.

A rebuild should be justified by:

• unsupported technology;
• unmaintainable custom code;
• severe structural problems;
• platform limitation;
• business requirements the current site cannot support.

21. Freeze unnecessary structural changes during handover

Do not change:

• URLs;
• domain;
• hosting;
• templates;
• SEO titles;
• content architecture;

at the same time unless there is a real reason.

22. Agree the maintenance scope

Write down responsibility for:

• updates;
• backups;
• security;
• uptime;
• forms;
• WooCommerce;
• small edits;
• emergency faults;
• reporting.

23. Define what is excluded

Common exclusions include:

• redesigns;
• new custom features;
• large content projects;
• pre-existing malware cleanup;
• third-party service fees.

24. Agree response expectations

Define:

• normal requests;
• urgent incidents;
• out-of-hours support;
• contact channels.

25. Set a precise handover point

The riskiest setup is one where both providers think the other is responsible.

Choose a date and time when responsibility transfers.

26. Perform a final acceptance test before removing old access

Confirm:

• domain access;
• DNS access;
• hosting access;
• WordPress admin;
• backup/restore;
• licences;
• forms/checkout;
• analytics;
• support contacts.

27. Remove old access deliberately

After acceptance:

• remove old admin accounts;
• revoke old hosting users;
• rotate shared secrets where appropriate;
• remove unnecessary API keys;
• update recovery contacts.

28. Keep the old provider contact available briefly where sensible

A short overlap can be valuable for questions about undocumented custom work.

What if the previous developer disappeared?

Start with what the business controls:

1. domain registrar;
2. hosting;
3. company email;
4. billing records;
5. WordPress;
6. backups.

If hosting access exists but WordPress login is lost, admin access can often be recovered safely.

If the site is broken or compromised, stabilise it first through the emergency website fixes service before normal maintenance begins.

Could switching maintenance provider hurt SEO?

Not by itself.

Risk appears when the handover also changes:

• hosting;
• DNS;
• URLs;
• content;
• canonicals;
• redirects;
• site structure.

Keep those stable during a straightforward provider switch.

Core Web UK maintenance takeovers

Our website maintenance and support service can take over existing WordPress, Elementor and WooCommerce sites built by another provider.

For businesses comparing support locally, the Website Maintenance London guide explains what to look for in a support arrangement.

Frequently asked questions

Can another company maintain a website they did not build?

Usually yes. A new provider needs appropriate access, a baseline and an understanding of custom dependencies.

Should I cancel old maintenance before switching?

No. Wait until the incoming provider has verified the assets and access needed to operate and recover the site.

Do I have to move hosting?

No. Hosting and maintenance are separate decisions.

Who should own the domain?

The business should normally control the registrar account or at minimum have independent renewal and transfer access.

What happens to old agency licences?

Some premium tools may continue working but lose updates after the agency licence is removed. Identify and replace those licences deliberately.

Do I need a rebuild when changing providers?

No. Rebuild only when there is a separate technical or business reason.

Create a pre-handover baseline before updating anything

The new provider should record the condition of the site before taking responsibility.

Capture:

• WordPress, theme and plugin versions;
• PHP version;
• known warnings and errors;
• current page-speed baseline;
• form/checkout test result;
• backup status;
• security status;
• existing broken layouts or known faults.

This prevents a pre-existing problem being confused with something caused during the takeover.

Do not inherit shared logins

Create named administrator accounts for the new provider and remove old access only after the handover is accepted. Shared credentials make it difficult to see who changed what and increase security risk.

Check proprietary or agency-owned components

Some sites depend on:

• agency licence keys;
• private plugins;
• custom themes;
• host-specific functionality;
• external APIs;
• premium fonts or stock licences.

Find out what stops working if the previous supplier cancels its licences or services.

Agree a formal acceptance point

The takeover is complete only when the new provider has verified access, captured a backup, tested the critical customer journey, reviewed licences and accepted the support scope.

That date should also mark when the new provider becomes responsible for incidents.