ERP on Windows VPS: Hosting, Sizing, and Migration

ERP hosting on a Windows VPS makes sense when your business runs Windows-based ERP software, needs remote users to access one shared environment, or wants to move an office server into the cloud without rebuilding the entire application. A VPS is a good fit for small and mid-sized ERP workloads, but success depends on sizing, database planning, RDS licensing, backups, security, and vendor support.

Quick verdict by use case

The short version:

Use a Windows VPS when your ERP is server-shaped.
Do not use a VPS just because the word “cloud” sounds better.

What ERP on a VPS means

ERP on a VPS means your enterprise resource planning software runs on a remote Windows Server instead of a local office machine.

Users connect to the server over Remote Desktop or through the ERP client application, depending on how the ERP is designed.

The ERP environment may include:

• Windows Server
• ERP application server
• SQL Server or another database
• shared files
• report engine
• print components
• scheduled tasks
• integration services
• backup jobs
• user profiles
• RDP or RDS access
• firewall rules
• monitoring
• snapshots and backups

For many small businesses, the goal is simple:

Put the ERP system in one stable cloud environment so authorized users can access the same data from different locations.

This is especially useful when the business has multiple offices, remote employees, accountants, consultants, warehouse staff, or field teams.

When ERP hosting on a Windows VPS makes sense

A Windows VPS is a strong fit when the ERP workload behaves like traditional business software.

That usually means:

• the ERP runs on Windows
• the database is self-managed
• users need access from multiple locations
• the app is not fully SaaS
• the business wants centralized control
• the software vendor supports Windows Server
• the company needs predictable monthly infrastructure
• the current office server is becoming a liability
• the business wants easier remote access than VPN-only office infrastructure

Good examples include:

• legacy Windows ERP systems
• accounting and inventory systems
• manufacturing management tools
• wholesale or distribution software
• custom business applications
• Microsoft Dynamics GP / NAV style deployments
• Sage 100 / 300 style deployments
• SAP Business One single-server style deployments
• ERP systems backed by SQL Server
• ERP tools with Windows client/server architecture

A Windows VPS gives the business a single place to run the app, database, and user access layer.

That can be cleaner than installing the ERP client and database components across several office PCs.

When ERP on a VPS is not the right answer

A VPS is not automatically the right answer for every ERP system.

Do not move ERP to a VPS if:

• your ERP is already SaaS and works well
• the vendor does not support self-hosted deployment
• the vendor requires a specific hosting partner
• licensing forbids third-party hosting
• the ERP needs hardware dongles that cannot be virtualized
• the app depends on local peripherals without a remote-friendly setup
• users need very low-latency access to local devices
• the database is too large for a single-server deployment
• the business has strict compliance needs that require a larger architecture
• nobody will maintain updates, backups, security, and monitoring

A VPS gives control.

Control creates responsibility.

If the ERP is business-critical, the migration plan must be serious.

The main ERP hosting models

There are three common ways to run ERP software in a hosted Windows environment.

Model 1 — Single Windows VPS

This is the simplest model.

Users
  ↓
RDP / ERP client access
  ↓
Windows VPS
  ├── ERP application
  ├── SQL Server or database
  ├── shared files
  └── backups

Best for:

• small teams
• early cloud migration
• simple ERP setups
• lower user counts
• single-location replacement
• cost-sensitive businesses
• simple support needs

This model is easy to understand and fast to deploy.

The trade-off is that the app, database, and user sessions share the same server resources.

That is fine for many small businesses, but it should be monitored.

Model 2 — App server and database server

As usage grows, separate the ERP app layer from the database.

Users
  ↓
ERP app / RDP server
  ↓
Private network
  ↓
Database server

Best for:

• heavier ERP workloads
• larger databases
• more users
• stronger backup separation
• better performance troubleshooting
• clearer scaling path

This model makes sense when SQL Server or the database becomes the bottleneck.

It also reduces risk when one part of the system needs maintenance.

