Here’s the uncomfortable truth: most agencies are carrying at least a few client sites they no longer fully trust.
They look fine on the surface. The design is polished. The client is still live. But underneath, performance is inconsistent, support tickets keep surfacing, and every traffic spike, plugin update, or sales campaign feels riskier than it should. For agencies managing 5–50+ WooCommerce or high-traffic WordPress sites, that kind of instability does not stay technical for long. It turns into reputation damage, wasted support time, and hard conversations with clients.
And yet, many agencies stay put because migration feels riskier than underperformance. Not because staying put is working, but because migration has been surrounded by myths for years.
Google’s own guidance is clear: changing hosting does not automatically mean SEO loss, and site moves can be handled with minimal search impact when they are planned and tested properly. At the same time, Google emphasises that performance and page experience directly affect both search ranking and user experience and the performance data is unambiguous. A Deloitte and 55 study commissioned by Google found that a 0.1-second mobile speed improvement increased retail conversions by 8.4% and average order value by 9.2%. A Portent study analysing over 100 million page views across 20 B2B and B2C sites found that ecommerce sites loading in one second converted at 3.05% – more than twice the rate of sites loading in five seconds.
So the real question for agencies is not “Is migration risky?” The better question is: Is staying on the wrong hosting stack costing us more than moving?
In this article, we clear up the 10 migration myths most likely to keep your portfolio stuck and show what a safer, smarter migration path actually looks like.
Why this matters more for agencies than everyone else
For a solo site owner, a slow or unstable site is frustrating. For an agency, it compounds.
One poor client experience generates more support requests, harder renewals, more reactive firefighting, and the kind of performance conversations your team should never have to keep repeating. If your agency’s name is attached to WooCommerce stores or high-traffic WordPress sites, hosting underperformance becomes your problem, whether you control the server or not.
That is why migration decisions should not be framed as a technical inconvenience. They should be framed as an operational leverage decision. And that is exactly why so many agencies delay a move for too long.
Let’s clear up the myths.
Myth 1: You will always lose traffic and SEO rankings after a migration
This is the single biggest psychological barrier holding agencies back, and it is almost always overstated.
If you are changing hosting without changing user-visible URLs, Google maintains a separate, well-documented process specifically for that scenario. Their guidance states that a hosting change can be completed while minimising impact on search performance, provided the new environment is copied, tested, crawlable, and monitored post-launch. Google also notes that a temporary change in crawl rate after launch is normal and explicitly not the same as permanent ranking loss.
The real issue is not migration itself. The issue is sloppy migration. Agencies lose traffic when they change URLs without mapping them correctly, forget redirects, launch untested templates, leave noindex or crawl blocks in place on the new environment, or (critically) combine a hosting change with a redesign and content overhaul all at once. Any one of those is a risk. All of them together is an SEO incident.
What actually happens when migration goes the other way? Google uses Core Web Vitals as a primary ranking signal. Their thresholds are specific: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint below 200ms, Cumulative Layout Shift below 0.1. A site that suddenly delivers uncached TTFB under 100ms is doing exactly what Google’s algorithms are designed to reward, not penalise.
How Servebolt handles this: At Servebolt, we eliminate the variables that cause SEO drops. Our process ensures that your URLs stay exactly where they are. We first create a copy of the site on a temporary staging URL, allowing you to test the environment fully without touching the live production site. The critical distinction is what happens next: before you go live or switch your DNS, we perform a final resync. This ensures that the live environment on Servebolt is a 1:1 mirror of your current site, capturing every single file and database entry, including WooCommerce orders or new comments, right up to the second of transition. You aren’t “moving” to a staging URL; you are validating on staging and then launching on your live domain with perfect data integrity. From an SEO perspective, there is nothing for Google to penalise because there is nothing for Google to notice except a site that now loads faster. Our Linux 8 stack has delivered uncached performance improvements of up to 580% for sites migrating from traditional managed WordPress environments, which, from a Core Web Vitals perspective, is an upgrade, not a disruption.
Myth 2: You will lose data or end up with broken links
You can lose data in a bad migration. You do not have to lose data in a good one.
This myth persists because many teams have experienced migrations where databases were exported carelessly, serialized data (where PHP objects get stored as strings) broke, media paths failed, or redirect logic was forgotten. Those are real concerns, but they are not inherent to the migration process. They are the result of incomplete preparation.
For WordPress and WooCommerce sites, the surface area is wider than most people realise. It is not just pages and posts. It is product data, order workflows, serialized options in the database, plugin settings, media libraries, custom tables, cron jobs, and external integrations. Serialized data in particular requires careful handling – a naive search-and-replace across a WordPress database can shatter serialized arrays, leaving plugin settings corrupted in ways that are painful to diagnose after the fact.
Google’s own site move guidance recommends thoroughly testing pages, images, forms, and downloads in a staging environment before DNS is touched. That is not a nice-to-have, it is the minimum.
Broken links and missing content are not evidence that migration is dangerous. They are evidence that validation was incomplete.
How Servebolt handles this: Servebolt’s migration workflow is designed to navigate this complexity smoothly, ensuring that issues are identified and resolved before DNS changes where possible.
The process begins with a clean, host-compatible copy of your site. We thoroughly check the frontend and backend, proactively fixing any obvious issues we find. If we spot anything structurally complex, we notify you immediately so it can be addressed before going live. It is also worth noting that many perceived “errors” at this stage are simply side effects of using a temporary staging URL, as many premium plugins restrict their functionality to a single, licensed domain.
When you are ready to transition, we coordinate the live migration closely with your team to minimize downtime. Rather than trying to isolate and lock specific WooCommerce order tables, we take a safer, holistic approach: we enable a brief maintenance mode on the original site. This guarantees that no new data, whether that is an order, a user registration, or a simple comment, gets written to the old database while we perform the new, final copy of your files and database.
We don’t just guess that the live environment is ready. Before you make any DNS changes, Servebolt Support does one last test by modifying our local hosts file to point your live domain to the new Servebolt IP. This allows us to see exactly how the website behaves in the browser under its actual domain name, totally bypassing the staging URL. Once everything is verified locally, we advise making the DNS changes right after the final sync is completed, ensuring a seamless handover.
Myth 3: Large sites or multiple sites will take weeks to migrate
Large sites are more demanding. They are not automatically slow to migrate.
Modern migration does not upload your site; it syncs it. rsync and SSH-based transfers operate at the protocol level, far faster than anything a browser-based migration plugin can manage. For genuinely large sites, the approach involves a base sync performed days in advance, moving the bulk of the file system in the background while the live site continues serving traffic. The final delta sync, transferring only the files that changed, takes minutes, not hours. The heavy lifting happens before the go-live window opens.
Agencies with large portfolios should not treat this as a series of individual emergencies either. The more repeatable your process (credential checklist, redirect inventory, launch sequencing, QA roles, client communication template), the more predictable every migration becomes. A 20-site migration handled as a structured programme with batching is a very different exercise from 20 one-off projects each treated as a unique crisis.
Google’s hosting-change guidance is built around a structure that scales: copy, test, update DNS, monitor old and new environments in parallel, shut down old infrastructure only once traffic has fully shifted. That framework works for a single site and a portfolio of 50.
How Servebolt handles this: For agencies moving multiple client sites, we treat portfolio migration as a programme, not a series of individual projects. We sequence migrations around your client priorities and campaign calendars, handle the base-plus-delta sync workflow for large databases and media-heavy sites, and provide your team with a staging URL for each site so QA can run in parallel across your portfolio rather than one-at-a-time. Agencies that have moved full client rosters to Servebolt typically find the per-site migration time drops significantly once the process is standardised, because we have done it hundreds of times and the workflow is already built.
Myth 4: Migration causes massive downtime
Poor cutovers cause downtime. Migration itself does not.
A properly handled migration does not require your live site to go offline while files transfer. The correct sequence is: clone the site to the new environment while the source remains fully live; test functionality on the temporary URL; perform a final sync of the files and database to capture any recent changes; and only then update DNS to point traffic at the new infrastructure. By the time public traffic starts shifting, the new environment already exists, has already been validated, is completely up to date, and is already serving requests.
The “downtime” fear is almost always conflating two separate things: the time it takes to transfer files (which happens in the background, invisibly to visitors) and DNS propagation (which determines how quickly the switch reaches different users). Reducing TTL settings in advance, something both Google and Cloudflare explicitly recommend, speeds propagation considerably. With TTL reduced several days before cutover, the transition is near-instantaneous for most visitors.
How Servebolt handles this: Servebolt uses a Servebolt Proof setup that is specifically designed around zero-downtime cutover. We copy the site to a temporary hostname and run initial tests on the frontend and backend, reporting any issues we spot back to you. However, because you know your client’s site inside and out, we rely on your team to test the more complex workflows and confirm everything works as expected.
Once you approve the test environment, we do not just flip the switch. As mentioned in Myth 2, we perform a final sync of the files and database right before the actual cutover. We recommend reducing the TTL of your relevant records to 5 minutes (or 300 seconds if you have to store it in seconds), a full day before the actual planned cutover. This is a standard step we walk every agency through, not an afterthought.
All this will do is make sure your DNS records are cached no longer than 5 minutes after that full day has passed. Effectively, if you were to change it today at 11:00 in the morning, you will have a flexible DNS migration path with a 5-minute TTL starting at 11:00 the next day. Meaning your site will point to the new IP address within 5 minutes of changing it, ensuring the final, synced version of your site is live almost immediately.
Myth 5: DNS changes will break your email
This myth survives because DNS feels invisible and therefore intimidating. The mechanics are actually straightforward once you separate what each record type does.
Your website’s traffic is governed by A records, AAAA records, or CNAME records. Your email delivery is governed by MX records, alongside supporting records for SPF, DKIM, and DMARC. These records coexist in the same DNS zone but operate completely independently. Moving web hosting requires changing A, AAAA, or CNAME records. It does not require touching MX records. If MX records are left untouched, and they should be in every well-managed migration, email continues without interruption.
Cloudflare’s DNS documentation makes the record-type separation explicit. Email problems in migrations almost always trace back to one of two causes: someone clicked “Reset to Default” on a DNS zone without auditing what was in it, or records were changed without understanding which ones controlled what. Neither is a consequence of migration as a concept. Both are consequences of proceeding without a record inventory.
How Servebolt handles this: Our main focus when migrating customers is strictly on your A records, AAAA records, and CNAME records. We do not alter your mail records. The only DNS elements that change are the ones that actually need to point web traffic to your new environment.
Additionally, we actively advise agencies to separate their web hosting from their email infrastructure. Generally, we recommend against using our web servers as your main email service provider on a live site because our servers are optimized specifically for high-performance web hosting, not for handling email sending and receiving. To ensure maximum deliverability and protect your client’s reputation, you should use dedicated transactional email providers such as Mailgun, Postmark App, Mandrill, SendGrid, or SendLayer.
Myth 6: Your custom setup is too complex to migrate smoothly
Every agency has at least a few sites that nobody wants to touch. The one with unusual redirect logic. The one built on Bedrock. The one with reverse proxy rules, custom Nginx directives, multisite mapped to client domains, or API integrations that nobody fully documented.
“Complex” does not mean “immovable.” It means the preparation phase has to be more thorough.
Successful migrations of complex sites have one thing in common: the people running the migration wrote down how the site actually works before touching anything. That means documenting custom rewrites, scheduled tasks, external services, access rules, hard-coded path references, plugin dependencies, custom database tables, and environment-specific behaviour. Bedrock and Roots stacks, subdomain or subdirectory multisite networks, Apache-to-Nginx rule translation, non-standard file structures, these are standard items in a professional migration checklist, not exotic edge cases.
Custom setups fail during migration when nobody mapped the environment before the move. When the mapping exists, complexity becomes a project management variable, not a reason to stay put.
How Servebolt handles this: Servebolt’s migration team regularly handles a wide range of technical configurations, so your custom setup likely isn’t as unique as it appears. If you are using a non-standard setup, we ask you to document it, and we will tell you exactly what we need to know. The complexity does not disappear; it gets planned for. Security is also treated as part of the migration scope, not an afterthought: custom access rules, IP restrictions, and environment-specific security configurations are ported, reviewed, and validated as part of the handover. Crucially, for every migration we do, we document the entire process step-by-step within the assigned internal ticket. This ensures complete transparency. By logging exactly how the migration is structured, we can reliably replicate the process for the final sync, ensuring everything works perfectly before we proceed with the live migration.
Myth 7: Migration is too expensive and too time-consuming to justify
This framing gets the accounting wrong.
The cost of migration is visible: dev time, a brief period of elevated attention, potentially a migration service fee. What rarely gets calculated is the ongoing cost of not migrating, and for agencies, that ongoing cost is real and recurring.
An agency managing client sites on infrastructure that cannot handle concurrency without queuing absorbs that burden every single month. The support tickets when a campaign drives traffic, the server cannot handle. The developer hours spent firefighting instead of building. The WooCommerce checkout that slows under load and costs the client revenue, they will eventually notice. The awkward conversation when a client’s Black Friday sale underperforms, and they want to know why.
The performance data is specific. The Deloitte and Google study found that a 0.1-second mobile speed improvement increased retail conversions by 8.4% and average order value by 9.2%. Travel conversions improved by 10.1%. These are not marginal gains. For a WooCommerce store doing $500,000 a year, an 8.4% conversion improvement is $42,000 in recovered revenue. The Portent dataset puts the contrast in even starker terms: an ecommerce site loading in one second achieves a 3.05% conversion rate; the same site at five seconds converts at 1.08%. That gap belongs somewhere. The question is whether it belongs to your client’s business or to their current hosting provider’s inability to serve concurrent requests.
For agencies, the honest calculation is not “migration costs X.” It is “what has the current stack cost us over the last 12 months in support burden, developer hours, and client outcomes, and what does that number look like over the next 12?”
How Servebolt handles this: For agency partners, migration is included, not sold as an add-on. There is no billable dev time for the migration itself, and no “migration fee” that quietly doubles the cost of switching. We also give agencies a Servebolt Proof before any commitment: we migrate a full copy of your heaviest client site to our infrastructure, run performance benchmarks on both environments, and review the results with you. You see the TTFB data and the overall page speed improvements on your actual site, not a generic demo, before a single client contract changes hands. If the numbers do not justify the move, we will tell you.
Myth 8: If you are migrating anyway, do all the changes at once
This is the most operationally dangerous myth on this list, and it is particularly common in agencies where migration gets bundled into a larger “while we’re in there” project.
Migration is one variable. A redesign is another. A plugin overhaul is a third. A URL restructure is a fourth. Deploying all of them simultaneously does not save time, it multiplies the diagnostic surface area if anything goes wrong after launch.
Google separates hosting-only changes from site moves that involve URL changes specifically because they carry different risk profiles. The most common post-migration problems are not caused by the infrastructure move itself. They are caused by changes that happened alongside it, making it impossible to isolate what caused the symptom.
The correct sequence is to move the site as-is first. Validate that it performs correctly on the new infrastructure. Confirm that all functionality: forms, checkout, integrations, cron jobs, redirects, behaves identically. Once the site is stable and hosting has been proven, deploy improvements.
How Servebolt handles this: Our migration brief is explicit on this point: we move the site as it exists. Not as you wish it existed, not with the new theme you have been planning, not with the plugin changes you have been meaning to make. We move the current site, validate it, hand it over, and then you have a stable, faster platform to build improvements on. Performance gained from better infrastructure is immediately visible and attributable. Changes layered on top of it can be tested and validated cleanly. Agencies that fold redesigns into migrations often spend more time on post-launch diagnosis than they saved on coordination.
Myth 9: You will have to migrate again when you grow
The logic sounds prudent: “Even if we move now, we will outgrow the new environment eventually. Why disrupt clients twice?”
This is almost always a rationalisation for staying on infrastructure that is already underperforming. And it trades a manageable one-time cost now for an ongoing cost every month until the inevitable second move.
The better question is not whether growth will eventually create new infrastructure needs. Of course it will. The better question is whether the next hosting environment gives you enough headroom, tooling, and support quality to avoid another disruptive move for long enough that the economics justify the first one.
Many hosts “scale” by moving you to different physical hardware, which is itself a migration. Infrastructure built for genuine vertical and horizontal scaling, where performance headroom is architectural rather than bolt-on, does not force that tradeoff. For agencies managing client sites through campaign peaks, seasonal traffic spikes, and the kind of WooCommerce growth that marks a successful client engagement, a host that handles concurrency without additional configuration is a fundamentally different operating model than one that requires caching workarounds and capacity planning every time a campaign performs.
How Servebolt handles this: Servebolt’s infrastructure is built for full scalability without the traditional migration model. When a client campaign succeeds and traffic triples overnight, the platform absorbs it. There is no “you have outgrown this plan, please migrate to a new server” moment, which, on a traditional VPS or shared cloud provider, is itself a disruptive migration in disguise. Our Linux 8 stack is optimized at the OS level for the hardware it runs on, which means performance headroom is structural, not dependent on adding layers of caching to compensate for an undersized server. For agencies managing 5–50+ client sites, that architectural difference compounds significantly over a year of client growth.
Myth 10: Automated migration plugins are the safest option
Plugins are accessible. They are not reliable for production-grade WooCommerce sites.
The failure modes are well-documented and consistent: time-outs on large databases, file permission errors, incomplete handling of serialized data, inability to tune the environment for the destination server’s specific architecture. A plugin can move files. It cannot verify that the environment is configured correctly for the site it just moved. It cannot translate Apache rules to Nginx. It cannot perform a final delta sync that prevents order data from being lost during the switchover window.
For a personal blog or a simple brochure site, an automated plugin might be fine. For a WooCommerce store processing real transactions, or a high-traffic WordPress site where the client relationship depends on the migration going cleanly, the risk profile is different. The plugin gets the files there. Expert-led migration gets the site there: configured, validated, and tuned for the architecture it is now running on. The distinction matters because “moved” and “working correctly” are not the same thing.
How Servebolt handles this: We avoid using migration plugins for client site migrations. If we have the necessary access, our engineers use SSH-based rsync transfers, WP-CLI for database operations, and direct server-level tooling for environment configuration. There are instances where we only receive wp-admin access without FTP, SFTP, or SSH credentials. In those specific scenarios, we do have to use a tool like the WordPress Duplicator plugin, but direct server access is always our primary and preferred method.
Every migration closes with a structured validation process, not just a plugin status screen. When a standard plugin reports “migration complete,” it simply means the files arrived. When our engineers complete a migration, we perform essential frontend and backend checks to catch and resolve obvious issues. We ensure the core foundation is working correctly on the new infrastructure, relying on your agency’s deep knowledge of the client site to perform the final complex workflow validation before the DNS changes.
What agencies should do before any migration
A smooth migration is decided largely before launch day. Here is the practical framework.
Separate the migration type. Are you changing hosting only, changing domain or URLs, or both? Google maintains separate guidance for each because the workflows and SEO implications differ significantly.
Crawl and benchmark the current site. Before anything else, capture key URLs, redirect chains, canonicals, Core Web Vitals baselines, top landing pages, conversion pages, and analytics benchmarks. That data gives your team an objective standard to validate against after launch.
Clone and test before cutover. Google explicitly recommends building and testing a complete copy of the site on a temporary hostname before any DNS changes. Test all user-facing functionality: forms, checkout, media, downloads, integrations. Find problems before visitors do.
Lower DNS TTL in advance. Both Google and Cloudflare identify TTL as a key lever for faster propagation. Reduce it several days before the planned cutover, not at the last minute.
Inventory custom logic. Document every cron job, rewrite rule, email routing configuration, external API integration, plugin dependency, custom table, and environment-specific setting. If it is not written down, it will be found the hard way during QA.
Preserve SEO signals. If URLs must change, use permanent server-side 301 or 308 redirects and maintain a clean old-to-new mapping. Google explicitly recommends permanent redirects for moved URLs. Do not leave ranking equity stranded on URLs that no longer exist.
Monitor after launch. Watch crawl rate, indexing signals, DNS propagation, and Search Console in the days following cutover. High-value templates and conversion pages get attention first.
The real risk is not migration, it is staying stuck
The market is full of agencies quietly carrying technical debt on behalf of their clients. They compensate for underpowered hosting with extra plugin layers, more caching complexity, more support hours, and more tolerance for mediocre performance than any client-facing business should accept.
That hidden burden accumulates. And when hosting infrastructure limits what your clients can achieve in search visibility, in conversion rate, and in campaign performance, keeping them on the wrong stack is not the safe option. It is often the more expensive one.
Agencies that understand this stop asking “What if migration causes problems?” and start asking “How much are these current hosting problems already costing us?”
Why agencies move to Servebolt
For agencies managing WooCommerce stores and high-traffic WordPress sites, the goal is not just to move hosts. It is to reduce support burden, protect client trust, and give the portfolio infrastructure that can handle real production load without workarounds.
Performance and scalability are the two variables that matter most for agencies at scale and they are exactly where most managed WordPress hosts run out of runway. Standard managed hosting plans cap PHP workers at 2–6 per site. Under WooCommerce concurrency, logged-in users, active carts, checkout flows, those workers queue, response times climb, and the checkout experience degrades in the exact moments that matter most to your client’s revenue. Edge caching provides no relief here: dynamic WooCommerce content bypasses it entirely.
For agencies, that translates directly: fewer performance escalations, less reactive support, and client sites that hold up when the traffic arrives rather than queuing until it clears.
Want to see the difference on your own sites before committing to anything? You don’t have to take our word for it. Put us to the test. We migrate a copy of your heaviest client site to our infrastructure, run benchmarks on both environments side by side, and review the results with you. Same store. Same plugins. Same theme. Different infrastructure. The performance difference becomes tangible – your own product pages, your own checkout flow, your own TTFB data, before a single client contract changes hands.
