Building the Product Team

A migration is a product delivery. It has a scope, a timeline, a risk profile, and a set of stakeholders who need different things from it. The team that delivers it must include people who understand Oracle, people who understand PostgreSQL, people who understand the application, people who operate infrastructure, and someone who coordinates between all of them. None of these roles can be collapsed without creating a gap that will surface at the worst possible time.

This chapter covers how to staff a migration team, what each role does at each phase, how the migration war room operates during parallel running and cutover, and what post-cutover support looks like.

20.1 The Core Roles

A production migration team needs five functional roles. On a small team, one person may fill two adjacent roles. No one person should fill three or more — the cognitive load is too high and the blast radius of a single person's absence is too large.

Oracle DBA

Phase: Assessment (lead), Full load (support), Parallel running (support), Cutover (critical)

The Oracle DBA is the authority on the source system. They:

• Run the assessment queries against Oracle (DBA_TABLES, DBA_CONSTRAINTS, DBA_SOURCE, V$SESSION)
• Enable supplemental logging on all in-scope tables
• Identify the undo retention setting and advise on whether it supports the planned full load duration
• Monitor Oracle health during the full load (no unexpected redo spikes, no archive log space issues)
• Confirm the SCN anchor before each full load run
• Execute the write-stop at cutover
• Remain on-call during the rollback window in case Oracle needs to be restored

What this role is NOT: the Oracle DBA is not expected to know PostgreSQL. They are asked to provide Oracle expertise, not to cross-train under pressure.

PostgreSQL DBA / Engineer

Phase: Schema migration (lead), Full load (support), CDC (support), Parallel running (lead), Cutover (critical)

The PostgreSQL engineer is the authority on the target system. They:

• Review and apply the generated DDL (pre-load and post-load)
• Configure PostgreSQL for load performance (WAL settings, parallel workers, connection limits)
• Monitor PostgreSQL health during the full load and CDC (bloat, I/O, connection counts)
• Apply post-load indexes and constraints
• Run the compensating writes generated by reconciliation
• Tune query plans if application performance on PostgreSQL is below expectations
• Confirm sequence advancement at cutover

Migration Engineer (Pulsaride Transform operator)

Phase: All phases (primary operator)

The migration engineer is the primary operator of the Pulsaride Transform pipeline. They:

• Configure the pipeline YAML for each table, normalization rule, and wave plan
• Start and monitor the full load
• Start and monitor CDC
• Respond to pipeline alerts (stalled chunks, CDC lag spikes, rejected rows)
• Run reconciliation and interpret its output
• Generate and propose compensating writes
• Execute the cutover command and monitor the cutover procedure
• Operate the reverse replication pipeline during the rollback window

This is the most operationally intense role during the parallel running phase. The migration engineer should be the person most familiar with the Pulsaride Transform documentation and the monitoring dashboard.

Application Engineer

Phase: Assessment (support), Schema migration (lead for application impact), Application testing (lead), Cutover (support)

The application engineer understands how the application uses the Oracle database. They:

• Identify which Oracle features the application depends on (PL/SQL calls, trigger behavior, sequence usage patterns)
• Review the identifier normalization mapping (Chapter 5) and update application code accordingly
• Update ORM mappings, JDBC queries, and connection configurations for PostgreSQL
• Run the application functional test suite against the PostgreSQL target during parallel running
• Confirm that application behavior is identical on PostgreSQL (performance, data, business rules)
• Execute the connection string switch at cutover

Project Manager / Migration Lead

Phase: All phases (coordination and communication)

The migration lead is not a technical role but a coordination role. They:

• Maintain the migration timeline and flag when slippage is occurring
• Coordinate between the Oracle DBA, PostgreSQL engineer, and application engineer
• Manage the go/no-go checklist and ensure all process gates are tracked
• Communicate status to stakeholders (weekly status report during preparation, daily during parallel running, real-time during cutover)
• Manage the maintenance window scheduling and notification process
• Run the war room during cutover

20.2 What Migration Costs Without the Right Product

Migration cost is not determined by database size — it is determined by how many unknowns your pipeline can absorb.

A team migrating 50 tables with deeply embedded PL/SQL business logic, circular foreign keys, and no documented trigger behavior faces a harder problem than a team migrating 500 clean transactional tables with no procedural code. The size metric that most pre-migration estimates use is the wrong variable. The structural complexity metric — how many edge cases the pipeline has to handle automatically versus how many surface as incidents — is the right one.

