Oracle to PostgreSQL Migration on AWS - Technical Guide with MAP Funding

This guide is written for mid-market companies, enterprise IT, and public sector bodies across Europe and the US – organisations running multiple Oracle instances with complex PL/SQL logic that need to migrate without business disruption. We’ve delivered these projects for financial services firms in the City and Frankfurt, healthcare providers bound by NHS Digital standards, and Mittelstand manufacturers modernising legacy ERP backends.

If you need a broader AWS migration overview (not database-specific), see our complete AWS cloud migration guide.

Why organisations leave Oracle for PostgreSQL

Oracle licensing costs – the real scale

For a mid-size deployment running two such servers, you’re looking at north of $400K per year in licensing alone – before hardware, DBAs, or data centre costs. Aurora PostgreSQL db.r6g.2xlarge (8 vCPU, 64 GB RAM, Multi-AZ) delivers comparable performance at ~$1,400/month = $16,800/year. No user limits. No audit exposure.

Oracle LMS audits – the single biggest trigger for migration decisions

Oracle License Management Services (LMS) audits are ruthless and increasingly common – particularly targeting organisations that have:

• Virtualised their environment (VMware) without purchasing full-rack licensing
• Run Oracle Standard Edition on servers with >2 sockets
• Deployed RAC or Data Guard without the corresponding option licence

The typical outcome? A compliance demand of $500K–$2M+ in back-payments. We’ve seen UK financial services firms hit with seven-figure demands after VMware sprawl went unchecked. German Mittelstand companies face similar exposure, often triggered by Oracle’s push to audit ahead of contract renewals.

Migrating to PostgreSQL removes Oracle’s audit leverage entirely. No licence to be non-compliant with.

Vendor lock-in and inflexibility

• Oracle licences per-processor – scaling up doubles your costs overnight
• No consumption-based pricing (unlike Aurora PostgreSQL, which bills per-second)
• Oracle on AWS still requires BYOL – you’ve moved to the cloud, but the licensing headache follows you
• No native integration with AWS IAM, CloudWatch, or Secrets Manager without additional configuration layers

PostgreSQL – why the timing is right

PostgreSQL has matured dramatically. Version 16 handles table partitioning, parallel query execution, logical replication, and JSON/JSONB natively – capabilities that used to be Oracle’s moat.

On AWS specifically:

• Aurora PostgreSQL delivers 3-5× standard PostgreSQL throughput with automatic failover and up to 15 read replicas. It’s a managed service – patching, backups, and HA are handled for you.
• Native ecosystem integration – IAM database authentication, automatic secret rotation via Secrets Manager, Performance Insights for query-level observability
• Zero licence cost – you pay for compute and storage, nothing else

For regulated industries (FCA in the UK, BaFin in Germany, or SEC-registered firms in the US), Aurora’s compliance certifications (ISO 27001, SOC 2, PCI DSS, C5 for DACH markets) mean you’re not trading Oracle compliance for a gap elsewhere.

Oracle vs PostgreSQL – key technical differences

Data type mapping

PL/SQL vs PL/pgSQL – key syntax differences

Oracle features without a direct equivalent

Step-by-step migration – 8-phase process

AWS tools for Oracle → PostgreSQL migration

AWS Schema Conversion Tool (SCT)

SCT analyses your Oracle schema and generates equivalent PostgreSQL DDL plus PL/pgSQL procedures. Think of it as the first pass – it handles the straightforward conversions so your engineers can focus on the hard parts.

It generates a colour-coded Assessment Report: green means auto-converted, amber means you’ll need to tweak it, red means someone needs to sit down and think through the logic. In our experience, 60-85% of objects land in green or amber territory.

Where SCT falls short: PL/SQL packages get flattened (you lose encapsulation), CONNECT BY hierarchies need manual CTE rewrites, and some Oracle analytic functions require a human eye. But for the price (free – it’s part of the AWS toolkit), it’s an essential starting point.

AWS Database Migration Service (DMS)

DMS moves the actual data. It supports one-off full loads and, more importantly, continuous replication via Change Data Capture (CDC) – which is how you achieve near-zero downtime on the final cutover.

A few things to get right on the Oracle side: supplemental logging must be enabled, you’ll need Binary Reader or LogMiner access, and the replication instance should be sized at roughly 1 vCPU per 50 GB of data being loaded (or per 100 tables under CDC).

On the PostgreSQL target, set up a logical replication slot for Multi-AZ configurations and flip session_replication_role to replica during the initial load to avoid trigger interference.

Running cost is modest – roughly $0.018/h per vCPU on the replication instance, plus data transfer.

ora2pg – the open-source option

A Perl-based tool that handles schema and data conversion without any AWS dependency. Useful for smaller databases, on-premise PostgreSQL targets, or situations where you want fine-grained control over every conversion decision.

It’s less suitable for large enterprises with hundreds of stored procedures (SCT’s heuristics are better at scale) and it doesn’t support CDC – so you’ll still need DMS or a custom solution for live replication.

How AWS MAP funds your Oracle → PostgreSQL migration

What MAP actually is

The Migration Acceleration Program is AWS’s way of subsidising your move off competing platforms. It’s not a discount on AWS services – it’s funding that covers your migration partner’s fees (assessment, engineering, testing, cutover). Three phases, each with its own funding envelope:

The Oracle-specific MAP track

AWS runs a dedicated MAP track for Oracle database migrations with a larger budget than the standard programme. This isn’t widely advertised, but it exists because AWS has a strategic interest in moving Oracle workloads onto its platform.

What the Oracle track adds beyond standard MAP:

• Additional credits to cover tooling, extended testing, and team upskilling
• Higher funding ceilings for complex multi-database estates
• “Windows of Opportunity” bonuses when you migrate before your Oracle renewal date (Oracle renewals are leverage points – AWS knows this)

