A successful cloud migration is not measured when the last byte arrives in AWS. It is measured when the application meets its latency and recovery objectives, the team can operate it at 3 a.m., the bill is explainable, and rollback has become unnecessary. PostgreSQL makes the data move look deceptively simple; dependencies, network behavior, extensions, identity and operating procedures are where projects usually lose time.
Migration factory: evidence must pass through every gate
A gate is complete only when its acceptance evidence exists. A calendar date is not evidence.
1. Start with business and technical success criteria
Write down the reason for moving and turn it into measurable acceptance criteria: maximum cutover downtime, p95/p99 application latency, RPO, RTO, monthly cost envelope, compliance boundaries and a date by which the old environment can be retired. Inventory every database, owner, version, size, growth rate, peak TPS, connection count, extension, scheduled job, external integration, replication consumer and backup dependency. Capture at least four weeks of workload, including month-end and batch peaks.
Build a dependency graph, not a spreadsheet of servers
A database dependency exists whenever a change to the endpoint, clock, network path, collation, role or transaction behavior can change another system. Trace application services, ETL, BI extracts, file drops, DNS aliases, firewall rules, certificates, LDAP/AD authentication, cron jobs, backup exports and logical replication consumers. For every edge, record owner, protocol, direction, frequency, timeout and validation method. This graph becomes the cutover order and prevents the classic surprise of a forgotten reporting job still writing to the source.
| Baseline | Collect | Why it changes the design |
|---|---|---|
| Demand | TPS, query concurrency, p95/p99, hourly and seasonal peaks | Defines compute, pool and headroom—not an average CPU chart |
| Data change | WAL bytes/hour, largest transactions, write hot spots | Determines CDC throughput and how quickly the target can catch up |
| Storage | working set, IOPS, throughput, latency, temp spill, growth | Separates capacity from performance and exposes burst dependency |
| Operations | backup duration, restore duration, incidents, vacuum and patch history | Turns RTO and maintenance into tested engineering constraints |
Common failure: sizing the target from allocated on-premises CPU and storage. Measure actual CPU, memory pressure, read/write IOPS, throughput, latency, temporary files, WAL generation and concurrent sessions. Cloud limits are explicit; averages hide the peak that determines whether cutover succeeds.
2. Choose the operating model before the migration tool
| Target | Best fit | Trade-off |
|---|---|---|
| PostgreSQL on EC2 | OS access, unsupported extensions, custom agents or exact topology control | Your team owns patching, backups, HA, failover and capacity |
| Amazon RDS for PostgreSQL | Managed PostgreSQL with familiar engine behavior and reduced operations | No OS access or true superuser; validate every extension and administrative routine |
| Aurora PostgreSQL-Compatible | Fast storage growth, multiple readers and AWS-native availability patterns | Compatibility is not identity; benchmark plans, extensions, failover and cost against your workload |
Do not select Aurora because it sounds “more cloud.” Do not select EC2 only because it resembles the data center. Run a proof of concept using production-like volume and concurrency. The AWS PostgreSQL-on-EC2 migration guide explicitly positions EC2 for workloads that require full database and operating-system control.
3. Build the foundation first
Create the AWS Organization, workload accounts, IAM Identity Center access, centralized logs, budgets, tagging standard and guardrails before production data arrives. Design at least two Availability Zones, private subnets, route tables, security groups, DNS, KMS keys, Secrets Manager rotation and connectivity through Site-to-Site VPN or Direct Connect. Measure round-trip latency from the application to the future database; a database can be healthy while a temporarily hybrid application becomes unusable because every request performs dozens of cross-site round trips.
Model hybrid latency explicitly
If an application transaction executes 20 sequential database round trips and the hybrid link adds 18 ms of RTT, the network alone adds roughly 360 ms before query execution. Connection setup, TLS and DNS may add more. Move chatty application components with the database, reduce sequential calls, warm connection pools and test packet loss—not just bandwidth. Direct Connect improves predictability, but it does not remove distance.
4. Select the data movement pattern from downtime and risk
- Offline:
pg_dump/pg_restoreis transparent and dependable for smaller databases with an acceptable maintenance window. Time the restore, index creation, constraints andANALYZE, not just the dump. - Physical: base backup or streaming replication preserves engine-level fidelity, but depends on compatible versions and a target that supports the method.
- Online: AWS DMS or native logical replication performs a full load followed by change data capture (CDC), reducing downtime to the final synchronization and application switch.
For homogeneous PostgreSQL migrations, the AWS DMS workflow uses PostgreSQL-native mechanisms: pg_dump/pg_restore for full load and a publisher/subscriber model for CDC. Logical migration still needs explicit treatment of roles, grants, sequences, large objects, extensions, DDL changes and objects outside replicated tables.
Understand the CDC capacity equation
Replication catches up only when sustained apply throughput is higher than the source change rate. If the source produces 80 MB/s of logical changes and the target applies 100 MB/s, the theoretical recovery rate is only 20 MB/s. A 720 GB backlog then needs about ten hours in ideal conditions. Large transactions, target indexes, LOB handling, network jitter and validation work reduce that margin. Measure source-to-replication and replication-to-target latency separately so the bottleneck is visible.
DDL discipline during CDC: logical replication is not a schema migration service. Freeze or coordinate DDL, pre-create compatible objects, synchronize sequences immediately before opening writes, and verify that triggers and jobs do not execute twice.
5. Rehearse, validate and make rollback executable
Run at least one complete rehearsal with timing by phase. Validate row counts and checksums for critical tables, sequence values, constraints, permissions, job schedules and application smoke tests. Compare query fingerprints, execution plans, latency distributions, cache hit, I/O, locks, autovacuum and replication lag between source and target. Load-test with realistic data skew and connection-pool settings.
- Freeze nonessential DDL and confirm the change window.
- Verify CDC latency is stable and the target has no validation errors.
- Reduce DNS TTL in advance; stop writers or place the application in controlled read-only mode.
- Let replication catch up, record the final source position and synchronize sequences.
- Switch secrets/endpoints, run smoke tests and open traffic gradually.
- Keep the source intact and define the exact time and conditions after which rollback is no longer safe.
A rollback plan must say who decides, how writes made on the new target are handled, which endpoint changes back, and how long execution takes. “We still have the old server” is not a rollback plan.
Use explicit go/no-go gates
| Gate | Minimum evidence | No-go example |
|---|---|---|
| Data | Critical tables reconciled; CDC latency within threshold; sequences checked | Unexplained count difference or replication error |
| Performance | Critical journeys meet p95/p99 and resource headroom targets | Same SQL has an unreviewed plan regression |
| Resilience | Restore and failover exercised; application reconnect measured | Runbook assumes a manual step with no owner |
| Operations | Dashboards, pages, access, backup and escalation verified | Team cannot diagnose the target without source tooling |
6. Stabilize before optimizing
For the first days, watch saturation, query latency, plan changes, connections, WAL, replica health, storage growth, backup completion and failover behavior. Only then rightsize or purchase commitments. A short period of intentional headroom is cheaper than a failed cutover; permanent overprovisioning is not.
How PG Monitoring helps with this migration
PG Monitoring creates a technical control plane across the migration rather than appearing only after production moves. Before cutover it records query fingerprints, latency distributions, execution plans, connection pressure, table growth, vacuum health and replication behavior. During rehearsal and cutover it exposes the delta between source and target: which query changed plan, where wait time moved, whether CDC/replica lag is converging and whether the new pool is exhausting connections. After the switch it keeps the comparison window available while capacity forecasts and anomaly detection identify problems that a short smoke test cannot reveal.
Concrete deliverable: use PG Monitoring to produce a pre-migration baseline, a cutover health view and a post-migration regression report. That evidence gives the go/no-go owner something stronger than “the dashboards look green.” If you are planning PostgreSQL on AWS, talk to our team about a migration readiness and observability assessment.