A client is hitting their limits, and the server's other customers are noticing. Two situations look identical from the outside and need opposite responses.
The immediate problem is everyone else
Before diagnosing anything, note the actual urgency: one account consuming the machine's processing is degrading service for people who did nothing.
That makes this a support issue with a clock on it, not a sales conversation to have next week. If the impact is severe, limiting that account temporarily is defensible, and tell the client you have done it, immediately, with the reason.
Signs it is fixable
No caching. By far the most common. Every visit rebuilding the page from the database costs many times what a cached page does, and enabling caching regularly resolves the whole situation.
One expensive component. A plugin running queries on every page load, or a query with no index. One thing is usually responsible for most of the load.
Automated traffic. Crawlers and scanners consuming real processing while the client's actual visitor numbers have not changed. For that, see stopping bots and scrapers.
Slow only at busy hours. That is a queue instead of a shortage, and caching removes it.
All four follow the client to a bigger server. Selling an upgrade without mentioning them means the same conversation again in three months, with less credibility.
Signs it is real
Caching is working. The application is lean. The account is at its ceiling during ordinary traffic rather than during occasional spikes. The pattern is consistent rather than intermittent.
That is a site that has outgrown the plan, which is a good outcome for the client and should be presented as one.
Diagnose before recommending
Half an hour of looking is worth more than any conversation about plans.
Check whether caching is enabled at all. Look at the access log for a single dominant source or path. Compare the traffic pattern against the resource usage graph. Telling whether a slow site is the server or the site goes into the measurement that separates the cases in two commands.
Doing this first also makes the recommendation credible, whichever way it goes. "I looked, here is what I found" is a different conversation from "you need a bigger plan".
The conversation
Lead with what you found, not with the product.
If it is fixable: say what is wrong, what fixing it involves, and whether that is work you will do or work they need done. Be clear about which is billed. What support to include and what to charge for explains drawing that line before you need it.
If it is growth: say so plainly. "Your site has outgrown this plan" is good news delivered as information. Then be honest about what a VPS involves, because a client who moves and cannot administer it becomes a much larger support burden than they were. Moving from shared hosting to a VPS walks through what changes.
Managed, or not
The client who has outgrown shared hosting usually cannot run a server, and this is the decision that determines whether the move succeeds.
Either sell the administration alongside it, or be explicit that they need someone who does. An unmanaged VPS handed to a client who expected hosting is an outage waiting to happen and it will be attributed to you.
Price the management honestly. It is real recurring work.
Move deliberately
Set the new environment up, test the site there, and cut over with a lowered TTL: planning a DNS cutover deals with the sequence, and keeping the old account running for a week costs little and covers what you missed.
A migration that goes badly turns a growth story into a grievance, and this is the moment a client is most likely to look elsewhere.
Watch for the pattern
If several accounts on one server keep reaching their limits, the plan's limits may be set below what the plan promises, or the server may be carrying more than it should.
That is worth examining as a pattern rather than handling one client at a time. Creating and managing hosting packages goes into setting limits you can defend.
Show the customer the numbers rather than the conclusion
A recommendation to spend more money is received differently when it arrives with evidence.
grep -c . ~/logs/example.com
awk '{s+=$10} END {printf "%.1f GB\n", s/1073741824}' ~/logs/example.com
du -sh /home/username 2>/dev/null
Three figures do most of the work: how many requests a month, how much data that moved, and how much space the account holds. Each is a fact rather than an opinion, and each has grown for a reason the customer usually recognises.
Present the trend rather than the current value. A customer looking at three months of growth reaches the conclusion themselves, and a conclusion reached rather than delivered is one they act on.
Be honest about what moving does not fix
A larger plan solves capacity. It does not solve a site that is slow because of how it was built, and promising otherwise creates a customer who is unhappy after spending more.
curl -s -o /dev/null -w 'ttfb %{time_starttransfer} total %{time_total}\n' https://example.com/
uptime
A slow response on a machine with idle processors and free memory is not a capacity problem. Moving that site to a larger plan produces the same response time on more expensive hardware.
Saying so costs a sale now and prevents a refund and a complaint later. It is also the conversation that makes the eventual upgrade, when capacity really is the constraint, one the customer believes.
Plan the move before agreeing to it
A customer who agrees to upgrade expects it to happen soon, and the parts that take time are not the ones they imagine.
Establish first: how large the account is and therefore how long a copy takes, whether the site can be read only for that period, where the DNS is hosted and what the record lifetimes are, and what has to be reconfigured on the new machine.
du -sh /home/username; find /home/username -xdev 2>/dev/null | wc -l
dig example.com A | awk '/^example/ {print "TTL:", $2}'
The file count matters more than the size for a copy, since a million small files take far longer than a few large ones. Lower the record lifetime days ahead, not on the morning of the move. Transferring cPanel accounts between servers covers the mechanics.