Self-hosting has many advantages. You have full control, costs are predictable, and you are not dependent on a platform you don’t own. For the right situation, it’s the right solution.
However, most businesses that self-host didn’t make that choice deliberately. They chose it years ago because it was the cheapest option, and they’ve been stuck with it ever since. The question of whether it’s still the right choice rarely comes up until something breaks.
These are the signals I’d pay attention to.
The person who set it up is gone
This is the most common and underestimated issue.
Self-hosted infrastructure set up by someone who has since left the company is a slow-motion problem. It works until it doesn’t, and when that happens, no one knows why. The configuration probably exists somewhere, but it is most likely undocumented. The logic behind decisions made two or three years ago is now mostly guesswork.
I’ve encountered situations where a server had been running untouched for four years because everyone was afraid to update it. That fear is rational. It’s also a sign that the setup has outgrown the team’s ability to maintain it.
If the only person who fully understood your infrastructure is no longer around, that’s not a stable situation. It’s a ticking clock.
You’re spending meaningful time on maintenance that isn’t your business
Each hour your team spends managing servers, renewing certificates, debugging failed backups, or investigating spikes in disk usage is an hour not spent on the product or customers.
For a software company, this trade-off made sense at one point. But when you’re watching every euro and a managed service costs three times as much as a VPS, you make the VPS work. That’s fine.
However, the calculation changes as the business grows. At some point, the engineering time spent on infrastructure incurs real costs, even if they don’t show up on a hosting bill. A managed platform that costs €200 more per month but eliminates four hours of maintenance work per week is almost always the better deal.
The question is whether anyone has done that recently.
You’ve had more than one incident in the past year that surprised you
One unexpected outage or data issue is just bad luck. Two or more in twelve months, however, is a pattern.
Self-hosted infrastructure quietly accumulates technical debt. Updates are skipped because there’s never a good time. Monitoring is set up but not tuned, so either alerts fire constantly or not at all. Backups run, but no one checks if they work properly.
These issues don’t announce themselves as problems. They just sit there until a combination of circumstances turns them into one. If your setup has been producing surprises, they are telling you something about the state of your infrastructure.
Your compliance situation has changed
A business that starts with a few customers and no particular data sensitivity can quickly find itself in a situation where compliance matters. For example, GDPR applies if you’re serving European customers. SOC 2 compliance may be necessary if an enterprise prospect requests it. The same goes for ISO 27001 if you’re moving into certain industries.
Self-hosted infrastructure can satisfy these requirements, but doing so requires deliberate effort in the form of documented processes, audit trails, access controls, and incident response procedures. Managed platforms handle a significant portion of these requirements by default and come with certifications that simplify the compliance conversation.
If your compliance requirements have grown but your infrastructure hasn’t kept pace, that’s a real risk—and often a quiet one.
Your team is spending time on infrastructure instead of product
This one is specifically for software companies.
There’s a version of infrastructure ownership that makes sense for product companies: you’re building something that requires tight control over the stack, or your infrastructure genuinely differentiates your product. However, for most small software companies, hosting is not the product. It’s overhead.
When engineers are frequently pulled into server issues, it delays the roadmap. When deployment is a stressful event rather than a routine one, it’s a symptom. Onboarding a new developer should not require half a day of infrastructure setup.
Managed platforms and cloud services have improved and become more affordable, so “we can’t afford to move” is less often true than it used to be. More often, nobody has made time to evaluate the move because the current setup works well enough to avoid forcing the conversation.
What moving actually involves
The reason businesses remain on self-hosted infrastructure longer than necessary is rarely cost-related. It’s the migration itself.
Moving a running system is hard work. There’s a risk of downtime, data migration, DNS changes, dependency mapping, and testing in the new environment. For a small team, that’s a project that competes with everything else on the list.
The key to making it manageable is to scope it accurately before starting. Not everything needs to be moved at once. Begin with the piece that causes the most pain or poses the greatest risk. Migrate it, stabilize it, and then move on to the next piece. Although a phased approach takes longer, it is almost always safer and less disruptive than a big-bang migration.
How to know if it’s time
It’s worth having the conversation if more than one of these applies to your situation:
- The person who built and maintained the setup is no longer around
- Your team is spending time on infrastructure that would be better spent elsewhere
- You’ve had more than one unexpected incident in the past year
- Your compliance requirements have grown beyond what your current setup was designed for
- A migration keeps getting pushed because there’s always something more urgent
None of these mean that you have to move immediately. However, they do mean that maintaining the status quo comes at a cost.