Database migration is the process of moving from one database to another (MySQL → PostgreSQL) or upgrading versions (MySQL 5.7 → 8.0). Challenges: (1) Schema differences (AUTO_INCREMENT → SERIAL, data types), (2) Data migration (export, transform, import), (3) Application changes (SQL syntax, connection strings), (4) Downtime (minutes to hours), (5) Risk (data loss, corruption). Migration phases: (1) Assessment (analyze compatibility, estimate effort), (2) Planning (timeline, resources, rollback plan), (3) Schema conversion (DDL mapping, constraints), (4) Data migration (full dump or incremental sync), (5) Testing (unit, integration, performance, data validation), (6) Cutover (switch traffic to new database), (7) Monitoring (watch for issues, ready to rollback). Real-world: GitLab migrated from MySQL to PostgreSQL (2017) - 6 months planning, 3 months execution, 100K+ installations affected. Uber migrated ride matching from MySQL to PostgreSQL - MVCC enabled 50K writes/sec with non-blocking reads.

**Migration Types:**

**1. Version Upgrade (Same Database):**

- Example: MySQL 5.7 → MySQL 8.0, PostgreSQL 11 → PostgreSQL 14

- Easier: Same database, mostly compatible

- Challenges: New features, deprecated syntax, performance changes

- Strategy: Test on staging, upgrade replicas first, then primary

- Downtime: Minutes (with replicas), hours (without replicas)

**2. Database Switch (Different Database):**

- Example: MySQL → PostgreSQL, Oracle → PostgreSQL, MongoDB → PostgreSQL

- Harder: Schema conversion, data type mapping, SQL rewrite

- Challenges: Syntax differences, stored procedures, application changes

- Strategy: Parallel run (dual-write), gradual cutover

- Downtime: Hours to days (big bang), minutes (blue-green)

**3. Cloud Migration:**

- Example: On-premise MySQL → AWS RDS MySQL, Oracle → AWS Aurora PostgreSQL

- Medium: Same database (easier), different database (harder)

- Challenges: Network latency, data transfer time, cost

- Strategy: Database Migration Service (DMS), incremental sync

- Downtime: Minutes (with DMS), hours (without DMS)

**Migration Strategies:**

**1. Big Bang (Single Cutover):**

- Process: Stop application → Export data → Import to new database → Start application

- Pros: Simple, clean cutover, no dual-write complexity

- Cons: Downtime (hours to days), high risk (no rollback), all-or-nothing

- Use case: Small databases (<100GB), low-traffic applications, maintenance windows acceptable

- Example: Small startup migrating MySQL → PostgreSQL over weekend

**2. Phased Migration (Gradual):**

- Process: Migrate tables one by one, application reads from both databases

- Pros: Lower risk (rollback per table), shorter downtime per phase

- Cons: Complex (dual-read logic), longer total time, data consistency challenges

- Use case: Large databases (>1TB), complex schemas, risk-averse organizations

- Example: E-commerce site migrating orders table first, then products, then users

**3. Parallel Run (Dual-Write):**

- Process: Write to both old and new databases, read from old, validate new, switch reads

- Pros: Zero downtime, safe (can rollback), data validation in production

- Cons: Complex (dual-write logic), performance overhead (2x writes), data sync issues

- Use case: High-availability systems, zero-downtime requirement, large user base

- Example: GitLab migration (MySQL → PostgreSQL) used dual-write for 3 months

**4. Blue-Green Deployment:**