A database migration service helps a team move production data to a new database environment while coordinating compatibility, target preparation, transfer, synchronization, cutover, validation, and rollback.
For buyers, the important question is not whether a provider has a migration tool. It is which migration responsibilities the provider owns, which remain with your team, and what evidence is required before production cutover.
Raff supports assisted migrations into Managed Databases for supported workloads. If you are still deciding between provider-managed and self-hosted operations, start with Managed Database vs Self-Hosted. This guide focuses on the next decision: how to compare migration services, consultants, tools, cost drivers, and provider scope.
For the execution runbook, use Database Migration Checklist for Managed Databases. For synchronization and low-downtime implementation patterns, use Zero-Downtime Database Migrations.
Database migration services differ mainly in responsibility ownership
The right migration model depends on operational risk, not only database size.
| Migration model | Best fit | What the buyer owns | What the provider or tool owns |
|---|---|---|---|
| DIY database-native migration | Small, well-understood same-engine move | Planning, transfer, cutover, validation, rollback | Little or none |
| Cloud migration tool | Team already has database operations expertise | Architecture, compatibility, application cutover, validation | Full load and synchronization mechanics |
| Destination-provider assistance | Moving into a supported managed database | Application changes, business validation, final approvals | Target setup and supported migration assistance |
| Database migration consultant | Complex or business-critical migration | Internal business decisions and application validation | Discovery, migration design, execution support, coordination |
| Modernization project | Engine change or major redesign | Product and application decisions | Schema conversion, data transformation, migration program |
A 20 GB database with many writers, strict downtime requirements, custom extensions, and difficult rollback can require more migration work than a larger database with a quiet maintenance window.
A migration tool does not replace a migration service
Migration tools automate mechanics such as:
- initial data loading;
- replication or change data capture;
- ongoing synchronization;
- transformation for supported objects;
- lag visibility;
- task retries.
A production migration still needs human ownership for questions such as:
- Is the exact source engine and version supported?
- Are extensions, plugins, collations, users, and stored routines compatible?
- Which applications, workers, jobs, and integrations use the source?
- How are credentials and network rules changed?
- What synchronization lag is acceptable?
- Who controls writes during cutover?
- Who validates business-critical records?
- What triggers rollback?
- What happens to writes created on the target after cutover?
A tool primarily moves or synchronizes data. A service defines the responsibility boundary around that move.
That distinction matters when evaluating AWS DMS, Google Cloud Database Migration Service, Azure database-migration tooling, a specialist consultant, or assistance from the destination database provider.
A complete migration service starts with discovery and compatibility
A credible migration scope should establish the real source and target state before production data moves.
Discovery should cover:
- source engine and version;
- target engine and version;
- database size and growth rate;
- write volume;
- connection demand;
- extensions and plugins;
- stored procedures, functions, triggers, events, and generated values;
- character sets and collations;
- users, roles, and permissions;
- application drivers;
- connection pooling;
- application and worker clients;
- networking and TLS;
- backup and recovery state;
- downtime tolerance;
- recovery point objective (RPO) and recovery time objective (RTO);
- rollback constraints.
A useful discovery output separates three states:
| Result | Meaning |
|---|---|
| Supported as-is | No known migration blocker for this requirement |
| Supported with change | Application, schema, network, or operational change required |
| Unsupported or unresolved | Must be solved before production cutover |
If unsupported items are still unknown on migration day, the risk has not disappeared. It has only been deferred.
Target preparation should finish before the migration window
The target should be production-ready before the final transfer or synchronization phase begins.
Target preparation can include:
- provisioning the managed database or target host;
- selecting initial capacity;
- configuring private networking or scoped access;
- creating credentials and roles;
- validating TLS requirements;
- enabling required extensions and features;
- configuring backups and recovery;
- configuring monitoring and alerts;
- testing application connectivity;
- confirming connection limits and pooling behavior.
A destination-provider migration service reduces coordination because the same organization operates the target platform. Buyers still need the provider to state exactly what is included.
Baseline transfer and synchronization solve different parts of the move
For a small database with an acceptable maintenance window, a logical export and import can be enough.
For larger or busier workloads, migration often starts with a baseline copy while the source remains active. The service should explain how it validates that baseline, including transfer logs, failed objects, skipped objects, row or object counts, schema differences, and representative integrity checks.
When the final outage must be short, continuous or repeated synchronization keeps the target close to the source after the baseline copy.
Ask:
- How is lag measured?
- What lag threshold allows cutover?
- Which data definition language changes or objects are not replicated?
- Who monitors synchronization?
- What happens when synchronization fails?
- How much source log retention is required?
- What happens if lag grows during the cutover window?
Operational insight from Raff: treat replication lag, recovery readiness, and write authority as separate cutover gates rather than assuming that a running replication task is enough evidence to switch production.
Go or no-go ownership should be explicit before cutover
A migration service should identify who has authority to proceed.
Before cutover, the team should know:
- who confirms target health;
- who confirms synchronization health;
- who approves the final write-control step;
- who changes application endpoints or secrets;
- who recycles long-lived connection pools;
- who validates reads and writes;
- who declares the target authoritative;
- who can trigger rollback.
A controlled sequence is:
confirm target and recovery readiness -> control writes -> complete final synchronization -> validate target state -> switch endpoint or configuration -> recycle cached connections -> validate reads and writes -> verify workers and integrations -> declare target authoritative
If the provider manages only the database side while your team owns application configuration, that boundary is workable. It must be documented before the maintenance window.
Technical validation and business validation are separate responsibilities
The migration provider can validate technical database state, including:
- schemas and objects;
- synchronization status;
- key row or object counts;
- users and permissions;
- connection success;
- database health.
The application team should validate business meaning, including:
- authentication;
- tenant or account data;
- billing and subscription records;
- critical writes;
- background jobs;
- scheduled jobs;
- reports;
- integrations;
- customer-facing workflows.
A migration is not complete because the database server accepts queries.
Rollback must be defined before the target accepts production writes
The provider scope should define the backward path before the target becomes authoritative.
Ask:
- How long is the source retained?
- Is the source read-only after cutover?
- Who can approve rollback?
- How is traffic or configuration returned to the source?
- How are target-only writes handled?
- When does rollback stop being practical?
- What observation or support window follows cutover?
- Who approves source retirement?
A migration service that describes only the forward path is incomplete.
The provider checklist should translate marketing language into concrete scope
Use this table when comparing providers or consultants.
| Responsibility | What to verify |
|---|---|
| Source discovery | Who inventories engine, versions, clients, size, write rate, and dependencies? |
| Compatibility assessment | Who identifies unsupported features before migration? |
| Schema conversion | Is heterogeneous conversion included or separately scoped? |
| Target provisioning | Who configures capacity, networking, users, monitoring, and backups? |
| Baseline transfer | How is initial data load performed and verified? |
| Synchronization | Is change data capture or replication included when low downtime is required? |
| Replication monitoring | Who watches lag, errors, and retained logs? |
| Application endpoint change | Provider, customer, or shared? |
| Go or no-go decision | Who can authorize production cutover? |
| Validation | Which technical checks are provider-owned and which business checks are customer-owned? |
| Rollback | Is the backward path documented before target writes? |
| Post-cutover support | How long does an engineer remain engaged after the switch? |
| Source retirement | Who approves shutdown, credential removal, and cleanup? |
Words such as white-glove, managed migration, or zero downtime should be translated into these responsibilities.
