The dangerous part of leaving ManageWP is not the new tool. It is the gap week, when the old backups are still on ManageWP's side, the new ones have not run yet, and a client's site chooses that moment to break. Migrate in the wrong order and you can end up with no restorable copy of a site you are being paid to protect.
This checklist is built around one rule: at no point does a site have zero verified backups. Everything else follows from that.
Before you touch anything: inventory
Start with a spreadsheet, one row per site. You want the URL, hosting provider, which ManageWP add-ons that site currently uses, the last backup date, and whether the client pays you for monitoring or reports. It sounds like admin, and it is, but it is also how you find the eleven sites nobody remembers adding.
ManageWP's core plan is free for unlimited sites, and the premium pieces are per-site add-ons: for example Backups at $2.75/month per site, Uptime Monitor at $1.25 and White Label at $1.25 (pricing page, checked October 2026, ManageWP pricing). Because you are billed on usage at month end, per the same page, the inventory also tells you exactly which sites you are still paying add-on fees for. Ask whether a site needs to be there at all before you migrate it.
Step one: export what you can still get
Backups are the asset at risk, so deal with them first.
Download the latest full backup of each business-critical site from ManageWP and store it somewhere you control, not in the tool you are leaving. If you have never done a test restore from one, do that now on a staging copy, because an untested backup is a hope, not a backup.
Note the retention you had. If you relied on ManageWP keeping a month of history, that history does not follow you, so decide which clients need older copies and download those explicitly. Then export whatever reports you owe clients. A client who asks in March what was done in January is entitled to an answer, and it should not depend on a subscription you cancelled.
I wrote about why the storage location matters in where should WordPress backups live. The short version: the copy that saves you is the one on infrastructure you control.
Step two: run both tools in parallel for one billing cycle
Do not cut over on a Friday. Install the new tool's connector alongside ManageWP's worker plugin. The two connectors can usually coexist on a WordPress site; the cost is a slightly heavier admin and a few days of duplicate monitoring.
While they overlap, do this per site:
- Connect the site to the new tool and confirm the connection survives a page-cache flush and a logged-out request.
- Run a first backup in the new tool. Check the file size is in the same ballpark as ManageWP's last one. A backup that is a tenth the size is a red flag, usually a skipped uploads directory.
- Restore that backup to a staging copy and load the site. This is the step people skip, and it is the whole point.
- Point uptime checks at the same URLs, and confirm alert routing goes to the right person, not just the account owner.
Only when a site has a restored, verified backup in the new tool does it move to the "cut over" column.
Step three: reproduce the settings that did quiet work
ManageWP does small things in the background that you forget about until they stop. Go through your account and list them.
Scheduled update windows and the plugins you exclude from auto-updates. Code snippets you push to sites. Performance and security check schedules. White-label branding on reports, including the logo, footer text and the sender address. Team members and their permission levels.
For updates, the thing to recreate is not just the schedule but the safety net around it. On our side that means a restore point and a screenshot comparison before and after an update; whatever tool you land on, make sure a failed update can be reversed in minutes rather than hours. There is more on the reasoning in safe WordPress updates explained.
Step four: tell clients only what changes for them
Most clients will never notice a change of dashboard, and you should keep it that way. The ones who will notice are those who receive branded reports or who log in to something you gave them. Send those clients a short note: reports will look slightly different from next month, same content, same date. Do not attach the words "new vendor". Do not promise features you have not verified.
If your reports go out as PDFs, generate one test report from the new tool for a real site and read it critically before the first client sees it. Check the site name, date range and that the numbers match what you remember.
Step five: cancel in the right order
The order matters more than people expect:
- Confirm every site has at least two consecutive successful backups in the new tool, plus one verified restore.
- Disable ManageWP add-ons per site, not the whole account first. This stops billing for that site without removing your ability to download a last backup.
- Remove the ManageWP worker plugin from each site once its add-ons are off. Leaving stale worker plugins around is a small security liability and a source of confusing error logs.
- Only then close the account or downgrade to the free plan. Given the free plan stays free for unlimited sites, you can choose to keep it as a low-effort fallback.
That last point is worth stating fairly: ManageWP's free tier is generous. If your needs were only updates and monthly backups, you may not need to leave at all. Leaving makes sense when you need something the free tier does not do, or when you want client-facing support and billing in the same place.
What to check a month later
Thirty days after cut-over, look at three things. Did every site keep producing backups on schedule? Did any alert fire and reach the right person? And do your invoices to clients still map to what you actually deliver? If any of the answers is no, fix it before the next billing cycle, while the old data is still recent enough to compare.
Where this leaves you
A migration is safe when it is boring: inventory, download, overlap, verify a restore, then cancel site by site. If you want the new tool to keep client backups on the client's own server plus your own offsite storage (S3-compatible), that is how WPClientHub is built. It is free for 3 sites if you want to try this on a real client site: register here.