A VPS migration checklist is a planning framework for moving a workload from one virtual-server provider to another without losing data, access, or a safe rollback path. It focuses on a provider-to-provider rehost: the application stays broadly the same while the compute, IP address, storage, network controls, and provider account change.
The safest move separates preparation from cutover. Build the target first, copy stable data in advance, identify everything tied to the old server, define one authoritative system for writes, and keep the source recoverable until the target has passed business and operational validation.
Raff has supported more than 15,000 VM deployments. From that product work, the recurring migration gap is rarely the initial file copy. It is an overlooked dependency—an allowlisted IP, scheduled job, certificate path, database writer, webhook, or DNS record—combined with no named rollback decision owner. This guide narrows that risk for teams switching VPS providers. The broader Cloud Migration Checklist remains the canonical guide for rehosting, replatforming, refactoring, and larger cloud-program decisions.
VPS migration planning starts with a rehost boundary
A provider-to-provider VPS migration should begin with a clear boundary: what will remain functionally unchanged, and what must be rebuilt because it belongs to the old platform?
The rehost boundary usually includes:
- the same application or service;
- the same database engine and major version where practical;
- the same public hostnames;
- equivalent operating-system packages and runtime versions;
- equivalent storage capacity with migration headroom;
- equivalent inbound and outbound network access;
- a new server identity, public IP address, and provider control plane.
Provider-specific resources should be treated separately. These may include firewall rules, private-network identifiers, snapshots, attached volumes, backup schedules, reverse DNS, monitoring agents, API credentials, rescue consoles, and image formats.
A clean scope prevents migration from turning into an unplanned modernization project. Changing provider, operating-system version, database engine, deployment method, network design, and application architecture in one window creates too many variables for a reliable rollback.
Choose a rehost-first approach when the workload is stable and the business reason is price, support, location, performance consistency, platform simplicity, or provider risk. Choose the broader cloud-migration process when the move also changes major application or data architecture.
The migration decision framework balances downtime, data change, and rollback
Three factors determine the safest migration pattern:
- How quickly data changes.
- How much downtime users can tolerate.
- Whether writes can be reversed after cutover.
| Workload pattern | Suitable migration pattern | Main trade-off |
|---|---|---|
| Static site or infrequently changed files | One validated copy followed by DNS cutover | Simple, but final edits must be controlled |
| Application with uploads but limited writes | Initial copy, maintenance window, final delta sync | Short downtime with manageable coordination |
| Database-backed application | Pre-stage files, use database-aware backup or replication, freeze or redirect writes at cutover | Data consistency becomes the central risk |
| Busy transactional service | Continuous synchronization or replication with explicit authority and rollback controls | Lower downtime, higher operational complexity |
| Internal tool with flexible maintenance | Offline backup, restore, validation, and scheduled cutover | Longer downtime, simpler recovery logic |
Choose an offline migration when downtime is cheaper than synchronization complexity. Choose staged synchronization when the dataset is large but the final change set is small. Choose replication only when the team can monitor lag, verify consistency, control write authority, and explain what happens during rollback.
A useful decision record should state:
- approved maintenance window;
- maximum acceptable data-loss window;
- maximum time allowed before rollback;
- whether the source remains writable before cutover;
- whether the target may accept writes during validation;
- how target-side writes would be reconciled if rollback occurs;
- who decides to continue, fix forward, or roll back.
Lower downtime is not automatically safer. A controlled 20-minute maintenance window may carry less risk than a complex near-zero-downtime design that nobody has rehearsed.
The source inventory protects hidden dependencies
A VPS is more than its application directory. The inventory should capture every dependency that could still point to the source after traffic moves.
| Inventory area | Record before migration |
|---|---|
| Compute | OS version, architecture, vCPU, RAM, swap, kernel requirements |
| Storage | Mounted filesystems, capacity, growth, permissions, ownership, ACLs, extended attributes |
| Application | Runtime, packages, services, environment variables, startup order, process manager |
| Database | Engine and version, users, extensions, size, backup method, connection strings |
| Network | Public IP, IPv6, ports, firewall rules, private IPs, outbound destinations, allowlists |
| DNS | A, AAAA, CNAME, MX, TXT, SRV, reverse DNS, TTLs, delegated zones |
| Security | SSH keys, users, sudo access, certificates, secrets, API credentials |
| Automation | Cron, systemd timers, queues, workers, CI/CD, webhooks, scheduled reports |
| Operations | Logs, monitoring, alerts, backups, snapshots, dashboards, escalation contacts |
| External systems | Payment, email, identity, storage, analytics, partner APIs, license activation |
IP-based allowlists deserve special attention. A successful DNS change does not update a database firewall, SaaS integration, partner endpoint, SMTP relay, monitoring probe, or administrative access list that still trusts the old IP.
The source inventory should also identify data that must not be copied blindly. Temporary files, caches, stale logs, machine-specific credentials, runtime sockets, and provider agents may belong to the old environment. Copying the entire filesystem without classification can reproduce old errors or expose secrets unnecessarily.
From Raff's product perspective, the most effective inventory is not the longest spreadsheet. It is the one that names an owner and a validation method for every item capable of breaking customer traffic or recovery.
Target readiness and staged synchronization reduce cutover risk
The target VPS should be production-ready before the final migration window.
Readiness includes:
- compatible operating system and architecture;
- adequate CPU, RAM, storage, and network capacity;
- administrative access tested independently of DNS;
- firewall and private-network rules applied;
- runtime, web server, process manager, and database dependencies installed;
- certificates and secrets available through a controlled process;
- monitoring and backup configuration active;
- application health checks defined;
- a temporary hostname or local hosts-file method for pre-cutover testing.
A staged file migration normally uses an initial bulk copy followed by one or more delta synchronizations. Rsync can preserve common file metadata in archive mode, while ACLs, extended attributes, hard links, sparse files, and filesystem boundaries require explicit consideration. Its documentation also distinguishes quick size-and-time checks from checksum-based comparison, which consumes additional disk I/O. The migration plan should therefore record the exact transfer settings rather than assuming “rsync completed” proves complete equivalence.
Database state should use database-aware methods. Copying live database files as ordinary files can produce an unusable or inconsistent target. PostgreSQL and MySQL both document backup, restore, and replication methods that should be selected according to engine version, dataset size, and downtime requirements.
A practical synchronization model is:
Build and test target ↓ Initial file and data copy ↓ Measure copy duration and change rate ↓ Run one or more delta synchronizations ↓ Enter maintenance or write-control window ↓ Final synchronization and validation
The pre-cutover rehearsal should measure real elapsed time. Estimates based only on dataset size can be wrong because small files, encryption, compression, source disk speed, network route, database restore behavior, and permission checks affect completion time.
DNS cutover works only with traffic and cache planning
DNS changes traffic direction, but DNS alone does not make a migration instantaneous or reversible.
RFC 1035 defines TTL as the period a resource record may remain cached before the source is consulted again. Lowering TTL in advance can reduce the expected cache window, but existing cached records retain the TTL value they received earlier. Some clients, applications, proxies, and local resolvers may also behave differently from a clean command-line lookup.
Before cutover, confirm:
- the authoritative DNS provider and account owner;
- every hostname that resolves to the source;
- current TTL values and when they will be lowered;
- target A and AAAA records;
- certificate coverage for all hostnames;
- proxy, CDN, or load-balancer behavior;
- reverse DNS requirements for email or reputation-sensitive services;
- whether clients cache IP addresses or DNS answers internally.
The safest validation path tests the target before public DNS changes. Options include a temporary hostname, direct IP access where the application supports it, a local hosts-file override, or a controlled proxy route. The target should be tested with the real hostname and TLS behavior whenever possible because redirects, cookies, allowed-host settings, CORS, and certificate chains can fail even when the service responds by IP.
During propagation, both source and target may receive traffic. That is safe for a read-only site but dangerous for an application where both systems can accept independent writes. The migration design must decide whether the source remains read-only, redirects to the target, stays synchronized, or is removed from service before DNS changes.
DNS rollback has the same cache limitations as forward cutover. Repointing a record does not guarantee every user returns immediately. Rollback planning must account for a period of mixed routing.
Validation and rollback preserve one authoritative system
Migration validation should prove the target is usable, correct, observable, and recoverable.
Business validation
Check the workflows users depend on:
- authentication and authorization;
- create, read, update, and delete operations;
- file upload and download;
- email, webhook, and notification delivery;
- payment or order processing;
- search, reports, and exports;
- background jobs and scheduled tasks.
Data validation
Check:
- database row or document counts for critical datasets;
- newest expected records;
- file counts, sizes, ownership, and selected checksums;
- permissions and application write paths;
- database users, extensions, indexes, and scheduled events;
- absence of new writes on the wrong system.
Operational validation
Check:
- CPU, memory, storage, and network behavior;
- application and database logs;
- monitoring and alerts;
- backup completion;
- certificate validity;
- firewall exposure;
- external allowlists and integrations;
- expected recurring jobs after one normal cycle.
Rollback criteria should be measurable. Examples include failed writes, missing critical data, broken authentication, unavailable integrations, unacceptable error rate, severe latency regression, or exceeding the approved migration window.
The runbook should identify one authoritative writer at every phase:
| Phase | Authoritative system |
|---|---|
| Preparation and initial sync | Source VPS |
| Maintenance and final sync | Source is frozen or writes are explicitly controlled |
| Target validation before approval | Target may be read-only or accept tightly controlled test writes |
| Production approval | Target VPS |
| Rollback window | Defined by the written data-reconciliation strategy |
The source should not be deleted immediately after cutover. Keep it isolated and controlled for a defined warranty period. Make it read-only or otherwise prevent accidental divergence. Retire it only after normal business cycles, backups, monitoring, integrations, and restore paths have been verified on the target.
Raff supports a controlled provider-to-provider migration path
Raff can serve as the target for Linux or Windows workloads moving from another VPS provider. The migration design should still follow the workload rather than assuming a one-to-one copy of the old plan.
Current Raff VM plans use NVMe storage and a 3 Gbps unmetered VM bandwidth model. Those characteristics can support initial and delta transfers, but transfer duration still depends on the source provider, route, encryption, file shape, source-disk performance, and the remote endpoint. Measure the real path before setting the cutover window.
A typical Raff target may combine:
Source VPS ↓ initial and delta synchronization Raff VM ├─ Private Cloud Network for internal service traffic ├─ Data Protection for infrastructure recovery layers └─ Object Storage for archives or migration staging where appropriate
Use database-native backup or replication for active databases rather than treating a VM snapshot as the only consistency mechanism. Use snapshots or automated backups as additional recovery layers according to the workload. Document firewall rules, private-network paths, public IP changes, DNS records, and external allowlists before production traffic moves.
Raff is a focused us-east platform. That can be a strong fit for U.S.-focused workloads and teams that value a direct VM operating model. Teams requiring several global regions or provider-managed guest operating systems should include those needs in the provider decision before migration.
The How to Choose a VPS Provider framework helps compare support, performance evidence, backups, pricing, location, and portability before selecting the target. Migration should begin only after the provider and workload requirements are aligned.
The final VPS migration checklist keeps ownership visible
Before the migration window
- Scope is limited to a provider-to-provider rehost.
- Application, data, DNS, access, automation, and external dependencies are inventoried.
- Target capacity includes transfer and recovery headroom.
- Target access, firewall, runtime, monitoring, and backups are configured.
- Initial data copy has completed and transfer duration is recorded.
- Database migration method has been tested.
- DNS ownership, records, TTLs, and certificate behavior are confirmed.
- External IP allowlists are ready for the target.
- Acceptance tests and rollback triggers are written.
- Cutover and rollback decision owners are named.
During cutover
- Source changes are frozen or controlled.
- Final file and database synchronization completes.
- Target services start in the documented order.
- Data and critical workflows pass validation.
- DNS or traffic routing changes are applied.
- Source and target logs are watched for mixed traffic or writes.
- The team explicitly approves production on the target.
After cutover
- Monitoring, alerts, backups, and scheduled jobs run successfully.
- External integrations and allowlists use the target.
- The source is isolated or read-only during the warranty period.
- Documentation, diagrams, credentials, and recovery procedures are updated.
- A restore from the new protection path is tested.
- Old resources are retired only after business approval.