Database Migration to Managed Cloud Databases with Minutes of Cutover
Database migration moves a database to a managed cloud service on the same or a compatible engine, such as SQL Server to Azure SQL Managed Instance or MySQL to Cloud SQL, with continuous replication so cutover takes minutes. NTSPL sizes the target, runs CDC replication, validates row counts and checksums, and rehearses the cutover before switching applications.
Delivered on
In scope
Why Same-Engine Database Moves Still Fail
The database is usually the last thing to move and the first thing blamed when a migration goes wrong. A 2 TB SQL Server with 400 stored procedures, linked servers and a nightly SSIS job cannot be copied over a weekend and switched on Monday. Logins, collations, SQL Agent jobs, Oracle DB links and MySQL definer users all break quietly. And if the app server moved last week, every query now crosses the hybrid link, adding 15-30 ms per round trip.
NTSPL keeps the engine the same, or moves only to a compatible version, so code does not change. We pick the managed target by feature fit, seed it from a backup or native dump, then keep it current with change data capture until cutover. Row counts, checksums and a set of business queries are compared before switching, and the cutover is rehearsed with a stopwatch so the real window is known in minutes.
Signals Your Database Is Ready for a Managed Target
Signals you need Database Migration
- The database is on SQL Server, Oracle, MySQL or PostgreSQL and the app team wants no code changes.
- DBAs spend more than 30% of their time on patching, backups and HA instead of tuning.
- The engine version is near or past end of support, such as SQL Server 2016 or MySQL 5.7.
- The business can accept a cutover of 5-30 minutes but not a full weekend outage.
When to choose something else
- If you want to leave Oracle or SQL Server for PostgreSQL, Aurora or AlloyDB, that is an engine change; see Managed Database Modernization in Application Modernization.
- If the source is a data warehouse such as Teradata or Netezza, see Data Modernization & Migration in Data & Analytics.
Target Fit, Replication, Validation and Cutover
Target fit check
Features in use, such as CLR, linked servers, DB links, cross-database queries or file-system access, are matched to managed options.
Sizing
vCores, memory, IOPS and storage are sized from 30 days of wait statistics and IO data, not from the source hardware.
Seed and CDC replication
Initial load by backup restore or native dump, then change data capture or log shipping to keep the target current.
Validation
Row counts, table checksums and 20-50 business queries are compared between source and target.
Cutover and rollback
Rehearsed switch with a reverse replication or snapshot plan, timed in minutes.
Seed-Sync-Validate-Switch Database Pipeline
Seed-Sync-Validate-Switch Database Migration Pipeline
A fit check selects the managed target, which is seeded from a backup or dump and kept current through CDC. Validation gates the rehearsed cutover, with reverse sync available for rollback.
Select any component
Seed-Sync-Validate-Switch Database Migration Pipeline: click any of its 7 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Managed Database Targets and Migration Services by Cloud
Large SQL Server and Oracle databases are seeded with native backup restore into RDS, then DMS CDC keeps them in sync. RDS Custom covers apps needing OS-level access.
SQL Server workloads that need SQL Agent or cross-database queries go to Managed Instance; Managed Instance link uses distributed availability groups for near-real-time sync.
Database Migration Service runs continuous homogeneous migrations of MySQL, PostgreSQL and SQL Server into Cloud SQL, with promotion as the cutover step.
Database Migration Choices: Target, Method, Version
PaaS database or database on a VM
Pick managed PaaS when the database uses standard features and the team wants patching and HA handled. Stay on a VM when the app needs sysadmin rights, OS-level agents, unsupported features such as some CLR assemblies, or a specific minor version the vendor certifies. A middle option on AWS is RDS Custom. Record the reason, because VM-hosted databases carry more operational effort.
Seeding method by size
Under 200 GB, a migration service full load is usually fine. From 200 GB to 5 TB, restore a native backup from object storage, then start CDC from the backup's log position. Above 5 TB or over thin links, ship the backup through a transfer service and start CDC once it lands. Never run a multi-day full load through DMS when a backup restore takes hours.
Version jump during migration
Upgrading one major version during migration, such as SQL Server 2016 to 2022 compatibility or MySQL 5.7 to 8.4 (8.0 reached community end of life in April 2026), is usually worth it. Keep the database compatibility level at the old value on day one, run the app for two weeks, then raise it. MySQL 8.x changes default collation and reserved words, so scan for them before moving.
Cutover window and rollback
Set the window at the rehearsed time plus 50%. If reverse replication is available, keep it running for 48 hours so writes after cutover can flow back. If not, take a target snapshot right after switch and define a hard decision point, usually 2-4 hours, after which rollback means data re-entry.
Database Move Sequence from Fit Check to Switch
Feature scan and target choice
Objects inventoried, target selected per database, sizing set from waits and IO.
Target build and seed
Managed instance created with networking, encryption and parameters; seeded from backup.
CDC sync and validation
Replication running, checksums compared, business queries passed.
Cutover rehearsal
Full dry run timed and runbook adjusted.
Production switch and tuning
Switch in the agreed window, then two weeks of query and index tuning.
What you receive
Data Integrity and Cutover Window Measures
| KPI | Typical target |
|---|---|
| Cutover downtime | 5-30 minutes for most OLTP databases |
| Row count and checksum mismatches at switch | Zero |
| Replication lag before switch | Under 5 seconds |
| p95 query time after 2 weeks | Equal to or better than source |
Hidden Database Objects That Break After Cutover
| Risk | How NTSPL prevents it |
|---|---|
| SQL Agent jobs, linked servers or DB links are left behind and nightly processes stop. | Feature scan lists every job and link; each is recreated and tested in the rehearsal. |
| Logins and definer users fail, so apps cannot connect. | Logins and SIDs are scripted and verified before cutover; MySQL definers are rewritten. |
| App servers left on-prem query the cloud database across the link and slow down. | Database and its main app servers move in the same wave unless latency tests show under 5 ms. |
Azure SQL Managed Instance or SQL Server on an Azure VM?
Choose Managed Instance when the database uses SQL Agent, cross-database queries or linked servers but nothing that needs OS access; you get near-full SQL Server compatibility with patching, backups and HA handled. Choose SQL Server on a VM when the vendor requires sysadmin, a specific build, SSRS or SSIS on the same box, or file-system access. Managed Instance usually costs more per vCore but less in DBA effort. For most mid-size ERPs and line-of-business apps, Managed Instance is the default unless the vendor's support statement says otherwise.
Key facts: Database Migration
Database Migration in Practice
2 Database Migration scenarios, from Stock brokerage back office and Eye-care hospital chain, plus related platform case studies.
Brokerage back office moves 3.1 TB Oracle settlement database to RDS in a 14-minute window
Eye-care hospital chain moves 38 clinics' MySQL 5.7 records to MySQL 8.0 on Azure
NBFC moves loan-origination Oracle database to Aurora PostgreSQL and drops EE licences
Microfinance lender moves loan SQL Server to Managed Instance in an 18-minute cutover
Database Migration: Frequently Asked Questions
How much downtime does a database migration need?
With CDC or log-based replication, cutover is usually 5-30 minutes: stop writes, let replication drain, validate, and repoint the app. Without continuous replication, downtime equals backup, copy and restore time, which for a 1 TB database can be several hours.
What does a database migration cost?
A single 500 GB to 2 TB database with standard features typically costs INR 3-8 lakh in services, including rehearsal and two weeks of tuning. Databases with many jobs, links or custom objects cost more. Native migration services are free or low cost; the target database is the main run cost.
Can we move SEBI- or RBI-regulated databases to cloud?
Yes, when the target runs in Indian regions and you meet the regulator's controls on encryption, access, audit logs and outsourcing. For SEBI-regulated entities, map the move to the Cybersecurity and Cyber Resilience Framework. We set audit logging with 180-day retention for CERT-In.
Will our stored procedures need rewriting?
No, as long as the engine stays the same. Procedures, functions and triggers move as-is. You may need to adjust features the managed service does not support, such as some CLR assemblies or OS file access, which the feature scan finds early.
How do you prove no data was lost?
We compare row counts and table-level checksums between source and target before switching, then the application owner runs 20-50 business queries such as month-to-date totals, open orders and ledger balances. The validation report is signed by both the DBA and the owner before cutover is approved.
Can we upgrade the version during migration?
Usually yes, one major version at a time. We keep the old compatibility level at first and raise it after two weeks of stable running. MySQL 5.7 to 8.x needs a scan for collation and reserved-word issues before the move.