This section presents outcome data from Pulsaride Transform customer migrations (anonymized), compared against the same migration types executed with assembled tooling or external consultancies. The purpose is not to disparage alternatives; it is to give decision-makers the information they need before committing an engineering team to an approach.

	DIY pipeline team	AWS DMS + consultancy	Pulsaride Transform + lean team
Team size	8–12 engineers	6–10 (incl. consultants)	3–5 engineers
Time to first cutover	6–12 months	4–8 months	6–10 weeks
Post-cutover data cleanup	4–8 weeks	2–4 weeks	< 1 week
Second migration on same estate	Same as first	Same as first	40–60% faster
Knowledge retained after migration	In your codebase	Leaves with consultants	In the rule library
Ongoing pipeline ownership	Your burden to maintain	Consultants gone	Product-supported
Incident rate during parallel running	High (first migration)	Medium	Low

The driving variable in every row is the same: whether the structural problems (dependency resolution, staging durability, reconciliation feedback, cutover gate enforcement) are solved by the product or rebuilt manually. When they are rebuilt manually, you pay the rebuild cost on every migration. When the product solves them, the cost is paid once — and compounds in your favor.

The numbers in the "Time to first cutover" row typically surprise teams the most. The 6–10 week figure for Pulsaride Transform is not an aspirational target; it reflects migrations where the schema assessment, full load, CDC, and continuous reconciliation pipeline is configured and running within the first week, and the remaining weeks are parallel running with the readiness gates building toward the cutover window.

The 6–12 month figure for DIY teams reflects the reality that the pipeline architecture takes months to get right under production data — not because teams are slow, but because the structural problems do not reveal themselves until the system is running at scale.

The second migration figure is the one most teams do not consider at the point of decision. If your Oracle estate has multiple schemas, departments, or phases of migration, the cost trajectory matters as much as the first-migration cost. Pulsaride Transform's reconciliation rule library compounds; every approved rule from migration N reduces cleanup time on migration N+1.

Start your first migration with Pulsaride Transform for free →

20.3 Extended Team: When to Involve Others

Beyond the core five roles, certain migration scenarios require additional expertise:

Infrastructure engineer: Needed when migration requires network configuration changes (new database endpoint, firewall rules, connection pooling), storage provisioning for the PostgreSQL target, or Kubernetes deployments for the pipeline.

Security engineer: Needed when the migration touches PII (to verify that encryption at rest and in transit are configured identically on PostgreSQL), or when the Oracle access control model (roles, grants) must be reproduced in PostgreSQL.

Business analyst: Needed when reconciliation aggregate discrepancies surface data quality issues in Oracle that require business decisions to resolve (the 4,421 NULL email rows in Chapter 11 were a business decision, not a technical one).

Vendor support: Needed when Pulsaride Transform produces unexpected behavior. The support contract with Pulsaride includes a migration support channel — use it when stuck, not after hours of debugging.

20.3 Phase Responsibilities Matrix

Activity	Oracle DBA	PG Engineer	Migration Eng	App Engineer	PM
Assessment queries	Lead	Review	Support	—	Schedule
DDL review	Review	Lead	Support	Review	—
Application code changes	—	—	—	Lead	Track
Full load execution	Monitor Oracle	Monitor PG	Lead	—	Track
CDC monitoring	Monitor	Monitor	Lead	—	Track
Reconciliation	—	Apply fixes	Lead	—	Track
App testing on PG	—	—	Support	Lead	Track
Go/no-go decision	Vote	Vote	Vote	Vote	Chair
Cutover procedure	Write-stop	Sequences	CDC drain	Conn switch	MC
Post-cutover monitoring	Standby	Monitor	Monitor	Monitor	Communicate

20.4 The Migration War Room

The war room is the operations center during cutover and the 4-hour post-cutover window. It can be physical or virtual (a persistent video call with screen sharing).

War room requirements:

