The Inherited Hosting Problem
Every growing agency reaches the point where a significant portion of their client portfolio is hosted on infrastructure that was never appropriate for a business website. IONOS because the client saw a TV ad in 2018. GoDaddy because it was the default when they registered their domain. Bluehost because someone in a Facebook group recommended it three years ago.
These clients are a liability in ways that aren’t always obvious until something goes wrong. This article makes the case for proactively moving them — not because it generates revenue for your agency (though it does), but because leaving them where they are creates ongoing risk for you and for them.
Why Bad Client Hosting Is an Agency Problem
The instinct is to treat client hosting as their problem. They own the site, they pay for the hosting, they manage the relationship. What happens on their server is their business.
This position is comfortable until the first incident.
When a client’s site goes down, they call their agency. When their site is hacked, they call their agency. When their WooCommerce store times out during a campaign, they call their agency. Whether or not the hosting relationship is formally your responsibility, you are the first call.
More practically: if you’re building and maintaining sites on poor infrastructure, you’re building on sand. A plugin update that would be routine on managed hosting becomes a potential incident on an underpowered shared server. A malware injection that managed hosting would have caught and blocked becomes a clean-up job you’re either billing for or absorbing.
The quality of the infrastructure directly affects the quality of the work you can deliver.
The Specific Problems With Common Budget Hosts
IONOS: Shared infrastructure with no staging and minimal WordPress management. Support that is not equipped to diagnose WordPress issues. Introductory pricing that obscures the true cost. No published SLA with compensation terms.
GoDaddy: US-based infrastructure adds latency for UK visitors. Support operates on US Central Time. “Managed WordPress” branding that doesn’t reflect genuine WordPress management. Security add-ons sold separately from the base product.
Bluehost: US infrastructure with no UK data centre option. Support with US Central Time hours. No meaningful SLA. Daily backups are an add-on rather than included.
Generic cPanel shared hosts: Variable PHP worker allocation. No staging. Support that escalates to server administrators who don’t understand WordPress. Often no malware detection until the site is already compromised.
The common thread: these platforms are built for volume, not for quality. They work adequately for personal sites and low-stakes applications. They are inappropriate for business websites, and particularly inappropriate for WooCommerce.
The Risk Audit
Before starting the conversation with a client, do a quick audit of what they’re currently on and what the actual risk exposure looks like.
Questions to answer
- When was the last verified backup, and where is it stored?
- Is there uptime monitoring in place? Who gets alerted?
- Is there a staging environment for testing updates?
- What’s the hosting support response time for a critical issue at 6pm on a Friday?
- Is there a WAF in place? Is malware scanning active?
- Is the site’s PHP version current? If the answers are “I don’t know” to most of these, you have the basis for a conversation about risk — not a hosting sales pitch.
Prioritising Who to Move First
You likely can’t move all clients at once. Prioritise by risk and value:
Move first
- WooCommerce stores where downtime has direct revenue impact
- Clients in regulated sectors (legal, healthcare, financial services) where data security is a compliance concern
- Clients who have had an incident in the last 12 months and don’t know how it was resolved
- Clients on hosting that is explicitly incompatible with your support scope
Move second
- Business websites where the client actively generates leads or enquiries through the site
- Clients whose hosting contract is up for renewal in the next quarter
Move when convenient
- Brochure sites with low traffic and minimal commercial function
- Clients who explicitly prefer to manage their own hosting and accept the risk
The Migration Conversation
The cleanest approach is to make the move as part of something else: a site redesign, a contract renewal, a quarterly review. This avoids the perception that you’re selling hosting for its own sake.
“As part of this redesign, we’re moving your site to managed hosting infrastructure. This gives you daily backups, proper uptime monitoring, and a WAF — things your current setup doesn’t have. The ongoing hosting cost is [£X/month], which I’ve included in the project proposal.”
For existing clients on retainer without a current project: “As part of reviewing our client hosting portfolio this quarter, we’d like to move your site to managed infrastructure. Your current setup doesn’t have [backup/staging/monitoring] in place, which creates unnecessary risk. The change costs an additional [£X/month] on your retainer.”
Be specific about what’s missing. Generic “better hosting” is easy to dismiss. “You currently have no staging environment, which means every update goes directly to your live site, and I can’t test changes safely” is a concrete problem that most clients understand.
What to Do When Clients Resist
Some clients will resist, particularly if they’re paying very little for current hosting and the number anchors them. Two things to try:
The liability conversation: “If your site is hacked and customer data is compromised, I need to be able to tell you I did everything I could to prevent it. On your current hosting, I can’t say that. The risk isn’t just to your business — it’s to the data of every customer who’s ever submitted a form on your site.”
The total cost conversation: “Your current hosting is £5/month. But when your site had that issue last February, that took us four hours to resolve — at our standard rate, that’s £400 of support time. Managed hosting at £25/month pays for itself in one avoided incident per year.” (Adjust the numbers to match your actual history with the client.)
If a client still refuses after both conversations, document it. A written record that you recommended managed hosting and the client declined protects your agency if an incident later occurs and blame starts being allocated.
Making Migrations Smooth
The logistics of moving a client from IONOS or GoDaddy to managed hosting need to be seamless or the conversation about why they should move becomes the conversation about the problems the move created.
On WP Pro Host, migrations are fully handled — we take on the DNS, SSL, database, and file transfer with a staging test before any DNS cutover. The client doesn’t need to do anything and shouldn’t notice any disruption.
For your agency workflow, the key steps are:
- Gather all credentials before starting (hosting, domain registrar, any third-party services that reference the old server IP or domain)
- Test the migrated site on staging before touching DNS
- Reduce DNS TTL to 300 seconds 24 hours before cutover
- Brief the client that they may see brief caching inconsistencies during propagation — this prevents “it looks weird on my phone” support calls
- Keep the old hosting account active for at least 48 hours after cutover as a rollback option
The Portfolio View
Once you have a managed hosting standard across your client portfolio, the operational benefits compound. You’re supporting one type of infrastructure rather than five. You know what’s available and what isn’t on every client’s site. Your staging process is consistent. Your update workflow is consistent. Your support escalation path is consistent.
The agencies that do this well treat it as infrastructure standardisation, not as a sales exercise. The revenue follows from the operational clarity, not the other way round.
Frequently Asked Questions
How should agencies approach moving clients from shared to managed hosting?
Frame the conversation around risk and performance, not cost. Do not lead with “your hosting is bad” — lead with “your site has outgrown its current infrastructure” or “we’ve identified a way to improve your site’s speed and security.” Present specific evidence: current TTFB versus managed hosting benchmark, Core Web Vitals scores, any past incidents. Offer to handle the migration as a project with a clear deliverable and zero downtime commitment. Price the migration as a managed service, not a technical task — clients pay for the outcome (faster, more secure, reliably managed infrastructure) rather than the technical hours.
What are the most common reasons client sites need to move off budget hosting?
The five most common triggers: a security incident (malware, compromise, or sustained brute force attack that the budget host cannot adequately address), performance degradation (site has grown beyond what shared hosting resources can support, manifesting as slow TTFB, checkout failures during traffic spikes, or slow WooCommerce admin), hosting provider reliability failures (repeated outages, unresponsive support, announced service changes), business growth that increases compliance requirements (GDPR, PCI DSS, sector-specific obligations that require documented infrastructure security), and agency portfolio standardisation (the agency decides to consolidate all client sites onto one managed platform for operational efficiency).
How do agencies prioritise which clients to migrate first?
Prioritise migrations by risk and impact: first, WooCommerce stores on shared hosting (highest risk of checkout failures and revenue loss, most to gain from performance improvement), then high-traffic sites with measurable SEO or conversion impact, then any client in a regulated sector with compliance obligations, then professional services sites with active lead generation, and finally lower-traffic brochure sites that can tolerate staying on current infrastructure longer. Start with 2-3 lower-complexity sites to refine the migration process before tackling the most complex clients.
What objections do clients raise about moving hosting and how do agencies respond?
“It’s working fine” — respond with specific performance data: actual TTFB measurements, Core Web Vitals scores, and any past incidents. “It’s too expensive” — present the total cost analysis including the cost of a single incident on cheap hosting versus the annual managed hosting fee. “I don’t want the disruption” — emphasise the zero-downtime migration process and the agency’s full management of the technical transfer. “My current host is good enough” — compare specific capabilities: site isolation, staging environments, PHP workers, Redis caching, WAF. Vague objections become harder to maintain when faced with specific evidence.
What happens operationally when all agency clients are on the same managed hosting?
Portfolio standardisation creates compounding operational benefits: one control panel interface for all sites (faster navigation, fewer login credentials), one support escalation path for all hosting issues (build a relationship with one provider’s support team), consistent staging and deployment workflow across all projects (developers become faster with practice on a familiar platform), one backup and restoration process for disaster recovery (documented once, applied consistently), and predictable monthly costs for budgeting and client care plan pricing. Agencies that reach full portfolio standardisation typically find their hosting-related support overhead drops by 50-70% compared to managing five different hosting environments.
· Building Hosting Into Your Agency Retainer · Agency Partner Programme