A database migration service helps a team move production data from one database environment to another while coordinating compatibility, data transfer, synchronization, cutover, validation, and rollback.
For buyers, the important question is not whether a provider has a migration tool. It is what the service actually owns when production data, application traffic, and rollback decisions are involved.
A migration product can copy data. A database migration service should define who assesses compatibility, who configures the target, who monitors synchronization, who approves cutover, who validates business data, and what happens if the target must be abandoned after it has already accepted writes.
This guide is for teams choosing a migration provider, consultant, or destination platform. For the operational runbook itself, use Database Migration Checklist for Managed Databases. For expand-and-contract, replication, and low-downtime implementation patterns, use Zero-Downtime Database Migrations.
Database migration services: the quick decision framework
Not every database move needs the same service model.
| Service model | Best fit | What you are buying | Main trade-off |
|---|---|---|---|
| Destination-provider migration assistance | Same-engine moves into a managed database | Provider knowledge, target setup, transfer and cutover assistance | Scope is usually limited to supported source/target combinations |
| Cloud migration tooling | Teams with database operations expertise | Managed full-load and change-sync tooling | Your team still owns much of architecture, validation and application cutover |
| Database migration consultant | Complex, business-critical or unusual workloads | Discovery, planning, execution and project ownership | Higher services cost and more vendor coordination |
| DIY database-native migration | Small, well-understood same-engine workloads | Maximum control and lowest external-service dependency | Your team owns every failure mode and cutover decision |
| Modernization / heterogeneous migration project | Engine changes or major redesigns | Schema conversion, application changes and migration program | Highest complexity, testing scope and cost |
The cheapest migration model is not necessarily the one with the lowest invoice. A failed cutover, extended maintenance window, lost writes, or emergency rollback can cost more than the migration service itself.
A migration tool is not the same as a migration service
The current search market is dominated by products such as AWS Database Migration Service, Google Cloud Database Migration Service, Azure Database Migration Service, and Oracle Database Migration. These tools can automate important parts of a move, including initial loading and ongoing change replication for supported databases.
They do not eliminate the decisions around the tool.
A production migration still needs answers to questions such as:
- Is the source engine and version supported?
- Are the schema, extensions, collations, users, or plugins compatible?
- What happens to sequences, generated values, stored routines, or triggers?
- Which applications and workers connect to the source?
- How are credentials and network access handled?
- What replication lag is acceptable before cutover?
- Who pauses or redirects writes?
- How is target data validated?
- What is the rollback deadline?
- How are target-only writes handled if rollback occurs?
A tool helps move data. A service should make ownership around those decisions explicit.
For a small team, that distinction is often more important than the specific migration technology underneath.
What should a database migration service include?
A good service proposal should describe the migration in phases rather than simply promising to “move the database.”
1. Discovery and compatibility assessment
The provider should identify the source and target state before production data moves.
At minimum, discovery should cover:
- source database engine and version;
- target engine and version;
- database size and growth;
- current write rate;
- required extensions or plugins;
- users, roles and permissions;
- character sets and collations;
- stored procedures, triggers and scheduled events;
- connection pooling;
- client applications, workers and reporting tools;
- acceptable downtime, RPO and RTO;
- backup and restore state.
If the provider cannot explain what is unsupported before migration begins, the risk is being deferred to cutover day.
2. Target preparation
The target should be ready before the migration window.
That can include:
- creating the managed database or destination cluster;
- selecting capacity;
- configuring private networking or allowlists;
- TLS and credential setup;
- creating users and permissions;
- configuring backups and recovery;
- validating required extensions and features;
- preparing monitoring;
- testing application connectivity.
This is where a destination provider can have an advantage: the team running the migration also understands the target service and its operational boundaries.
3. Baseline data transfer
For a small database with an acceptable maintenance window, export and import may be enough.
For a larger or busier database, the migration may begin with a baseline copy while production continues writing to the source.
The service should say how it will verify that the baseline is complete, including relevant row counts, object counts, errors, omissions, schema differences, and transfer logs.
4. Ongoing synchronization
When downtime must be short, a service may use replication or change-data capture after the baseline load.
This keeps the target close to the source until cutover.
The important buyer questions are:
- How is lag measured?
- What lag threshold is required before cutover?
- Which changes are not replicated automatically?
- What happens when synchronization breaks?
- How much source log retention is required?
- Who monitors the replication process?
“Continuous replication” is useful only if the team knows what constitutes healthy synchronization.
5. Cutover ownership
The service proposal should state who actually runs the production switch.
A cutover commonly includes:
confirm migration health → control or pause writes → complete final synchronization → validate target state → switch connection configuration → recycle cached connections where needed → validate reads and writes → approve the target as authoritative
The provider may manage the database side while your team manages application configuration. That is fine, but it should be explicit before the maintenance window begins.
6. Validation
Technical validation should be paired with application validation.
A provider can verify database objects and replication state. Your team is usually better positioned to verify whether invoices, subscriptions, entitlements, customer records, jobs, and reports are correct from the application's perspective.
A good migration plan combines both.
7. Rollback and observation
Rollback must be defined before the target becomes authoritative.
The migration service should explain:
- how long the source remains available;
- whether it becomes read-only;
- who can approve rollback;
- how traffic or connection configuration returns to the source;
- what happens to writes created on the target;
- when rollback stops being practical;
- when the source can be retired.
A service that only explains the forward path is incomplete.
What should be in the service scope?
Use this table when comparing proposals.
| Migration responsibility | Ask whether it is included | Why it matters |
|---|---|---|
| Source discovery | Yes | Finds unsupported features and hidden clients early |
| Compatibility assessment | Yes | Prevents engine/version surprises |
| Schema conversion | If needed | Critical for heterogeneous migrations |
| Target provisioning | Usually | Confirms capacity, networking and recovery before cutover |
| Initial data load | Yes | Establishes the target baseline |
| Continuous synchronization | If low downtime is required | Reduces final data-transfer window |
| Replication monitoring | If synchronization is used | A running task is not proof of healthy replication |
| Application connection switch | Clarify | Frequently remains the customer's responsibility |
| Cutover support | Yes for critical migrations | Gives the migration a named operating owner |
| Data validation | Split responsibility | Provider validates database state; customer validates business meaning |
| Rollback procedure | Yes | Prevents improvisation after a failed cutover |
| Post-cutover observation | Preferably | Catches delayed worker, reporting and integration failures |
| Source retirement | Clarify | Old credentials and infrastructure must eventually be removed |
If a provider uses the phrase white-glove migration, ask for this table in practical terms. The label matters less than the responsibilities behind it.
How much do database migration services cost?
There is no useful universal price because migration cost follows workload complexity more than database size alone.
The main cost drivers are:
Database size
A larger dataset usually takes longer to copy, verify, and potentially re-copy after a failed attempt. It can also increase temporary storage and network-transfer requirements.
Write rate
A 500 GB database that changes slowly can be easier to migrate than a smaller database with constant high-volume writes. Write rate affects replication lag, source log retention, cutover timing, and reconciliation risk.
Same-engine vs cross-engine migration
PostgreSQL-to-PostgreSQL or MySQL-to-MySQL generally preserves more compatibility than MySQL-to-PostgreSQL or another heterogeneous move.
Cross-engine migrations can require schema conversion, data-type changes, query changes, application testing, and new operational behavior.
Downtime requirement
A four-hour maintenance window can make a migration much simpler than a requirement for a cutover measured in seconds.
Lower downtime often requires baseline loading, continuous synchronization, more rehearsal, stronger monitoring, and a more complex rollback strategy.
Source and target differences
Major-version changes, unsupported extensions, custom plugins, stored procedures, collations, unusual authentication, or provider-specific features all add discovery and testing work.
Number of database clients
The database itself may have one endpoint, but ten application services, workers, dashboards and integrations may use it. Every client that caches credentials or connections expands the cutover surface.
Validation requirements
Simple row-count checks are different from reconciling financial records, audit histories, tenant data, or customer-facing reports.
Migration support window
A daytime migration with flexible scheduling costs differently from an overnight or weekend production cutover requiring dedicated engineers on both sides.
Common database migration pricing models
Providers usually package migration work in one of several ways.
| Pricing model | How it works | Best fit |
|---|---|---|
| Included with destination service | Migration assistance is bundled or free for supported moves | Teams already choosing the target provider |
| Usage-based migration tooling | Pay for replication/migration resources used | Teams operating the migration themselves |
| Fixed project fee | Defined scope and deliverables | Predictable, well-discovered migrations |
| Time and materials | Pay for consultant/engineer effort | Complex or uncertain migration scope |
| Ongoing managed engagement | Migration is part of a broader operations contract | Teams outsourcing more than the one-time cutover |
Before comparing prices, ask each provider to state what is excluded.
A $0 migration that covers only data copy may be less useful than a paid service that owns discovery, cutover, validation and rollback. Conversely, paying a consultant for a small same-engine database with an easy maintenance window can be unnecessary.
Is “zero-downtime database migration” really zero downtime?
Treat zero-downtime language as an architecture claim that needs a definition.
Continuous synchronization can keep the target nearly current while the source stays live. That can reduce the final data-transfer window dramatically.
But users may still see an interruption from:
- pausing or controlling writes;
- application restarts;
- connection-pool recycling;
- DNS or endpoint changes;
- credential changes;
- long-running transactions;
- lag catching up;
- client retry behavior.
Ask the provider:
From which event to which event do you measure downtime?
A provider may mean the database replication path remains available while the application still needs a short reconnect window.
Raff's current Managed Databases migration workflow advertises continuous replication for supported migrations and says that, once replication lag reaches zero, cutover is usually under 30 seconds. That is a useful operating target, not a universal guarantee for every source, engine, application, or workload. Compatibility and the expected interruption should be validated before scheduling production cutover.
For the mechanics behind these patterns, see Zero-Downtime Database Migrations.
When should you use a migration service instead of DIY?
DIY is reasonable when most of these are true:
- the source and target use the same database engine;
- the database is small enough to copy within an acceptable window;
- a maintenance window is available;
- the team understands backup and restore;
- extensions and features are straightforward;
- there are few application clients;
- rollback is simple;
- an engineer can own the complete migration window.
Provider-assisted migration becomes more valuable when:
- the database is business-critical;
- downtime must be very short;
- the workload is write-heavy;
- the database is large;
- source and target differ materially;
- replication or CDC is required;
- there are many application clients;
- the team lacks database operations experience;
- rollback after target writes is difficult;
- the destination provider has migration tooling and engineers already familiar with the target platform.
A consultant is most useful when the move also includes an engine change, major application redesign, unusual extensions, compliance-heavy data handling, or a large multi-database program.
Questions to ask a database migration provider
Ask these before agreeing to a production migration:
- Which exact source and target engines and versions do you support?
- What features, extensions, plugins or objects are not supported?
- Is schema conversion included, or only data movement?
- Will you use continuous replication or a maintenance-window copy?
- How is replication lag measured and monitored?
- Who owns the application connection-string and credential switch?
- Who is present during production cutover?
- What database validation do you perform?
- What validation remains our responsibility?
- What exact conditions trigger rollback?
- How are writes created on the target handled if rollback happens?
- How long does the source remain available after cutover?
- Are network-transfer or egress charges separate?
- What happens if the cutover has to be repeated?
- What backups, PITR, monitoring and HA are active on the target after migration?
- What post-cutover support window is included?
If these answers are vague, the migration scope is not ready for production.
Raff database migration assistance
Raff Managed Databases currently includes migration assistance for supported workloads rather than requiring customers to operate a data-migration tool alone.
The public migration workflow describes:
- source assessment;
- target database preparation;
- continuous replication for supported low-downtime moves;
- engineer-assisted cutover;
- validation during the transition;
- migration assistance included without a separate migration-service fee for supported cases.
Public examples include migrations from AWS, DigitalOcean, Supabase and self-hosted databases. The Managed MySQL workflow also references sources such as Amazon RDS MySQL and Aurora.
That makes Raff a practical fit when the destination is already Managed PostgreSQL or Managed MySQL and the workload fits the supported migration path.
It does not mean every database, extension, engine combination, topology, or zero-downtime requirement is automatically supported. The correct first step is to validate the source engine/version, database size, write rate, compatibility requirements, networking and expected cutover model before promising a migration window.
For teams that need host-level control, unsupported database components, or a topology outside the managed service boundary, self-hosting on a VM may still be the better target. Use Managed Database vs Self-Hosted for that decision.
Database migration service provider checklist
Scope
- Source and target versions are documented.
- Supported and unsupported features are written down.
- Schema conversion responsibility is explicit.
- Every application, worker and reporting client is inventoried.
- Downtime, RPO and RTO expectations are agreed.
Data movement
- Baseline transfer method is documented.
- Continuous synchronization is defined if required.
- Replication lag has a measurable cutover threshold.
- Transfer failures and retries have owners.
- Network and egress costs are understood.
Cutover
- One person owns the go/no-go decision.
- Write authority is explicit at every phase.
- Application connection changes have an owner.
- Target reads and writes are validated.
- Background workers and integrations are checked.
Rollback
- Rollback triggers are written before cutover.
- The source-retention period is defined.
- Target-only write handling is understood.
- The rollback deadline is explicit.
- The source cannot accidentally continue as a second writer.
After migration
- Target backups and recovery are active.
- Monitoring and alerts are active.
- Application owners approve business validation.
- Temporary credentials and migration tooling are removed.
- Source retirement is approved and documented.
Conclusion
The best database migration service is not the provider with the most impressive copy tool. It is the one whose scope matches the risk of your workload and whose responsibilities are clear before production cutover.
For a small same-engine database with an acceptable maintenance window, DIY may be enough. For a large, write-heavy, low-downtime or business-critical database, provider-assisted migration or specialist consulting can reduce operational risk substantially.
Compare providers on discovery, compatibility, synchronization, cutover ownership, validation, rollback and post-cutover support—not only on headline price or a “zero downtime” label.
If Raff Managed PostgreSQL or MySQL is the intended destination, Raff currently offers migration assistance for supported workloads, including continuous replication and engineer-assisted cutover paths. Validate the exact source and workload first, then design the cutover around measurable lag, application reconnect behavior and a written rollback plan.