• All five core roles present or on-call (max 5-minute response time)
• Monitoring dashboard visible to all participants
• Shared runbook document open (everyone can see the current step)
• Communication channel open with business stakeholders (they don't need to be in the war room, but they need updates every 5 minutes during cutover)
• Decision log: every decision made and by whom, timestamped

War Room Communication Cadence During Cutover

T-60min: "We're entering the final preparation hour. All checklist items confirmed."
T-15min: "Automated gates re-confirmed. CDC lag: 11 seconds. GO."
T+0:     "Maintenance window open. Starting cutover procedure."
T+01:    "Oracle writes stopped."
T+04:    "CDC drain complete. Lag = 0."
T+16:    "Final reconciliation: PASS."
T+19:    "Cutover complete. PostgreSQL is live. Smoke tests passing."
T+25:    "First 5 minutes clean. Continuing monitoring."
T+90:    "90-minute post-cutover checkpoint: no issues. Rollback window closes in 2h30m."
T+240:   "Rollback window closed. Migration complete. War room stands down."

Stakeholder communication at T+19 and T+240 is the minimum. Add more checkpoints if the business requires them.

20.5 Post-Cutover Support Model

The migration is not done at cutover. The first 30 days post-cutover are the highest-risk period for discovering application behaviors that were not tested, query plans that differ from Oracle, or data quality issues that surface in production use.

Week 1: Heightened Monitoring

• pulsaride-monitoring remains running with PostgreSQL-side metrics only
• Application error rate monitored against pre-migration baseline
• Slow query log reviewed daily by the PostgreSQL engineer
• Any data anomaly reported by the business is investigated within 2 hours

Week 2–4: Normalization

• Slow queries are tuned (new indexes, query rewrites)
• Any data quality issues discovered in production are traced through the reconciliation history
• The application engineer completes final ORM and connection configuration cleanup
• Documentation is updated: connection strings, DBA runbooks, application configuration

Day 30: Migration Retrospective

• All five core roles attend
• Timeline: what went according to plan, what did not
• Incidents: what went wrong, root cause, what was done, what would be done differently
• Product feedback: findings for the Pulsaride Transform team (bugs, missing features, documentation gaps)
• Oracle decommission plan: confirm that Oracle is no longer receiving writes, set a decommission date

The retrospective is not a blame session. It is a structured knowledge transfer that makes the next migration faster.

20.6 Communication Patterns That Work (and Ones That Don't)

What works:

• A single shared status document updated after each shift, readable by all stakeholders
• A #migration-ops Slack channel for technical team communication with no business stakeholders (they get a daily summary)
• A #migration-status Slack channel for business stakeholders with summarized, non-technical updates
• Explicit escalation paths: who to call for each type of incident, at what hour, with what information

What doesn't work:

• Email chains for time-sensitive decisions during cutover
• Status meetings that describe what happened yesterday during a week-long parallel running phase (replace with a dashboard link)
• A single person who is the only one who understands the pipeline configuration — create a brief handover document on day 1
• Verbal go/no-go decisions without a written record — the go/no-go checklist must be written, signed, and retained

20.7 Example: Staffing a Financial Services Migration

A financial services company is migrating a 340-table Oracle schema. The team:

• Oracle DBA: Elena (10 years Oracle experience, on the project for 8 weeks from assessment through post-cutover week 1)
• PostgreSQL engineer: Marcus (PostgreSQL expert, hired 3 months before migration start for the PostgreSQL build-out)
• Migration engineer: Layla (Pulsaride Transform certified operator, dedicated to this project)
• Application engineer: Two engineers sharing the role: David (backend, JDBC/Hibernate) and Sara (batch processing, DBMS_SCHEDULER migration)
• Migration lead: Ahmad (project manager with a previous Oracle migration under his belt)

Engagement timeline:

• Week -8 to -6: Elena runs assessment. Ahmad sets timeline. Marcus configures PostgreSQL infrastructure.
• Week -5 to -3: Layla configures pipeline. David and Sara update application code.
• Week -2 to -1: Full load run 1 (dry run to test pipeline configuration). Issues found and fixed.
• Week 0: Full load run 2 (production). Completes in 36 minutes.
• Week 1–2: CDC catch-up. Reconciliation begins. David and Sara run application test suite.
• Week 3: Parallel running. All reconciliation gates pass. Go/no-go checklist prepared.
• Week 3, Saturday: Cutover. 19 minutes. Clean.
• Week 4–6: Post-cutover support. 3 slow queries identified and indexed. No data incidents.
• Week 7: Retrospective. Oracle decommission scheduled for week 14.

Total engagement: 15 weeks for a 340-table financial schema. The 19-minute cutover was the culmination of 14 weeks of preparation.