How to Migrate a Database to a New Dedicated Server

A database migration can appear successful while leaving missing rows, stale writes, broken users, or an application connected to the wrong server. The safest process treats the move as a controlled change of database authority: prepare the destination, create a consistent copy, synchronize later changes, stop competing writes, validate the result, and preserve a tested path back.

This playbook applies to migrations between dedicated servers and from another hosting environment to a newly rented dedicated server. It is database-agnostic, so the exact commands and compatibility rules must come from the documentation for your database engine and versions.

Define the migration requirements

Start with the business limits rather than the transfer tool. Record:

• The maximum acceptable period without database writes.
• The maximum acceptable application downtime.
• The amount of recent data the business could tolerate losing.
• The database size and daily rate of change.
• The source and destination database engines and versions.
• Required extensions, character sets, collations, and plugins.
• Applications, workers, integrations, and reports that connect to the database.
• The rollback decision deadline.
• The people authorised to stop writes, switch traffic, and restore the old service.

Do not describe the requirement only as “minimal downtime.” Convert it into a measurable limit. A ten-minute write pause and a two-hour maintenance window lead to different migration designs.

Inventory the source database

Before sizing or configuring the new server, collect a current inventory of the source.

• Database engine, version, and operating system.
• Total data size and the largest databases, tables, or collections.
• Current CPU, memory, storage, and network utilisation.
• Peak connection count and connection-pool settings.
• Storage engine, extensions, plugins, and custom functions.
• Database users, roles, grants, and authentication rules.
• Scheduled jobs, triggers, events, and maintenance tasks.
• Replication, archiving, and backup configuration.
• Encryption keys and certificate dependencies.
• Monitoring checks and alert thresholds.

Identify every writer. The public application may not be the only system changing data. Background workers, scheduled imports, billing systems, administrative tools, and third-party integrations can continue writing after the main site enters maintenance mode.

Prepare the new dedicated server

The destination must be ready before the first production copy is created. Complete the relevant steps from your dedicated server deployment checklist, then configure the database environment.

Check that the new server has:

• Enough usable storage for the database, indexes, logs, temporary files, backups, and expected growth.
• Appropriate memory for the workload and database configuration.
• Network access between the source and destination where synchronization requires it.
• Restricted administrative and database access.
• Correct time synchronization.
• Monitoring for storage, memory, connections, replication, and database availability.
• An off-server backup destination.
• Remote-console or rescue access through the provider.

Install a database version that supports the selected migration method. Logical migration can often accommodate a wider range of version changes than physical copying, but extensions, data types, authentication defaults, and application drivers may still introduce incompatibilities.

Do not copy a live database’s raw files unless the database engine explicitly supports the chosen procedure and the required consistency conditions are satisfied. Database files can depend on engine state, logs, version, storage layout, and recovery metadata.

Choose the migration method

Select the simplest method that meets the downtime and recovery requirements.

Method	Best fit	Main trade-off
Offline backup and restore	Small databases with an acceptable maintenance window	Writes must remain stopped during the final copy and restore
Logical export and import	Selective migration, platform changes, or supported version changes	Large imports and index creation may take substantial time
Physical backup or replica	Large databases moving between compatible environments	Requires close engine and version compatibility
Continuous replication	Busy production databases with a short cutover window	Adds setup, lag monitoring, and promotion complexity

Offline backup and restore

Stop every writer, create a consistent backup, transfer it, restore it on the destination, validate the database, and start the application against the new server.

This method has the clearest authority boundary because the source stops changing before the final copy. Its disadvantage is that downtime includes backup, transfer, restore, validation, and application startup.

Logical export and import

A logical tool exports database objects and data in a form that the destination engine can recreate. PostgreSQL documents that pg_dump creates an internally consistent snapshot and can generally load its output into newer PostgreSQL versions. Engine-specific restrictions still apply.

Logical migration can expose compatibility problems early and allows selective transfer. It may be slow for large databases, and objects outside the selected export scope—such as users, permissions, external files, or instance-level settings—may require separate handling.

Physical copy or replication

A physical method transfers the database’s storage-level representation. It can be efficient for large datasets but normally requires stricter compatibility between source and destination.

Replication creates an initial copy and then sends later changes to the destination. PostgreSQL’s official documentation notes that streaming replication is asynchronous by default. MySQL likewise documents asynchronous replication as the default. With asynchronous transfer, the destination may remain behind the source, so replication lag must reach an acceptable level before cutover.

Replication is a transport mechanism, not automatic proof that the migrated application works. You still need compatibility tests, data validation, a write-free cutover point, and a rollback plan.

Measure the transfer before scheduling downtime

Do not estimate migration time from the network port speed alone. Effective transfer speed can be limited by source reads, destination writes, encryption, compression, latency, database processing, and competing production traffic.

Run a representative transfer test using non-sensitive or properly protected data. Measure:

• Export or backup duration.
• Transfer throughput.
• Import or restore duration.
• Index-building time.
• Replication catch-up rate under normal write load.
• Application validation time.

Use the measured result to build the maintenance window. Add time for troubleshooting and rollback. Do not schedule the cutover so tightly that the first unexpected delay consumes the entire rollback window.

Create and validate the initial copy

Build the destination early enough to test it before production traffic moves.

