Shared hosting is useful when a project needs the lowest possible operational burden. It becomes restrictive when a SaaS application needs custom runtimes, background workers, predictable resource access, stronger deployment control, or a safer path to scale.
A growing SaaS team should move from shared hosting when hosting limits begin affecting product reliability, deployment speed, or the ability to operate the application correctly. The goal is not simply to rent a larger server. It is to move with a tested cutover, a rollback path, and a VM size matched to the real workload.
Shared hosting to cloud VM: quick answer
Stay on shared hosting when the application is simple, traffic is modest, and the platform still supports every required runtime, dependency, database feature, and operational task.
Move to a cloud VM when you need:
- root or administrator control
- custom packages and runtimes
- reliable background workers or scheduled jobs
- stronger database control
- private networking
- independent storage or backup planning
- repeatable deployments
- clearer scaling options
| Decision factor | Shared hosting | Cloud VM |
|---|---|---|
| Server control | Limited | Full operating-system control |
| Runtime choice | Provider-defined | Team-defined |
| Background jobs | Often restricted | Configurable |
| Resource model | Shared platform limits | Depends on selected VM category |
| Deployment workflow | Usually basic | Can be automated |
| Scaling path | Plan upgrade or migration | Resize, split roles, or add nodes |
| Operations responsibility | Mostly provider | Mostly your team |
A VM gives you more control, but it also gives you more responsibility. Your team becomes responsible for patching, firewall rules, service configuration, monitoring, and recovery planning.
Signs that shared hosting is becoming a constraint
You cannot install what the application needs
A SaaS product may require a specific Node.js, Python, PHP, Java, or database version. It may also require system packages, queue workers, headless browsers, media-processing tools, or custom proxy configuration.
When the hosting environment prevents those requirements, application design begins adapting to the host instead of the product.
Background work is unreliable
SaaS applications often depend on:
- email queues
- data imports
- scheduled billing tasks
- report generation
- webhook processing
- image or document conversion
- recurring maintenance jobs
Shared hosting may limit long-running processes, cron frequency, memory use, or worker supervision. A VM lets you operate workers through tools such as systemd, Supervisor, Docker, or a process manager appropriate to the runtime.
Resource contention affects users
Shared hosting places many accounts on the same underlying system. Providers use limits to prevent one account from consuming everything, but those limits can create throttling or unpredictable behavior for a growing application.
A cloud VM offers a defined allocation of memory, storage, and virtual CPU according to the selected plan. CPU behavior may differ by VM category, so distinguish between shared-vCPU and dedicated-vCPU products instead of assuming every VM provides identical isolation.
Deployment has become risky
Uploading files directly into production or editing the live application through a control panel may work initially. It becomes dangerous when:
- releases require database migrations
- multiple developers deploy changes
- background workers must restart
- environment variables differ between environments
- rollback needs to be fast
A VM makes better deployment workflows possible, but the team must still design them.
You need clearer network boundaries
A growing SaaS may need:
- a public web endpoint
- private database access
- restricted administrative access
- internal worker communication
- a load balancer
- private service-to-service traffic
These patterns are difficult to build cleanly inside conventional shared hosting.
Choose the target architecture before migrating
Do not start by copying files. First decide what the application should look like after the move.
Option 1: one VM
A single VM can run:
- reverse proxy
- application runtime
- database
- background workers
This is often the simplest starting architecture for an early SaaS product.
Use it when:
- traffic is still moderate
- one team operates the stack
- downtime risk is manageable
- operational simplicity matters most
Read Single-Server vs Multi-Server Architecture before separating every component prematurely.
Option 2: application and database on separate systems
Separating the database can reduce resource competition and make application deployments less likely to disturb persistent data.
Use it when:
- database load is significant
- customer data is business-critical
- backup and recovery requirements are stronger
- application and database scaling differ
Option 3: multiple app nodes
Multiple application VMs behind a load balancer can improve capacity and availability, but only when the application is ready for horizontal scaling.
Sessions, uploads, queues, and other shared state should not depend on one app server. Review Stateful vs Stateless Applications before adding nodes.
Select a VM from workload evidence
Avoid choosing a plan only from user count or a competitor's recommendation.
Measure or estimate:
- current memory usage
- peak CPU usage
- database size
- storage growth
- concurrent requests
- worker demand
- backup space
- deployment headroom
Use Choosing the Right VM Size and the live Raff pricing page for current plan options.
General Purpose and CPU-Optimized VMs may fit different workloads. Use the current product descriptions to confirm the CPU model and performance characteristics rather than describing all Linux VMs as fully dedicated.
Migration plan
A safe migration separates preparation, data movement, validation, cutover, and rollback.
Step 1 — Inventory the existing application
Document:
- runtime and version
- web server configuration
- database engine and version
- PHP or language extensions
- environment variables
- cron jobs
- queue workers
- uploaded files
- email configuration
- DNS records
- SSL certificates
- redirects
- external API allowlists
- storage and backup locations
Also identify provider-specific features such as control-panel mailboxes, managed DNS, or one-click backups that will not move automatically.
Step 2 — Create the Raff environment
Deploy a suitable Linux VM and configure:
- a supported operating system
- SSH-key access
- a non-root administrative user where appropriate
- firewall rules
- automatic security updates according to your policy
- time zone and NTP
- application directories
- monitoring and log rotation
Do not expose database, cache, or internal worker ports publicly unless the architecture specifically requires it.
Step 3 — Rebuild the application stack
Install the required:
- reverse proxy or web server
- application runtime
- package manager
- database client or server
- process supervisor
- queue and cache services
- TLS tooling
Match compatible versions rather than copying an old shared-host configuration blindly. A migration is a good time to remove obsolete modules and undocumented settings.
Step 4 — Copy application files
Use a repeatable transfer method such as rsync, SFTP, Git-based deployment, or a release artifact.
Example:
rsync -avz --delete ./app/ deploy@new-server:/var/www/app/
Be careful with --delete; use it only after confirming the source and destination paths.
Exclude:
- secrets that should be recreated securely
- local cache directories
- temporary files
- development dependencies not needed in production
- old logs
Step 5 — Migrate the database
For a small MySQL database, an export and import may be sufficient:
mysqldump --single-transaction --routines --triggers app_db > app_db.sql mysql app_db < app_db.sql
For PostgreSQL, use the appropriate pg_dump and pg_restore workflow.
The exact method depends on database size, write rate, engine version, and acceptable downtime.
For an application that continues receiving writes, use a staged approach:
- copy an initial database version
- test the application against the copy
- schedule a short write freeze or use a replication/synchronization method
- perform the final data sync
- switch traffic
Do not assume one early export contains the final production state.
Step 6 — Move uploads and persistent files
User uploads, generated files, and documents may be stored separately from the application code.
Decide whether they should live on:
- the VM disk
- an attached Block Storage Volume
- Object Storage
Object storage is often a better long-term target when multiple application nodes need the same files or when file growth should be independent from VM size.
Step 7 — Recreate scheduled jobs and workers
Shared-hosting cron entries do not automatically become VM services.
Recreate and test:
- cron jobs
- queue workers
- scheduled billing
- email delivery jobs
- data imports
- cleanup tasks
- report generation
Ensure each task runs once where required. A duplicated cron job can create repeated invoices, emails, or data processing.
Step 8 — Test before DNS cutover
Test the new environment using:
- a temporary hostname
- a local hosts-file override
- a staging subdomain
Validate:
- login and authentication
- password reset and outbound email
- payment callbacks
- API integrations
- file uploads and downloads
- background jobs
- scheduled tasks
- redirects
- SSL
- database migrations
- error pages
- backup creation
Do not treat the home page loading as complete validation.
Step 9 — Prepare DNS
Before the migration window, reduce DNS TTL where appropriate. Do this early enough for the previous TTL to expire.
Record the existing values before changing anything.
At cutover:
- stop or restrict writes on the old environment if needed
- complete the final database and file sync
- verify the new application
- update the DNS record
- monitor both environments during propagation
DNS propagation is not a fixed duration. Resolver caching depends on the previous TTL and client behavior.
Step 10 — Keep a rollback path
Do not delete the old hosting account immediately.
A rollback plan should define:
- when traffic should return to the old host
- whether the old database is still safe to use
- how writes made on the new system would be handled
- who makes the decision
- how DNS is reversed
Rollback becomes harder after both environments accept different writes. This is why a controlled cutover and a short validation window matter.
Minimal downtime vs zero downtime
A well-planned DNS migration can keep downtime short, but that is not automatically a zero-downtime migration.
True zero-downtime migration may require:
- continuous database replication
- dual-compatible application versions
- shared file storage
- a traffic-routing layer
- health-aware cutover
- tested rollback
For many small SaaS products, a short planned write freeze is safer than pretending a complex zero-downtime process exists.
Security work after the move
A VM is not secure merely because it is separate from shared hosting.
Complete at least the following:
- use SSH keys
- restrict administrative ports
- enable a host or platform firewall
- remove unused services
- patch the operating system
- configure backups
- test restore procedures
- rotate credentials copied during migration
- review application secrets
- configure monitoring and alerts
Use Private Cloud Networks when application, database, and internal services should communicate without unnecessary public exposure.
Cost planning
Compare architectures, not only monthly plan labels.
Include:
- VM compute
- storage growth
- backups
- snapshots
- object storage
- monitoring
- email delivery
- operational time
Use the live pricing page for current Raff prices. Do not base a migration plan on historical plan amounts embedded in an article.
A smaller VM that constantly requires emergency work may cost more operationally than a correctly sized system. A larger VM with no monitoring may also hide inefficient code or database problems.
Common migration mistakes
Migrating without a complete inventory
Missing cron jobs, mail settings, extensions, or uploads are common causes of post-cutover failure.
Changing too many things at once
A migration, framework upgrade, database-engine change, and architecture redesign in one window create unnecessary risk.
Copying the database only once
Applications that remain live continue receiving writes.
Switching DNS before validating background work
Web pages may work while queues, billing, and emails fail silently.
Exposing every service publicly
The application edge may need public access. The database and internal services normally do not.
Canceling the old host immediately
Keep the old environment available until the new system has passed the agreed validation period.
Conclusion
Moving from shared hosting to Raff is a change in operating model, not only a change in server size.
The migration becomes worthwhile when shared-hosting restrictions affect product reliability, deployment control, or growth. A cloud VM provides more flexibility, but the team must manage security, patching, monitoring, backups, and recovery deliberately.
Choose a simple target architecture, size it from evidence, rehearse the migration, perform a controlled final sync, switch DNS with a rollback plan, and keep the old environment until the new one is proven.