Model 3 — Multi-server ERP environment

Larger ERP systems may need separate components.

Users
  ↓
RDS / app server
  ↓
ERP application server
  ↓
Database server
  ↓
File storage / backups / integrations

Best for:

• larger teams
• multiple departments
• heavy reporting
• warehouse or inventory workflows
• ERP integrations
• strict uptime requirements
• dedicated support processes

This model is more expensive and more complex, but it is safer for serious ERP workloads.

Do not start here unless the workload requires it.

Recommended Windows Server version

For ERP workloads in 2026, Windows Server 2022 is usually the safest default.

Use this decision rule:

The ERP vendor’s support matrix should decide the final answer.

Do not choose the newest Windows Server version until the ERP application, database version, backup tool, RMM agent, antivirus, reporting components, and integrations are confirmed.

For many small business ERP systems, compatibility is more important than novelty.

Remote access: RDP, RDS, and user licensing

Most ERP-on-VPS projects need remote access planning.

There are two different cases.

Administrative RDP

Windows Server includes remote access for administration.

This is for server management, not for giving an entire team daily ERP access.

Use administrative RDP for:

• setup
• patching
• maintenance
• troubleshooting
• installing ERP components
• managing services
• reviewing logs

Do not build your multi-user ERP workflow around admin sessions.

RDS Session Host for real multi-user access

If multiple users need to sign in and use ERP software on the same Windows Server, you likely need Remote Desktop Services.

A proper RDS setup may include:

• RD Session Host
• Remote Desktop Licensing
• RDS CALs
• user profiles
• security policies
• session timeouts
• printer redirection rules
• clipboard policy
• mapped drives
• application permissions

This matters because ERP users are not server admins.

They should connect with normal user accounts and only access the ERP tools they need.

Per-user vs per-device RDS CALs

For ERP access, RDS CAL planning matters.

A simple rule:

Licensing should be planned before production.

Do not wait until users cannot connect or the licensing grace period becomes a problem.

ERP server sizing

ERP sizing depends heavily on the software, database, user count, and reporting workload.

There is no universal plan that fits every ERP system.

Start with these variables:

• number of concurrent users
• ERP software requirements
• Windows Server version
• database engine
• database size
• report generation frequency
• file attachment volume
• integrations
• scheduled jobs
• RDP user sessions
• antivirus/EDR overhead
• backup window
• expected growth

A small ERP environment may run well on one VPS.

A larger ERP environment may need separate app and database servers.

Practical sizing starting points

Use this as a starting point, not a guarantee.

Do not size only by employee count.

Size by concurrent usage and workload behavior.

A company with 20 employees but 4 active ERP users may need less than a company with 8 users running heavy reporting all day.

Database planning for ERP

Many ERP systems depend on a database.

Common database engines include:

• SQL Server
• PostgreSQL
• MySQL / MariaDB
• vendor-specific embedded databases
• file-based legacy databases

For Windows ERP workloads, SQL Server is common.

Database planning affects performance more than almost anything else.

Check:

• database size
• memory requirements
• SQL Server edition
• backup method
• maintenance plans
• transaction log growth
• index maintenance
• TempDB behavior
• report workload
• database recovery model
• restore process
• antivirus exclusions
• storage growth

If the ERP database is important, do not treat it as just another file.

It needs a backup and maintenance plan.

Storage planning

ERP systems can generate significant storage growth.

Storage may include:

• database files
• transaction logs
• documents
• invoices
• PDFs
• exports
• attachments
• reports
• backups
• audit logs
• integration files

Use NVMe storage where possible for better database and application responsiveness.

Plan for:

• current database size
• 12-month growth
• backup storage
• log file growth
• temporary files
• restore testing space
• operating system overhead

A common mistake is sizing storage only for the current database.

That leaves no room for backups, logs, updates, exports, and growth.

Backup strategy for ERP on VPS

ERP backups are not optional.