Who qualifies

The bar isn’t as high as you might expect:

• Active Oracle environment (on-premise, co-located, or running on EC2 with BYOL)
• Minimum ~$50K in partner engagement value (this rules out trivial single-instance migrations, but most enterprise scenarios clear it easily)
• Target must be an AWS-native database service (Aurora PostgreSQL or RDS PostgreSQL)
• You need a certified MAP partner to submit the application. We handle this end-to-end.

What this looks like in practice

On top of the partner fee coverage, you’ll typically receive 1-3 months of AWS infrastructure credits for the target environment, access to AWS Solution Architects during the project, and (for the largest engagements) direct involvement from AWS Professional Services.

DACH and UK compliance context

For organisations in regulated industries, MAP funding doesn’t change your compliance obligations – but Aurora PostgreSQL’s certification stack makes it easier to meet them:

• UK (FCA-regulated): Aurora supports data residency in eu-west-2 (London). ISO 27001, SOC 2 Type II, and PCI DSS compliance certifications via AWS Artifact.
• Germany/Austria/Switzerland (BaFin, FINMA): C5 attestation (BSI Cloud Computing Compliance Controls Catalogue) covers Aurora PostgreSQL. Data stays within eu-central-1 (Frankfurt).
• GDPR/UK GDPR: Standard contractual clauses built into the AWS Data Processing Addendum. No data leaves the EU/UK unless you explicitly configure cross-region replication.

The qualification process

What we need from you to get started:

1. Inventory of Oracle databases – instance count, sizes, rough procedure counts
2. A business case outline – even back-of-envelope licensing savings vs migration cost
3. Your Oracle renewal timeline – this determines urgency and can unlock bonus funding
4. A conversation – we submit the MAP application on your behalf and manage the funding lifecycle through to completion

Most common Oracle → PostgreSQL migration challenges

1. Stored procedures with business logic

Problem: Enterprise Oracle databases have hundreds of PL/SQL procedures implementing business logic (calculations, validations, workflows). SCT converts 60-70% automatically; the rest requires manual work.

Solution:

• Prioritise: identify procedures actually called in production (Oracle AWR report)
• Rewrite, don’t translate: PostgreSQL has better window functions, CTEs and array operations – use them instead of mimicking Oracle
• orafce extension: temporary bridge for Oracle-specific functions (NVL2, DECODE, LPAD with Oracle semantics)
• Per-procedure testing: every converted procedure must pass testing with Oracle results as baseline
• AI assistance (Amazon Q, Copilot): LLMs convert PL/SQL → PL/pgSQL with target schema context. Engineers verify and refine rather than writing from scratch. Reduces manual conversion effort by 40-60% and eliminates common syntax errors

2. Post-migration performance

Problem: Queries that ran in 50ms on Oracle can take 5s on PostgreSQL. Different optimiser, different statistics, different indexes.

Solution:

• pg_stat_statements – identify the slowest queries
• EXPLAIN (ANALYSE, BUFFERS) – compare execution plans
• Additional indexes: PostgreSQL benefits from partial indexes, expression indexes, covering indexes
• Tune random_page_cost (for SSD: 1.1 instead of the default 4.0)
• Connection pooling: PgBouncer in transaction mode (Oracle handles thousands of connections natively; PostgreSQL needs a pooler)

3. Oracle-specific features without a direct equivalent

Problem: CONNECT BY, MODEL clause, MERGE with advanced logic, autonomous transactions.

Solution by feature:

4. DBA team mindset shift

Problem: Teams accustomed to Oracle (AWR, ASH, Enterprise Manager) need to learn new tooling.

Solution:

• AWS Performance Insights = Oracle ASH (Active Session History) equivalent
• pg_stat_statements = Oracle V$SQL equivalent
• pgBadger = Oracle AWR Report equivalent
• 2-3 day training for the DBA team (covered by MAP budget)

5. External integrations

Problem: Reporting systems (BI), ETL tools (Informatica, SSIS, Talend) and other applications connect directly to Oracle.

Solution:

• Assessment phase identifies ALL connections to Oracle (netstat, AWR, Oracle auditing)
• Cutover plan includes switching every integration
• Parallel run: DMS maintains Oracle in read-only as a safety net for systems that can’t switch immediately

Timeline and costs for Oracle → PostgreSQL migration

By database size and complexity

Costs above factor in AI-assisted code conversion (Amazon Q Developer, Copilot). Without AI tooling, the manual conversion phase would take 40-60% longer – particularly visible in “Complex” and “Enterprise” scenarios where stored procedure work dominates the budget.

What affects timeline

Post-migration savings – ROI

Typical organisation with 2 Oracle EE instances (2-socket each):

At a migration cost of ~€70,000 after MAP funding – ROI in under 4 months.

Frequently asked questions

Next steps – free migration assessment

Every Oracle → PostgreSQL migration starts with assessment. We analyse your Oracle estate (schemas, PL/SQL complexity, data volumes, integration points) and come back with:

1. SCT conversion report – what converts automatically, what needs engineering time
2. Cost and timeline estimate – realistic ranges, including MAP funding projections
3. Architecture recommendation – Aurora vs RDS, Multi-AZ, read replicas, pooling strategy
4. Cutover plan – how to switch with minimal business disruption

We’ve delivered Oracle exits for regulated firms in London, Frankfurt, and across the Nordics. Whether you’re facing an Oracle renewal in six months or an LMS audit demand letter on your desk, the first step is understanding what you’re working with.

Considering leaving Oracle?

Book a free 30-minute call. We'll assess your migration complexity and check whether your project qualifies for AWS MAP funding (typically 70-80% of costs covered).

Book a migration assessment