This document discusses migrating from Oracle to PostgreSQL and EnterpriseDB. It outlines a 5 step process: 1) assess pain points and options, 2) evaluate PostgreSQL features like compatibility and cost savings, 3) plan a staged migration approach, 4) choose a deployment platform like virtualization or cloud, 5) ensure continuity with tools, training and support. Key benefits of migrating include running Oracle applications with no changes, lower costs, and no vendor lock-in. EnterpriseDB can help with assessments, migrations and ongoing management.

1. Migrate to Platform
of your choice
Migration  Transformation  Success
3/12/2019

2. Agenda
• Pain-points and what choices you have
• Why migrate to EDB Postgres?
• Assessment and Migration Strategy
• Migration and next steps
• How we can help you
2

3. The BIG Pain-Point

4. What choice do I have?
4
PostgreSQL

5. What EDB Postgres offers

6. Process Architecture – Much like Oracle!
• Reliable without
compromising on
performance
• Scalable
• Ensures
performance (data
read-write caching)
• Conforms with ACID
transaction model

7. • Run applications written for Oracle
virtually unchanged
• No need to re-train Oracle DBAs and
developers
• Support for PL/SQL language and OCI
interoperability
• Replication for easy sharing of data
• Dramatic Cost Savings
• No Vendor Lock-in
Oracle Compatibility

8. EnterpriseDB Product Overview

9. How to go about Migration?

10. Step-1: Planning
Planning and Identification

11. Plan a Staged migration
50 Apps
Pool
Days/App
# of Apps
Net Savings
3yr (Net) ROI
50% 30% 20%
20 Days 40 Days 60 Days
25 Apps 15 Apps 10 Apps
$3.7 Million $2.0 Million $1.2 Million
140% 109% 84%

12. Iterative and Agile approach
Find the Sweet Spot
Prioritize and
Plan Migration
Build the Team
Migrate Deploy

13. Step-2: What are the risks?
Assessment and Feasibility

14. Good to Start with
• Developed using open standards
• Open standard connections
• Not much dependent on server
side code – stored procedures etc
• Vendor already supports Postgres
or EDB Postgres
• No RAC scalability requirement
• No need of flashback
Don’t choose
• Uses proprietary connection
method e.g. tnsnames
• Heavily dependent on stored
procedure
• Multiple dblink dependencies or
dependents
• Has dependencies on other
applications/databases
What applications to start with?

15. • How easy will it be to perform the migration?
• What are the risks?
• Will all my server side code (Stored procedures) work fine?
• Is my application compatible?
• How much testing effort will be needed?
Migration Assessment

16. Sample Assessment report
SCHEMA OBJECT_TYPE
COUNT
OF
OBJECTS
IN
ORACLE
COUNT OF
VALID
OBJECTS AT
ORACLE
OBJECT
MIGRATED
WITHOUT
ANY
CHANGE
OBJECT
MIGRATED
WITH
MINOR
CHANGE
OBJECT
MIGRATED
WITH MAJOR
CHANGE OR
REWRITE
COMPATIBIL
ITY IN %
ALL-SCHEMAS
TABLES 519 519 519 0 1 100
TEMPORARY
TABLE
1 1 0 1 0 100
VIEWS 3 3 3 0 0 100
TRIGGERS 49 26 21 0 5 100
PACKAGES 26 19 19 0 0 100
PROCEDURES 1649 1452 1329 0 123 100
FUNCTIONS 26 24 20 0 4 100
SEQUENCE 293 293 293 0 0 100
INDEX 894 894 894 0 0 100

17. Step-3: Which platform
should I go for ?

18. Deployment Platform of your choice
18

19. Container Deployment
19
• Data persistence
• Provisioning in seconds
• High Availability
• Scalability

20. Virtualization
20
• Reduced Hardware Costs
• Quick Server deployment
• Energy cost saving
• Better resource utilization

21. Bare Metal Deployment
21
• Full control on server resources
• Highly secure environment
• Best possible performance
• Customization

22. Cloud Deployment
22
• Reduced infrastructure and
maintenance costs
• Scalability
• Business continuity
• Automatic updates
• Flexibility

23. Step-4: Keeping the lights on!
DBA tools, training and continuity!

24. • Performance
Monitoring Dashboards
• Capacity Manager
• Postgres Expert
• Alert Management
• Browser based console
and dashboard
• Audit Manager
• Team Support
• Distributed Architecture
• Convenient Access
PEM For DBAs: Centralized Tool

25. • Training provided by certified trainer
• Periodic health checks
• Managed DBA service
• On-call remote DBA pack
• Dedicated Technical Account Manager
• Solution Architecture – extension to your
Enterprise Architecture Team
Training and operational support!

26. More Migration
• Identify more workloads
for migration
• Assessment
• Planning
• Migrating
• Operations
New workloads
• Adopt Postgres as an accepted
stack
• Standardize the deployment
template
• Identify solutions that are
compatible with Postgres
• New solutions prefer Postgres
• Automate the deployment
template
What’s next?

27. You need a solutions partner in this journey!
27
Over 20 successful migration
projects and over 100 migration
assessments
Over 100 different deployments
and helping customers with
automated deployment
Training and Managed Services
Team of certified and
experienced Database
professionals with the right
mix of application
understanding
Experience in various
different replication
topologies

28. Thank you!