1. Create a consistent backup, export, snapshot, or base copy using a supported procedure.
2. Record the copy’s timestamp and database position where applicable.
3. Transfer it through an authenticated and encrypted channel.
4. Verify the transferred artifact’s integrity.
5. Restore or initialise the destination.
6. Apply required users, roles, permissions, extensions, and configuration.
7. Start replication or change capture if the migration design uses it.
8. Record every manual correction needed during the process.

Keep the source backup intact until the new database has passed validation and the rollback period has ended. A copied backup should not be your only recovery option.

Test the destination before cutover

Connect a controlled test instance of the application to the new database. Prevent it from serving public traffic, sending customer messages, running production payments, or executing scheduled jobs.

Validate more than row counts:

• Required databases, schemas, tables, and indexes exist.
• Users and applications can authenticate with the intended permissions.
• Character encoding, collation, and time-zone behaviour are correct.
• Stored procedures, triggers, events, and extensions work.
• Representative reads and writes return the expected result.
• Large and recent records are present.
• Application migrations report the expected schema state.
• Scheduled jobs are present but safely disabled until cutover.
• Monitoring and backups cover the new instance.

Use application-level reconciliation for important business objects. Compare carefully selected counts, totals, maximum timestamps, identifiers, and checksums where appropriate. Define the queries before cutover so the team does not invent validation while the service is offline.

Performance tests should use realistic queries and concurrency without modifying live customer data. A new server can have faster hardware and still perform poorly because of missing indexes, different database settings, cold caches, or slower storage behaviour.

Prepare the cutover runbook

The runbook should list actions in order, with an owner, expected duration, validation result, and rollback trigger for each step.

Include:

1. Announce the maintenance window.
2. Confirm current backups and recovery access.
3. Verify destination health and available capacity.
4. Stop or drain every source of database writes.
5. Confirm that no unexpected sessions or jobs are writing.
6. Complete the final synchronization.
7. Measure and record replication lag or final database position.
8. Prevent new writes to the old database.
9. Promote or activate the destination where required.
10. Update application connection settings.
11. Start the application and required workers.
12. Run technical and business validation.
13. Open production traffic.
14. Monitor the system during the observation period.

Prepare connection changes in advance, but protect them from accidental early deployment. Check applications, background workers, reporting tools, administrative interfaces, monitoring systems, and integrations separately.

Control the final synchronization

The central cutover rule is simple: do not allow independent writes to both databases unless the migration architecture was explicitly designed and tested for bidirectional operation.

For an offline move, stop writes before the final backup. For a replication-based move, stop writers, allow the destination to catch up, verify the final position, and then promote or activate it according to the engine’s supported procedure.

PostgreSQL documentation explains that a standby replays write-ahead log records and can be promoted to normal operation. It also distinguishes asynchronous replication, where some committed transactions may not yet have reached the standby, from synchronous configurations. Your validation must match the replication mode actually used.

Do not infer zero lag from a quiet application. Check the database’s own replication state and confirm that all known writers are stopped.

Validate immediately after cutover

Use a short, pre-approved validation sequence before declaring success.

• Confirm that applications connect only to the new database.
• Create and retrieve a controlled test record.
• Check critical reads, writes, and transactions.
• Confirm that background workers process expected jobs.
• Review database errors, rejected connections, and slow queries.
• Monitor CPU, memory, storage latency, connections, and free space.
• Verify that a new backup completes from the destination.
• Confirm that external integrations receive expected results.

Business validation matters as much as technical availability. A database can accept connections while orders, account updates, reports, or scheduled processing remain broken.

Keep rollback possible

Define rollback triggers before cutover. Examples include failed reconciliation, unacceptable error rates, missing functionality, unstable database performance, or an inability to complete validation before the decision deadline.

A basic rollback plan should specify:

• Who can order the rollback.
• How application traffic returns to the old database.
• Whether writes made on the new database must be preserved.
• How those new writes will be reconciled.
• Which services must be stopped before reversal.
• How customers and stakeholders will be informed.

The hardest rollback problem is data written after cutover. If the new database has accepted production transactions, simply reconnecting the application to the old database can discard those changes. Keep the initial observation period controlled, record the new database position, and define how post-cutover writes will be handled.

Do not reuse or rebuild the old server immediately. Keep it isolated from writes but available for investigation and rollback until the agreed retention period ends.

Monitor the new server after migration

Watch the destination closely during the first hours and days. Compare behaviour with the source baseline.

• Connection count and rejected connections.
• Query latency and slow-query volume.
• CPU and memory pressure.
• Storage latency, capacity, and growth.
• Locking, deadlocks, and long-running transactions.
• Application errors and failed background jobs.
• Backup completion and restore readiness.

Avoid making several unrelated tuning changes immediately after cutover. Establish a stable baseline, correct concrete problems, and document every adjustment.

Close the migration safely

End the project only after the new database has completed its observation period and produced a verified backup.

1. Confirm final application and data validation.
2. Complete a backup from the new server.
3. Test a representative restore.
4. Update diagrams, inventories, access records, and recovery instructions.
5. Remove obsolete replication paths and temporary credentials.
6. Revoke unnecessary network access between servers.
7. Record the final configuration and operating baseline.
8. Approve decommissioning of the old database.
9. Retain or destroy old data according to the applicable policy.

Review the full move against your dedicated server migration checklist. Record what delayed the work and update the runbook before the next migration.

A safe database migration does not depend on one perfect copy command. It depends on a consistent starting point, controlled writes, measurable synchronization, application-level validation, and a rollback path that remains usable until the new server has proved stable.