Almost every WordPress migration looks trivial in the quote and turns out not to be. A host swap that a plugin promises to handle in twenty minutes drags into a weekend of broken image paths, a checkout that silently stopped charging cards, and a Search Console account filling up with 404s. WordPress migration services exist because the gap between "the files moved" and "the business kept working" is much wider than the toolset suggests.
This guide covers what you are really buying when you hire for a migration, what the market charges, the failure modes that cost the most money, and the questions that tell you within one call whether a vendor has done this before.
What a migration actually involves
The word covers at least five different jobs, and pricing only makes sense once you know which one you have.
Host-to-host moves. Same WordPress, same theme, new server. Shared hosting to a managed platform like WP Engine or Kinsta, or an escape from a provider whose performance has gone sideways. This is the cheapest category and the one plugins genuinely do handle well most of the time.
Platform-to-WordPress moves. Coming off Wix, Squarespace, Drupal, or a hand-built CMS. Content has to be modelled, not copied: what was a page in the old system might need to be a custom post type in the new one. The limitations that push teams off closed platforms usually reappear as scope in the migration quote, because everything the old platform did implicitly now has to be built.
WordPress-to-elsewhere moves. Usually a store leaving WooCommerce, or a marketing site consolidating into a headless stack. Related in shape to the Magento-to-Shopify path and the BigCommerce equivalent: the hard part is never the export, it is the URL and data mapping.
Domain or structure changes. Same platform, new domain, or a URL scheme rebuild. Technically simple, commercially the most dangerous, because this is where organic traffic disappears.
Multisite consolidation or splits. Enterprise territory. Several sites merging into one network, or a network breaking apart after a divestment. Priced by the day, not by the site.
A vendor who quotes the same number for all five has not asked enough questions.
What WordPress migration services cost
Market rates in the US and UK cluster into fairly predictable bands.
A straightforward host-to-host move of a brochure site — under 100 pages, no ecommerce, no custom integrations — runs $300 to $900. Many managed hosts include one free migration when you sign an annual plan, and for simple sites that offer is genuinely worth taking.
A mid-sized business site with a few hundred pages, a form stack, some custom post types, and a live blog archive lands between $1,500 and $5,000. Most of that is not file transfer. It is the audit, the redirect map, the staging cycle, and the post-launch monitoring.
WooCommerce stores start around $4,000 and climb quickly. Order history, customer accounts, subscription tokens, tax configuration, and payment gateway re-authorisation all have to survive the move, and each one is a place where money leaks silently. A store doing meaningful revenue should also budget for the traffic dip discussed below, not just the invoice.
Platform migrations onto WordPress — Squarespace, Wix, Drupal — typically run $5,000 to $20,000 depending on content volume and how much of the design is being rebuilt rather than approximated.
Enterprise and multisite work is day-rate territory, commonly $1,200 to $2,500 per day with a discovery phase billed separately.
The number that matters is not the quote, it is the quote plus the expected revenue disruption. Before signing anything, model the downside: take your monthly organic revenue, assume a 20 to 30 percent dip for six weeks, and see what that costs. Running those figures through a break-even calculator alongside the migration fee usually reframes the decision. A $6,000 vendor who protects rankings is cheaper than a $1,200 vendor who does not, and it is rarely close.
The five ways migrations lose money
Redirects that were never mapped
This is the big one. Any URL that changes needs a 301 to its closest equivalent, and "closest equivalent" means the page serving the same intent, not the homepage. Bulk-redirecting a thousand old URLs to the root is the single most common way a migration destroys a decade of accumulated authority.
A proper redirect map is built before launch from a full crawl of the old site, cross-referenced against Search Console and analytics so that pages with links or traffic get individual attention. Ask to see the spreadsheet. If there isn't one, there isn't a plan.
Staging that does not match production
Migrations that are tested on a staging server with different PHP versions, different caching, or search engine blocking left on will pass every check and then fail on launch day. The staging environment should mirror production down to the object cache, and the very first post-launch task is confirming the noindex header that protected staging has actually been removed. Sites have sat de-indexed for weeks over exactly this.
Ecommerce state that silently breaks
Payment gateways often need re-authorisation against the new domain or server IP. Subscription products can lose their billing schedule. Tax rules configured against the old environment may not carry over. None of this throws a visible error; you find out from the revenue report. Any WooCommerce migration plan should include a test transaction on the live site with a real card, refunded afterwards, before traffic is switched.
Performance regression
Moving to a faster host does not automatically produce a faster site. Caching layers get reconfigured, image optimisation plugins lose their settings, and a CDN pointed at the old origin can serve stale assets for days. Core Web Vitals feed into rankings, so a regression here compounds the redirect risk rather than offsetting it. Benchmark the old site before the move so you have something to compare against.
Tracking that stops recording
Analytics tags, conversion pixels, and server-side tracking frequently live in theme files or plugin settings that do not survive the move intact. Losing three weeks of conversion data does not just cost reporting, it starves ad platform bidding algorithms of the signal they need. Confirm every tag fires on the new site the same day, and keep a copy of your conversion tracking setup documented outside the site itself so it can be rebuilt from a source of truth.
How to vet a vendor in one call
Six questions do most of the work.
"Walk me through your redirect process." A specialist will describe crawling the old site, exporting top pages by traffic and backlinks, building a one-to-one map, and testing it on staging. A generalist will say the plugin handles it.
"What is your rollback plan?" There should be a full backup of files and database taken immediately before the switch, a documented restore procedure, and a decision threshold — what has to go wrong, and who calls it. "We've never needed one" is not an answer.
"How long is DNS propagation and what happens during it?" The right answer covers lowering TTL a day or two ahead, keeping the old server live and in sync during the window, and how form submissions or orders landing on the old server will be reconciled.
"What do you monitor after launch, and for how long?" Two weeks of monitoring 404 logs, crawl stats, index coverage, and Core Web Vitals should be included, not billed as an extra.
"Can I speak to a client whose site is comparable to mine?" Comparable means similar page count, similar commerce complexity, similar traffic level. A vendor whose portfolio is all five-page brochure sites is a poor fit for a 2,000-page publisher.
"Who owns the hosting account and the credentials?" You should. Vendors who insist on holding hosting in their own account create a hostage situation later. This is the same governance issue that comes up when choosing an agency to build a B2B site, and the answer is the same: your assets, your accounts.
Timing the move
Two scheduling decisions matter more than the rest.
Migrate in your slow season. Retailers should not move in Q4. B2B firms should avoid the fortnight before a major campaign or event. If your business has no slow season, pick the quietest weekday window your analytics can identify, not Friday evening — you want engineers awake and available for the following two days.
Do not stack changes. A host migration, a redesign, and a URL restructure done together produce a traffic change you cannot diagnose, because you cannot isolate which one caused it. Sequence them with at least three to four weeks between, long enough to read the effect of each. It is slower and it is worth it.
What to expect after launch
A short dip is normal. Google needs to recrawl, follow redirects, and consolidate signals, and even a clean migration usually shows a 10 to 20 percent organic decline for two to four weeks before recovering. What is not normal is a dip that deepens after week four, or one concentrated in your highest-value pages while low-value pages are unaffected — that pattern points at a redirect problem, not a crawl delay.
Watch four things weekly for the first two months: index coverage in Search Console, organic sessions by landing page compared against pre-migration baselines, 404 volume in server logs, and conversion rate on your top commercial pages. Comparing sessions against a stable baseline is much easier if you have already established how your traffic is measured before the move rather than reconstructing it afterwards.
If conversion rate holds but traffic drops, you have an SEO problem. If traffic holds but conversion rate drops, something in the funnel broke — a form, a payment step, a tracking tag. The two symptoms have completely different fixes, and separating them early saves weeks. For stores, put post-migration revenue per session against your pre-migration figure and check the change against your profit margin to see whether the recovery is real or just discounting.
When to skip the service entirely
Not every site needs a paid migration. If you run a small brochure site on standard WordPress with no ecommerce, no custom post types, fewer than fifty pages, and you are keeping the same domain and URL structure, a managed host's free migration service plus an afternoon of link checking will get you there. The plugins in this space are mature and reliable within their limits.
The threshold for hiring is roughly this: you have ecommerce, or more than a few hundred URLs, or you are changing domain or URL structure, or the site produces revenue you would notice missing for a week. Any one of those and the cost of a specialist is small next to the exposure.
FAQ
How long does a WordPress migration take? A simple host-to-host move is a day of work plus 24 to 48 hours of DNS propagation. A mid-sized business site typically runs two to three weeks end to end, most of it audit, staging, and testing rather than the switch itself. WooCommerce and platform migrations commonly take four to eight weeks.
Will migrating hurt my Google rankings? A same-URL host move should have no ranking effect at all beyond a brief crawl adjustment. Anything that changes URLs carries real risk, and the outcome depends almost entirely on redirect quality. Clean migrations recover within four weeks; badly mapped ones may never fully recover.
Can I just use a migration plugin? For simple sites, yes — All-in-One WP Migration, Duplicator, and host-provided tools work well. They move files and databases. They do not build redirect maps, verify payment gateways, reconcile orders taken during propagation, or monitor index coverage afterwards, which is where the cost of a failed migration actually sits.
Should I redesign at the same time? No. Separate them by at least a month. Combining a migration with a redesign means any traffic or conversion change has two possible causes and no clean way to attribute it, which turns a diagnosable problem into guesswork.