Shared hosting is the right ground to start: cheap, managed, and enough. The mistake is not starting there. It is staying after the project starts paying (in slowness, lost sales, and support hours) the price of a design that no longer fits.
"When should we leave?" has an objective answer. Four signs, and two of them in the last quarter end the discussion.
The 4 signs it is time
1. Resources hitting the account cap. On shared hosting, CPU and concurrent processes are rationed. If the panel shows usage pinned at the ceiling at peak (or the provider warns about throttling), the site is measurably leaving money on the table.
2. Slowness that only shows at peak. Fast site on Tuesday at 10am, slow on the Friday campaign at 8pm is no mystery: that is the rationing working. Peak is exactly when performance becomes revenue, and exactly when shared hosting delivers least.
3. Resource requests denied. You need a PHP version, an extension, a cache tweak, and the answer is "not possible on this plan". When the business architecture starts being defined by plan limitations, the plan has become the product’s bottleneck.
4. The add-on invoice reached VPS prices. Paid cache, paid CDN, paid scaling, paid priority support: when the extras approach R$ 100 a month, the cost argument for shared hosting is gone. Tech86’s VPS line starts at R$ 106 (1 vCore, 1 GB RAM, 25 GB SSD, 100 Mbps), with the VPS 2 Cores at R$ 152.
What actually changes on a VPS
Three concrete gains, in the order they appear:
- Isolation: your usage does not fight neighbors, and another account’s peak cannot take your site down. This ends the most common shared-hosting incident category.
- Control: full root, versions and extensions measured to your application, your own cache, backup, and security rules. The server adapts to the application, not the other way around.
- Predictability: the plan’s ceiling is known, and growing is your decision with one click (Tech86 upgrades need no reinstall), not a contract negotiation.
The price of that is honesty about responsibility: on a VPS, system administration is yours. For those who do not want (or cannot carry) that, the answer is managed VPS or managed cloud, where the operation stays with the vendor. We have written about when latency and location call for migration; the capacity decision comes before that one.
The migration that takes nothing down
The full method is in this article’s howTo, and the summary is: new environment up before touching the old one, validation with real data, DNS with short TTL and the old plan active through propagation, final backup before cancelling.
A well-run migration has zero downtime. A rushed one has undefined downtime. The difference between them is one week of planning.
Conclusion
Leaving shared hosting is not a status move, it is arithmetic: when the signs appear, every month of waiting has a price in slowness and lost sales, and an entry VPS costs less than the add-ons masking the problem.
The simplest test: open the panel and check CPU usage over recent peaks. Pinned at the ceiling? The migration date has passed. With headroom? Keep this article for the day it is not, because on every project that grows, that day comes.