PL/SQL & Oracle features
Migrating Oracle packages to PostgreSQL
Packages can combine APIs, state and business logic. Separate those responsibilities before deciding how each part should live in PostgreSQL.
Read the articleInsights
The difficult decisions are often nowhere near CREATE TABLE.
Practical articles on packages, PL/SQL, database links, Scheduler, Oracle-specific features, PostgreSQL/Aurora and the work required to turn a converted schema into an operable target.
PL/SQL & Oracle features
PL/SQL & Oracle features
Migrating Oracle Scheduler jobs to PostgreSQL
Jobs are part of the operating model. Capture schedules, dependencies and failure behaviour before choosing the target scheduler.
Read the articlePL/SQL & Oracle features
Replacing Oracle database links
A database link is more than a connection. Classify reads, writes, consistency and failure behaviour before choosing the replacement.
Read the articlePL/SQL & Oracle features
Migrating Oracle XMLTYPE to PostgreSQL
Treat storage type, XML queries and business processing as separate concerns: XMLTYPE is more than stored text.
Read the articlePL/SQL & Oracle features
Replacing Oracle UTL_FILE
PL/SQL file access affects privileges, operating procedures and error handling. Make the ownership change explicit.
Read the articlePL/SQL & Oracle features
Migrating Oracle Advanced Queuing
Define durability, acknowledgement, ordering and retry semantics before choosing the replacement technology.
Read the articlePL/SQL & Oracle features
Migrating Oracle materialized views to PostgreSQL
Do not migrate only the SELECT statement. Refresh behaviour, data age, availability and query patterns all matter.
Read the articlePL/SQL & Oracle features
Resolving Oracle synonyms during migration
Synonyms can hide schema boundaries and remote targets. Make the actual dependencies explicit before moving them.
Read the articlePL/SQL & Oracle features
Reassessing Oracle partitioning for PostgreSQL
Review partition keys, boundaries and maintenance processes. The Oracle design is not automatically the best PostgreSQL design.
Read the articleTarget architecture & AWS
Target architecture & AWS
Choosing PostgreSQL extensions for an Oracle migration
Extensions can close functional gaps, but availability, privileges, maintenance and exit strategy must be assessed first.
Read the articleTarget architecture & AWS
Designing a PostgreSQL target architecture for Oracle workloads
Treat schemas, roles, interfaces and operations as one target design before local fixes become permanent dependencies.
Read the articleTarget architecture & AWS
Modernising Oracle RAC: compare requirements, not product names
Evaluate availability, throughput and recovery separately. A PostgreSQL target needs its own operating and failure model.
Read the articleTarget architecture & AWS
Oracle on EC2, RDS for Oracle or Aurora PostgreSQL?
These are three different migration paths with different levels of change, operational responsibility and compatibility impact.
Read the articleTarget architecture & AWS
Building an Oracle migration strategy for AWS
Separate infrastructure relocation from an engine change. That makes sequencing, risks and dependencies much clearer.
Read the articleTarget architecture & AWS
Evaluating Aurora PostgreSQL as an Oracle target
Managed operations do not remove compatibility work. Business logic, supported features and application behaviour remain decisive.
Read the articleTarget architecture & AWS
Oracle on AWS: make cost assumptions explicit
Combine technical inventory with cost drivers. A useful business case depends on documented assumptions, not a single infrastructure price.
Read the articlePlanning & quality
Planning & quality
PostgreSQL partitioning after an Oracle migration
After choosing the partition model, define a repeatable lifecycle for loading, querying, archiving and maintenance.
Read the articlePlanning & quality
Validating PostgreSQL performance after an Oracle migration
Equivalent results do not imply equivalent runtime. Compare representative workloads and investigate measured bottlenecks on the target.
Read the articlePlanning & quality
Building a PostgreSQL migration roadmap
Turn findings into migration units: dependencies, pilot, testing and cutover in an evidence-based sequence.
Read the articlePlanning & quality
Oracle to PostgreSQL migration: approach and risk
Understand the source, choose a meaningful pilot, and validate data and logic before committing to an engine change.
Read the articlePlanning & quality
Modernising an Oracle database portfolio
Not every database needs the same path. Prioritise applications by changeability, risk and real modernisation value.
Read the articlePlanning & quality
Oracle modernisation: define the objective and success criteria
Clarify what problem should be solved before selecting a platform, then define how success will be proven.
Read the articlePlanning & quality
GCON-DB and Ora2Pg: different roles in an Oracle migration
Keep analysis, conversion and engineering judgement separate. The right tool combination depends on the task.
Read the article