WordPress Migration Services for Agencies
Why client migrations go wrong
Most migrations that go badly do not fail on the big things. The pages load, the images show, and the homepage looks right. The damage comes from things nobody wrote down: a redirect someone added years ago, a contact form that sends to an address nobody remembers, or email that quietly depends on the same DNS zone as the website.
For an agency, these failures are expensive in a specific way. The client does not see a technical problem. They see that the quote request form stopped working and nobody told them. By the time a lead mentions it, weeks of inquiries may be gone.
Three areas cause most of the trouble:
- Hidden redirects. Old campaign URLs, retired pages and renamed sections often redirect through rules that live in a plugin, a server file or the old host's control panel. Move the site without them and search traffic and bookmarks land on error pages.
- Email. Websites and email often share a domain. Change DNS carelessly and mail can stop or land in spam. Treat mail records as a separate item that must survive the switch untouched.
- Forms. A form can look fine after a move and still fail to deliver. You only know it works when you submit a real test and see it arrive.
A good migration process does not rely on memory. It relies on an inventory made before anything moves, a copy you can check, and a switch you can undo.
The connect flow
The connect flow is built around a simple order: copy, verify, then switch. When you connect a site, its content, media and settings are copied onto fresh managed hosting. The original site is not touched while that happens. It keeps running exactly as before, and your client's visitors keep seeing it.
After the copy, a verification step confirms the copy is complete. Nothing changes for the live site until that check is done and you decide to switch. That order is what makes the process safe to run on a client site with a real audience.
For agencies, this changes the risk profile of a migration. You are not taking a site apart and hoping it reassembles. You are building a second copy beside the first, checking it, and only then moving traffic. If something looks wrong in the copy, the cost is a conversation with yourself, not with the client.
The help article on how to migrate an existing site covers the steps inside the product. This post covers the agency layer around it: what to inventory first, what order to switch things in, and how to keep a way back.
Pre-flight checks
Do this work before you start the copy. It takes less time than recovering from a missed redirect, and it gives you a written record you can show the client.
Inventory the site
Write down everything the site does, not just what it shows. A useful inventory covers:
- Every page that earns traffic or inbound links, so you can spot-check them after the move.
- All redirect rules and where they live.
- Every form, who receives its submissions, and what happens next (an email, a spreadsheet, a CRM).
- Any third-party scripts, embeds or tracking tags the site loads.
- Logins your client or their team use, so nobody is surprised.
If you want a longer list to start from, the content migration checklist goes deeper on content, media and structure.
Look at DNS before you touch it
Open the current DNS records for the domain and save a copy. Screenshot them or export them into the client's project folder. Note which records belong to the website and which belong to email or other services. Find out who controls the domain registration and who can log in, because on cutover day you do not want to wait three days for a client to find a password.
Also check how long the existing records are cached before they refresh. If you can lower that time ahead of the switch, a change and a reversal both take effect faster. How you do this depends on your DNS provider, so check their documentation rather than assuming.
Test the forms you can find
Submit every form on the live site now and record where each message lands. This gives you a baseline. After the move you repeat the same tests and compare. If a form already fails today, you want to know that before the migration, not be blamed for it afterward.
If the domain is changing as well as the host, treat that as a separate project with its own redirect plan. Our guide to moving to a new domain explains how to handle that without losing search visibility.
Cutover day
Cutover day should be boring. The decisions were made earlier, and the day itself is a checklist you follow in order. Pick a time when the client's traffic is usually low and when you are available afterward to watch the result.
- Confirm the copy is verified. Make sure the verification step on the connected copy has finished and reports the copy as complete. If it has not, stop and fix that first.
- Review the copy by hand. Open the new site and click through the pages from your inventory. Check the pages with the most traffic, a few deep pages, and any page with a form or embed.
- Run the form tests. Submit each form on the copy and confirm the message arrives where your baseline says it should.
- Freeze changes on the old site. Ask the client not to publish, edit or take orders during the switch window. Anything changed on the original after the copy will not be on the new site.
- Check your redirect list. Make sure each rule you recorded exists in the new setup, and test a handful of old URLs.
- Switch. Make the DNS change for the website records only, and leave email records as they are. Keep the saved copy of the old records open beside you.
- Verify on the live domain. Once the change takes effect, repeat the page checks and form tests on the real address, not just the preview.
Each step has a clear outcome, so at any point you can say whether you are on track. If step three fails, you have not switched anything yet. That is the whole advantage of verifying before cutover.
Keep the rollback ready
The rollback habit is simple: do not change anything on the old host until you are finished. Because the original is untouched until you switch, going back is a matter of restoring the DNS records you saved. Rehearse that in your head before you start. Know where the old records are, who has access, and how long a reversal will take to propagate.
Agree on a rollback condition with yourself in advance. For example, if the main form does not deliver and you cannot fix it quickly, you revert and investigate in calm conditions. Deciding this beforehand stops you from pushing forward because you have already invested the evening.
After cutover
The work is not done when the new site loads. For the first stretch, treat the site as still in migration, and keep checking.
Watch for the quiet failures:
- Form submissions that stop arriving. Ask the client to tell you if their inbox goes unusually quiet, and test once more on the next day.
- Old URLs returning errors. Look at any search or analytics tools the client already uses to spot pages that suddenly show as missing.
- Email behavior. Send a test message to and from the domain to confirm nothing changed.
- Anything the client mentions. Their staff will notice small differences before you do, so invite them to report them.
If the client's team logs in to edit content, check that their access works as expected. When you create sites for clients from scratch, the client dashboard lets you create sites on their behalf and open their WP admin, which keeps your own access straightforward. For a site you connected, confirm with the client who can log in and with what.
Retire the old host last
Do not cancel the old hosting on the day of the switch. Keep it running until you have watched the new site through a full cycle of normal use: a typical week of traffic, form submissions, and any scheduled content or orders the client has. Only then does it make sense to close the old account.
Before you cancel, take one more copy of anything you might need for records, and tell the client what you are about to do. Once the old host is gone, the rollback option goes with it. Retiring it should be a deliberate decision that you and the client both agree to, not a billing accident.
Make migration part of your service
Clients rarely ask for a migration because they want one. They ask because their current hosting is slow, unreliable or hard to manage, and they want someone to take care of the problem without breaking anything. An agency that follows a written process (inventory, copy, verify, switch, watch) can offer that with confidence and charge for the care involved.
If you want to see how the platform fits that process, what SimpleWP does is laid out on the features page. Partners who manage several clients can also use the client dashboard to create sites on their behalf and open their WP admin, which keeps day-to-day work in one place once the migration is behind you.