A useful ERP backup strategy usually includes multiple layers.

VM-level protection

Use snapshots before risky changes:

• ERP version upgrades
• Windows updates
• SQL Server upgrades
• database migrations
• major configuration changes
• firewall changes
• RDS changes

Snapshots are useful for rollback.

They are not a full backup strategy.

Application and database backups

Use ERP-aware or database-aware backups when possible.

For SQL Server workloads, plan:

• full backups
• differential backups if needed
• transaction log backups if using full recovery model
• restore testing
• backup retention
• off-server storage where appropriate

The key question is:

Can we restore the ERP to a known-good point if the database is corrupted, deleted, or encrypted?

If the answer is unclear, the backup plan is not ready.

Restore testing

Backups are only useful if they restore.

Test:

• full ERP restore
• database restore
• file restore
• user login after restore
• report generation after restore
• integrations after restore
• RDP access after restore

The first restore test should not happen during an emergency.

Security basics for ERP hosting

ERP systems contain sensitive business data.

Treat the server like a production system.

Start with:

• strong administrator passwords
• named user accounts
• least-privilege permissions
• firewall rules
• restricted RDP access where possible
• RDS user separation
• Windows updates
• antivirus or EDR planning
• backup access control
• audit logs
• account lockout policy
• MFA where supported
• VPN or RD Gateway where appropriate
• no shared admin accounts
• no public database ports

Only expose the services that must be public.

ERP databases should not be open to the public internet.

Network planning

A simple ERP VPS may only need RDP access and outbound internet.

A more advanced ERP setup may need:

• private networking
• site-to-site VPN
• office IP allowlists
• RD Gateway
• domain controller
• file server access
• integration endpoints
• payment or shipping APIs
• backup storage
• monitoring agent access

Document the required ports before migration.

Avoid opening broad firewall rules because “the app did not work.”

A working ERP setup should also be a controlled ERP setup.

Printing and local device access

ERP software often depends on printing.

Common examples:

• invoices
• packing slips
• labels
• purchase orders
• warehouse documents
• checks
• reports

Printing can become one of the hardest parts of ERP hosting.

Before migration, test:

• redirected printers
• network printers
• label printers
• PDF printers
• default printer behavior
• paper sizes
• check printing
• barcode labels
• driver compatibility
• print speed over RDP

Do not assume printing will work because the ERP login works.

For businesses that print heavily, printer testing should be part of the migration checklist.

ERP migration checklist

A good ERP migration is planned, not improvised.

Before migration

Collect:

• ERP software version
• database engine and version
• license information
• vendor support notes
• number of users
• concurrent users
• database size
• attachment storage size
• current server specs
• current Windows Server version
• backup method
• integrations
• scheduled tasks
• printers
• reports
• mapped drives
• DNS records
• firewall rules
• user permissions

Create a rollback plan before touching production.

Build the VPS

Prepare:

• Windows Server version
• administrator access
• Windows updates
• firewall rules
• RDP access
• RDS roles if needed
• antivirus/EDR
• backup configuration
• monitoring
• database engine
• ERP prerequisites
• ERP installer
• license activation plan

Keep the old server available until the new environment is verified.

Migrate data

Move:

• database backup
• ERP application files
• shared folders
• report templates
• custom forms
• attachments
• integration folders
• scheduled tasks
• license files if applicable
• configuration files
• user permissions

Do not rely on file copy alone for database-backed ERP.

Use the vendor-supported migration or database backup/restore method where possible.

Test business workflows

Before cutover, test:

• user login
• ERP launch
• database connection
• invoice creation
• invoice print
• report generation
• inventory lookup
• order entry
• document upload
• PDF export
• scheduled jobs
• integrations
• backups
• restore process
• RDP performance
• user permissions

A server that boots is not the same as an ERP system that works.

Cut over

During cutover:

• stop writes on the old system
• take final backup
• restore to the VPS
• verify data
• update shortcuts or DNS
• test user access
• confirm printers
• monitor logs
• keep the old system read-only temporarily
• document the final state

Schedule cutover outside business hours when possible.

Common mistakes

Mistake 1: Treating ERP like a normal website

ERP is not just a web app or a file share.

It often includes databases, reports, integrations, users, printers, and scheduled jobs.

Plan the whole system.

Mistake 2: Ignoring vendor support

Do not assume an ERP works on every Windows Server version.

Check vendor support before choosing Server 2025 or moving from an older system.

Mistake 3: Under-sizing RAM

ERP users, RDP sessions, SQL Server, antivirus, reporting, and Windows itself all need memory.

If the server is slow, RAM pressure is often one of the first things to check.

Mistake 4: Forgetting RDS licensing

Multiple users connecting to use business apps is not the same as two admin RDP sessions.

Plan RDS Session Host and RDS CALs before users depend on the environment.

Mistake 5: Skipping printer tests

Printing is often business-critical.

Test invoices, labels, PDFs, check printing, and default printer behavior before cutover.

Mistake 6: No restore test

ERP backups must be restorable.

Do not wait for an incident to discover that backups are incomplete.

Mistake 7: Opening too many ports

Do not expose SQL Server, ERP admin panels, or internal services to the public internet unless there is a very specific and protected reason.

Mistake 8: Migrating without a rollback plan

If the new environment fails, the business needs a safe fallback.

Keep the old environment available until the new ERP system is proven.

How Raff fits ERP hosting

Raff Windows VPS is useful for ERP workloads that need a Windows Server environment with full administrator access, RDP access, and predictable cloud infrastructure.

Raff can support ERP-style deployments such as:

• Windows-based ERP apps
• Sage-style business systems
• Microsoft Dynamics GP / NAV style environments
• SAP Business One single-server style deployments
• custom .NET business apps
• SQL Server-backed ERP systems
• RDP/RDS-based remote access
• business software migrations from office servers

A practical Raff ERP setup can start simple:

Windows VPS
  ├── ERP application
  ├── SQL Server or database
  ├── RDP/RDS access
  ├── backups and snapshots
  └── monitoring

As the workload grows, it can move toward:

RDS / app server
  ↓
Private network
  ↓
Database server
  ↓
Backups and monitoring

The goal is not to make ERP infrastructure complicated.

The goal is to give the business a stable, centralized, remote-accessible environment for the software it already depends on.

Recommended setup by company size

Use this table as a planning guide, not a fixed rule.

ERP systems vary too much for one universal sizing formula.

What we recommend

For most small and mid-sized ERP hosting projects:

1. Use Windows Server 2022 as the conservative default unless the vendor supports 2025.
2. Start with a single Windows VPS for small ERP workloads.
3. Use RDS Session Host and RDS CALs for real multi-user access.
4. Size for concurrent users, database load, reports, and growth.
5. Keep the database private.
6. Use snapshots before changes and scheduled backups for recovery.
7. Test printing and business workflows before cutover.
8. Move to separate app and database servers when the workload proves it needs it.

The best ERP hosting setup is not the biggest server.

It is the setup that keeps the business workflow stable.

What's next

• Connect to a Windows VPS via RDP.
• Compare Windows Server 2019, 2022, and 2025 before choosing the operating system.
• Review multi-user RDP vs RDS Session Host before giving users access.
• Read the RDS CAL licensing guide before production rollout.
• Review the Windows VPS for Sage hosting guide if your ERP stack is Sage-based.
• Review cloud backup strategy before migrating production data.

Sources

• Microsoft Learn — Remote Desktop Services roles
• Microsoft Learn — License Remote Desktop Services with Client Access Licenses
• Microsoft Learn — Windows Server 2019 lifecycle
• Microsoft Learn — Windows Server 2022 lifecycle
• Microsoft Learn — Windows Server 2025 lifecycle
• Raff — Windows VPS product page