PostgreSQL Migration: learn the cutover before you live it.
Three days on the full migration lifecycle — assessment, schema and code conversion, CDC data movement, parity testing, cutover rehearsal, and tuning. Your team practices on a realistic estate, then runs a simulated cutover.
What this course is
Built for teams about to migrate — or mid-migration and feeling it. We teach the methodology from our migration practice: the same assessment framework, conversion patterns, and cutover discipline we use on client engagements, taught on a lab estate that behaves like a real one.
Who should attend
- DBAs and database engineers owning a migration to PostgreSQL
- Data engineers rebuilding ETL around the new platform
- Architects and tech leads planning or governing the migration program
What you need coming in
- Professional SQL; familiarity with SQL Server or Oracle
- Basic PostgreSQL familiarity helpful but not required
- Lab environments (source + target + replication) provided
Learning objectives
- Run a structured migration assessment: inventory, workload profiling, and compatibility scoring
- Convert schemas and procedural code (T-SQL and PL/SQL patterns) to PostgreSQL with behavioral parity
- Set up initial load plus CDC replication and continuous data validation
- Execute parity testing, performance validation, and failure drills
- Plan and rehearse cutover and rollback with defined trigger criteria
- Tune PostgreSQL post-migration: autovacuum, connections, indexes, and monitoring
Day by day
Day 1 — Assessment & compatibility: scope before you promise
Estate inventory methodology, workload profiling with real traces, dependency mapping, and per-object compatibility scoring. The type-mapping decisions that cause the most post-migration bugs: datetime semantics, collations, and case sensitivity.
LABS → inventory a sample estate; score compatibility with SCT/ora2pg output; profile a workload and set the performance baselineDay 2 — Schema & code conversion: the hand work
DDL conversion and the judgment calls tools can't make. T-SQL → PL/pgSQL and PL/SQL → PL/pgSQL idiom rewrites: error handling, temp tables, cursors, dynamic SQL, autonomous transactions, package state. Unit-testing converted code with production fixtures.
LABS → convert a procedure set with tooling, then hand-fix the failures; write fixture-based unit tests; triage a behavioral diffDay 3 — Data movement, cutover & tuning
Initial load + CDC replication, validation jobs, parity testing, and performance validation. Then the simulated cutover: flip writes, run the smoke tests, trigger the rollback drill. Post-migration tuning: autovacuum, PgBouncer, index rationalization, monitoring.
LABS → run CDC into a live target; execute the cutover runbook; roll back on a trigger; tune a migrated workloadDelivery options
3-day course
The complete syllabus, onsite or virtual, up to 16 participants. Lab estate provided. Includes a post-course office-hours session.
1-day exec workshop
Migration economics, risk, sequencing, and what to demand from a migration partner — for the leaders signing the decision.
Migration-adjacent deep dives
Focused 1–2 day modules: PL/SQL conversion clinic, CDC and cutover workshop, or PostgreSQL operations for Oracle/SQL Server DBAs.
Private cohorts only, tailored to your source platform in a pre-course scoping call. Planning the migration itself? Start with our SQL Server → PostgreSQL guide, Oracle → PostgreSQL guide, or request an assessment.
Rehearse the migration before it counts.
Tell us your source platform, estate size, and timeline — we'll scope the cohort and send a proposal.