Deutsch
Growing beyond shared hosting is not a feeling and it is not a traffic milestone. It is a diagnosis: the current hosting account is limiting a measured workload, a required service, or a control you genuinely need. This guide helps you collect that evidence, decide whether your team is ready to operate a self-managed VPS, and migrate without turning DNS cutover into a one-way door. For the broad feature-by-feature choice, read Shared Hosting vs VPS; this page stays focused on migration signals and readiness.
Evidence that shared hosting is the constraint
Start with the hosting account, application monitoring, and provider notices. Record the time, duration, affected request, response code, and any CPU, memory, process, input/output, or database limit shown by the control panel. Compare those events with application logs and a simple external uptime check.
A slow page alone does not prove that shared hosting is the cause. An oversized image, an uncached query, a failing third-party API, or a plugin conflict can remain slow after migration. Build a small evidence table before changing platforms:
| Observation | Evidence to capture | Readiness decision |
|---|---|---|
| Requests slow at peak time | Server timing, application log, resource chart, response code | Migrate only if the host limit aligns with the slowdown |
| Background work stalls | Queue depth, cron history, worker limit, failed-job log | Define required concurrency and retry behavior |
| Database time increases | Slow-query log or application timing, connection errors, working-set estimate | Fix query/index problems and size the new database deliberately |
| Storage approaches a limit | Current use, monthly growth, temporary-file and backup peaks | Budget normal growth plus maintenance headroom |
If the evidence points to application code or an external dependency instead, correct that first and repeat the measurement. A VPS changes the operating boundary; it does not automatically repair the workload.
PHP, worker, and scheduled-job limits
Shared plans often expose limits through a control panel or support documentation. Identify the exact values that affect your site: concurrent PHP workers or processes, memory per process, execution time, scheduled-job frequency, and whether long-running workers are permitted. Then measure the actual demand during an ordinary busy period and an expected peak.
A VPS becomes relevant when a required, understood workload cannot run within the present plan and the application cannot reasonably be simplified. Write down the web-server, PHP, queue, and scheduler configuration you intend to test. Do not treat root access as a performance setting: it gives you control, but you still have to configure limits, observe saturation, and prevent one service from exhausting the guest.
Database and storage constraints
Separate database symptoms from general page latency. Look for connection-limit errors, lock waits, slow queries, memory pressure, and storage input/output contention. Estimate the active database working set, peak connection count, write volume, and maintenance space required for imports, indexes, and temporary files.
Also chart storage growth rather than copying only today's file total. Include uploads, logs, caches, databases, staging data, and independent backups. The destination needs enough space for normal operation and the temporary duplication created during migration. If poor queries are the primary constraint, tune and retest them before buying more server resources.
When you need software or network control
Migration may be justified even when performance is acceptable. Your application might require a supported operating system, a specific PHP or database version, a customer-installed proxy, a persistent worker, a private service, custom firewall rules, or server-level observability that the shared plan does not expose.
List each requirement and label it either mandatory or convenient. Confirm the software supports your chosen operating system and decide who will install, update, monitor, and recover it. Virtarix provides self-managed infrastructure; customer-installed software and its configuration remain customer-managed.
Traffic patterns that need a different operating model
Use traffic shape, not monthly visits, as the planning input. Record peak requests per second, concurrent sessions, uncached request share, upload or download behavior, scheduled bursts, and the business cost of an error during a peak. Test the representative workload against explicit latency and error thresholds.
Irregular peaks need a runbook as much as capacity. Decide what the system should shed or queue when demand exceeds the tested boundary, which alert should fire, and who responds. Do not assume an unspecified resize mechanism will rescue an overloaded system. Select and test enough headroom for the workload you can defend with evidence.
Security control is also security responsibility
A VPS gives the customer control over operating-system access, firewall policy, services, users, and updates. That control can support a security design, but an unpatched or misconfigured self-managed server can be less secure than a shared account whose server layer is maintained by the host.
Before migrating, assign owners for operating-system updates, application updates, SSH keys, least-privilege access, firewall changes, log review, vulnerability response, backups, and restore tests. Document how access is removed when a person leaves the team. If nobody can own those tasks, the correct next step may be a managed service from a provider that explicitly offers it, not a self-managed VPS.
Operational readiness for a self-managed VPS
Do not schedule the move until every row has a named owner and a testable answer:
| Responsibility | Evidence required before cutover |
|---|---|
| Build | Reproducible operating-system and service configuration |
| Access | Named administrators, protected keys, and a recovery-access procedure |
| Patching | Maintenance owner, schedule, and emergency-update path |
| Monitoring | External availability check plus resource and application alerts |
| Recovery | Independent backup, documented restore procedure, and completed restore test |
| Incident response | Contact path, triage checklist, and authority to roll back |
The migration itself is customer-managed. Budget time for configuration, security hardening, data transfer, testing, monitoring, and rollback; the server price is not the total operating cost.
Current Virtarix facts for a migration test
If the evidence and ownership checks support a VPS trial, use current plan facts as test inputs rather than as performance promises. Virtarix Cloud VPS S has the following standard specification:
| Fact | Cloud VPS S |
|---|---|
| Standard monthly price | $5.50/month |
| CPU | 3 CPU cores |
| RAM | 6 GB |
| Storage | 50 GB NVMe |
| Bandwidth | Unlimited* |
| Access | Full root |
| Network | IPv4 + IPv6 |
| Recovery inclusion | One backup and one snapshot |
| Live VPS locations | Dallas, Frankfurt, Johannesburg |
\* Unlimited bandwidth is subject to fair use, acceptable-use requirements, network integrity, and service limits.
Virtarix is self-managed. The included backup and snapshot do not replace customer-owned copies or an independent recovery plan. The table does not promise application throughput, migration assistance, a resize method, backup retention, or a restore mechanism. Benchmark the intended workload and complete a restore test before treating the destination as ready.
Migration checklist from backup to monitoring
Complete these steps in order and record the evidence for each one:
- Inventory and baseline: List domains, DNS records, files, databases, users, scheduled jobs, mail dependencies, certificates, redirects, environment variables, and third-party integrations. Capture current latency, error rate, and peak-resource evidence.
- Independent backup: Create customer-owned copies of application data, databases, configuration, and required secrets. Verify file integrity and perform a restore into an isolated test location.
- DNS preparation: Record the current zone, lower relevant TTL values far enough in advance for the previous values to expire, and define who can change and reverse each record.
- Build staging: Install and harden the supported operating system and customer-managed services. Reproduce the required runtime, access rules, firewall policy, scheduled jobs, logging, and monitoring without directing public traffic to it.
- Copy and test data: Transfer an initial copy, preserve ownership and permissions, import databases, and test the site through a hosts-file override or private staging name. Keep staging from sending real customer notifications or processing live transactions.
- TLS preflight: Confirm the destination can serve every required hostname with a valid certificate at cutover. Do not disable certificate verification to make a test pass.
- Plan the final sync: Define the maintenance window, write freeze or delta-copy method, expected transfer duration, responsible people, and the exact data-consistency check.
- Define rollback: Record the previous DNS values, old-host state, rollback authority, and measurable triggers such as error rate, failed critical transactions, or unresolved data divergence. Set a rollback decision deadline.
- Cut over: Apply the write freeze or final delta sync, validate the final data state, change only the planned DNS records, and timestamp every action.
- Smoke test: Test the homepage and critical routes, authentication, forms, database writes, uploads, background jobs, scheduled jobs, redirects, certificates, integrations, and any business-critical transaction from outside the server.
- Monitor: Watch external availability, application errors, CPU, memory, storage, database behavior, worker queues, and certificate state throughout the rollback window.
Cutover, rollback, and old-host retention
Keep the previous host intact and prevent conflicting writes while DNS caches converge. If a defined rollback trigger occurs, stop the cutover, restore the prior DNS values, return writes to the known-good system, and reconcile any data created during the attempted move. DNS rollback is not data rollback; the runbook needs both.
Do not cancel the old account because one browser test passed. Retain it until the agreed rollback window has ended, independent checks resolve to the new destination, critical workflows have passed, monitoring is stable, and the final customer-owned backup has been verified. Only then schedule decommissioning and securely remove obsolete credentials and data.
When not to migrate to a VPS
Do not migrate yet when the constraint is unproven, the application defect has not been isolated, no one owns server operations, the recovery procedure has not passed a restore test, or the cutover has no reversible plan. A better shared tier or a genuinely managed service may fit the evidence and the team's responsibilities more closely.
Decision record
Finish with a short record that another operator can review: the measured constraint, rejected alternatives, required controls, chosen test allocation, acceptance thresholds, owners, cutover window, rollback triggers, rollback deadline, and evidence location. Approve the migration only when the record demonstrates both workload need and operational readiness.
Source
- Virtarix frozen Source of Truth, version 2.2, effective 16 July 2026 and frozen for this remediation on 11 August 2026: service model, Cloud VPS S specification, bandwidth qualification, recovery inclusion, and live VPS locations.
