Migrating Oracle Databases to
Open Source Technologies
AUTHOR
John Schulz
Principal Consultant, Microsoft MCM & MVP
V01-012021-HW
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 2
Introduction
Some Oracle customers today are beginning to weigh other options,
often for a host of reasons including Oracle’s license and contract
restrictions, customer audits, concern about eventually being locked
in, and high support costs. One option they may choose is to migrate to
open source databases (OSDBs) with much less restrictive licenses and
no license fees. In this document, we will review the options current
Oracle users have to migrate to open source database technology.
We will start with what Oracle database technologies are currently in
use, compare those to the many Open source options available, and
then review how best to get there, including an evaluation of many of
the robust tools available to help.
All OSDBs offer a subset of the capabilities and feature options
of the Oracle database, so first reviewing the Pythian white paper
“Considerations For Converting From Oracle To Other RDBMS Platforms”
is highly recommended. This will help ensure that the options, features,
and non-functional capabilities unique to Oracle are either not used or
are a palatable loss.
No matter which Oracle database technologies are in use, there are
three general approaches to migrating to an OSDB:
1. Direct migration
Migrate the schema into the new OSDB format, modify the data
manipulation language (DML) to work with the new OSDB technology,
and copy over the data to the new database. This approach, while
straightforward, is usually only practical for a small subset of OSDB
technologies and in some cases not even for those.
2. Refactor the application and re-write for the new OSDB
technologies chosen
This approach, while daunting, is often the better one as it allows
for a new application which eliminates technical debt and improves
operability, including scaling and availability and faster features to
market. It is also a major undertaking, and the return on investment is
likely to be years away.
3. Find the right off-the-shelf application which supports the
OSDB of your choice.
The application itself may be either proprietary or open-source.
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 3
Oracle Single-Instance vs RAC vs Exadata
Oracle offers several products, and Oracle Database can roll out
several specific feature sets to suit certain workloads. The kind of
workload will, at least in part, drive the final decision as to which OSDB
technologies are good use cases for the migration.
Single-Instance Oracle Databases
Many Oracle databases run on a single host, optionally with one or
more standby databases providing disaster recovery (DR) , backup or
query off-loading. These configurations are typically used by most small
to medium-sized businesses for the majority of their database traffic.
The workloads tend to vary extensively and can include transactional,
content management, business intelligence, and data warehouse use
cases.
Oracle RAC
This is Oracle’s premier high-volume transactional engine, designed for
high availability (HA) via horizontal scalability. It operates as a cluster
of computers with shared storage designed to scale beyond a single
system while offering HA without replication. For DR, RAC installations
also replicate to one or more standby RAC (or non-RAC) databases as
part of Oracle’s Maximum Availability Architecture (MAA).
Exadata
Exadata is Oracle’s hardware-based product (with unique hardware and
software capabilities, not replicable outside of the Exadata platform)
designedto support large data warehouse applications and high volume
OLTP applications. It is the only Oracle Database product that supports
on-disk column store technology.
Business Requirements
Before thinking about which database technology to which you might
want to migrate, you should evaluate your business requirements.
Knowing what your real business requirements are will help you select
the best OSDB technology in terms of the database itself, along with
the way you’ll configure it and what tools you’ll use.
High Availability (HA)
We all want our databases to be highly available. But there is
always a cost to keeping a database up 24X7, 365 days a year with
99.9999% uptime. Understanding your real needs will help identify
what technologies you should investigate and how you might want to
configure them.
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 4
Disaster Recovery (DR)
What are your DR requirements? Will you need an active disaster site
able to seamlessly take over from the primary? Will a passive backup
be acceptable? Can you just rebuild from the data you have in another
database, meaning the cost of DR may not even be justified?
Global Data Distribution
Will your database need to be available globally, with data replicated
between nodes more or less transparently? Or will you want a single
central database with geographically distributed copies? Or maybe you
just want to store customer data in the closest datacenter, and then
safely replicate it in just one other place.
Rapid Response to Changing Requirements
Will your database need to support rapid changes due to fluctuations in
market conditions? To take advantage of new business opportunities?
Or will the database structure be more or less static, changing only
slightly over time?
Regulatory Requirements
What are your regulatory and compliance requirements? This matters a
good deal. Depending on what kind of data you have, one or more of the
OSDB databases may not meet your needs – or you may need additional
software to make it work. If you are thinking of migrating to a public
cloud, is the cloud or the database offering in the cloud certified and
able to meet your compliance requirements?
Continuous Availability during Migration
When it comes time to migrate to the new database technology, will
users of the source Oracle Database and the target OSDB database(s)
require continuous uninterrupted access to all the data? Will access to
most of the data be acceptable? Will it be okay for applications to be
down? If so, for how long?
Migrating data in a batch inside of a downtime window is clearly the
easiest and simplest route but is not always acceptable. What is your
requirement?
Migration Approaches
We mentioned up top that there are three general options when
migrating from your Oracle Database. However, within those three
options are many additional considerations.
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 5
Direct Migration
With direct migration, you will need to evaluate the existing schema and
SQL code, especially any stored program code (PL/SQL). There are a
number of tools available to help in this effort, such as Ora2Pg and AWS
Database Migration Services (DMS).
After determining what features and functions are missing or just
named differently, you will need to convert the schema and code. In
many cases, this means changing at least some program logic. If your
code used an object-relational mapper (ORM), this may prove relatively
painless. If not, and if there are many lines of code to change, this could
be a major effort.
Once you complete the analysis and translation phases, you will next
need to set up a test environment to validate the schema and code
changes. After all these considerations are carefully weighed, it’s finally
time to migrate the data. There are two approaches you can take:
1. Batch
Shut down the existing application, dump the data, and restore it to
the new database. This can be done through utilities like Ora2Pg or
AWS DMS. It also can typically be done by performing a SQL-level
dump from Oracle, suitably modifying it, and restoring it into the new
database. This approach is generally straightforward and if downtime is
acceptable, it’s often the simplest approach
2. Online heterogeneous replication
In this case, you bring up both databases, load a copy of the production
data into the new database, and start replicating from the existing
Oracle Database to the new one. Oracle Golden Gate can target many
databases and do this for you. You can also use AWS DMS (if you are
migrating to AWS). There are also numerous other third-party options,
with one of the most versatile being Kafka. In that case, you use an
Oracle sink to write to Kafka, which can be done via Golden Gate.
You must then use a source for your database to write to your new
database. This approach allows for transformation work to take place
between the source and destination, which is sometimes useful.
Method two is the most common since it requires no downtime and can
sometimes accommodate a slow roll migration with replication going in
both directions. But it is also much harder to implement.
Refactor and Rewrite
For many large, complex databases using many Oracle-specific features
and large amounts of stored program code, this is the correct approach.
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 6
It also provides additional benefits:
• Eliminate Technical debt – Old code and workarounds to resolve
compatibility with old features make code fragile and difficult to fix
or enhance
• Move to a modern microservice framework – Allows developers to
create new features faster with generally lower error rates
• An updated codebase is a golden opportunity to implement data
governance best practices from the ground up
When taking this approach it is common to break a single monolithic
database into multiple components, including:
• Microservice transaction and configuration stores – Transaction
stores going to a relational database and configuration data in a
document store
• Event stores – Not really addressed here but Elasticsearch, Solr, and
Kafka can often fill this requirement. Kafka can be used as a buffer to
Elasticsearch or to queue requests between microservices
• Data warehouse/Data lake – For analytic processing of column stores
like MariaDB AX, Spark with Parquet, or Clickhouse
Once the redesign and refactoring is done – which will likely take a year
or more – migrating to the new database will require a replication as
described in the direct migration plan above, ideally using the Kafka/
Sink/Source approach.
Migrate to a New Application
This is a subject worthy of its own paper, so we won’t talk about this in-
depth beyond pointing out that you will still need to get your data from
the old system to the new one, and you will need a plan. Some software
vendors will help, but many will leave it all up to you.
Where to Migrate
In Place
In this scenario you migrate to a server in the same location. If your
Oracle Database is in your own data center or a colocation center, you
simply put the new OSDB server in the same place.
If your Oracle server is running in a private cloud such as VMware,
OpenStack or another cloud, you put your new database there. And if
your Oracle Database is already running in a public cloud, you put the
new database in a public cloud.
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 7
The Cloud
If you’re considering migrating from Oracle to another database, it’s
much more likely in today’s world that you’re also thinking about
migrating to one of the public clouds.
If that’s the case, you have two additional choices:
• Migrate to the cloud using their infrastructure-as-a-service (IaaS)
tools, for example creating virtual machines (VMs) or containers
which will run much the same as if your database were running on
regular hardware.
• Migrate to the cloud vendor’s database-as-a-service (DBaaS) offering
for your chosen database, which allows the cloud offering to take
care of most day-to-day operational tasks.
The Cloud: IaaS
Why stick with IaaS when you can use DBaaS? It depends on your needs
and the offerings available from the vendor, including:
• The OSDB technology you’ve chosen is not available from the vendor
• To make their DBaaS offering point and click and manageable for
them, the cloud vendor may not support one or more of the features
you need
• The configuration options you need for good performance is not
available
• The DBaaS high availability implementation does not meet your needs
• You are a control freak and don’t like the idea of a DBaaS service
doing things that are out of your control. For example: AWS regularly
performs minor upgrades to their RDS service with little warning, and
have been known to force upgrades when a database version reaches
end of life.
The Cloud: DBaaS
If the cloud vendor offers a DBaaS solution, then there are several
compelling reasons why it may be a good choice:
• Point-and-click provisioning
• Built-in HA
• Automatic backups
• Automatic recovery from backups
• Point-and-click replica creation
• Point-and-click failover
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 8
• Near-zero or zero downtime hardware upgrades and downgrades
• Auto-scaling (not available for all DBaaS offerings)
Most database users find the benefits of DBaaS offerings very
worthwhile.
OSDB Technologies
There are many OSDB database technologies to consider. Each has its
own history and design characteristics that make it best for certain
workloads. Below, we will go over each at a fairly high level.
Rank Score
DBMS When to use
Jul 2020 Jun 2020 Jul 2019 Jul 2020
1 1 1 Oracle 1340.26
Very popular, but not as close to
2 2 2 MySQL 1268.51 Oracle as PostgreSQL. Good for
most use cases.
Popular Oracle migration Target.
4 4 4 PostgreSQL 527 Good for transactional and content
store applications.
Good for redesign efforts with
5 5 5 MongoDB 443.48
content stores.
Good for redesign efforts with high
10 10 10 Cassandra 121.09 volume writes and time series
data.
12 12 13 MariaDB 91.13 MySQL with PL/SQL support.
Good for redesign efforts with
23 21 18 HBase 48.66 high volume writes to a key values
store.
Good for redesign efforts with a
34 34 35 Spark SQL 18.4
heavy analytics component.
Amazon
45 45 52 8.64 PostgreSQL or MySQL DBaaS
Aurora
Good for redesign efforts with a
65 67 86 ClickHouse 5.31
heavy analytics component.
Distributed scalable PostgreSQL
68 74 89 CockroachDB 4.97 dialect but not as mature. Good for
transactional and content stores.
Distributed scalable PostgreSQL
159 166 213 YugabyteDB 1.04 dialect but not as mature. Good for
transactional and content stores.
Source data: https://db-engines.com/en/ranking July 2020
db-engines.com score definition: https://db-engines.com/en/ranking_
definition
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 9
PostgreSQL1
If you are migrating directly from Oracle to an opensource database,
PostgreSQL should be given serious consideration. Due to the
similarities in dialect between Oracle and PostgreSQL, especially
between PL/SQL and PostgreSQL stored procedures, most successful
migrations from Oracle directly to an OSDB have been to PostgreSQL
Postgres was created as a research project at the University of
California, Berkeley as a successor project to the Ingres project –
hence the name, which essentially means post Ingres. The project was
initiated in 1985, although it did not get SQL added to it for another
decade.
PostgreSQL is one of the oldest popular OSDBs, along with being the
most developer-friendly. It is very feature-rich and its SQL and stored
procedure language dialects are very similar to those of Oracle.
But it doesn’t include all Oracle’s features and capabilities, meaning
server-side code translations may not be seamless.
Until recently the PostgreSQL community was fairly insular, slow to
develop and, like Oracle, the technology was hard to install and its
learning curve was steep. But that’s changed recently, very likely due
to increased interest due to the similarity of its SQL dialect to that of
Oracle.
PostgreSQL has now become the default choice for many users
migrating directly from Oracle to an OSDB. But PostgreSQL’s surface
similarities to Oracle can become a trap if you are not careful. One
common example is Oracle’s number data type, which corresponds
to PostgreSQL’s numeric data type almost exactly. However, Oracle
optimizes its storage depending on the size and required precision.
PostgreSQL stores all numeric columns in exactly the same way, which
can become inefficient both in terms of space and performance.
PostgreSQL is designed from the ground up as a transactional engine.
It shines in transaction processing applications, does well for content
management, and special proprietary branches have even been created
for data warehousing applications. Amazon RedShift and Green Plumb
are examples of data warehousing implementations.
PostgreSQL database replication is built into the server. HA is managed
through external utilities to route traffic to replicas and manage
the failover process, while sharding/horizontal scaling of writes for
PostgreSQL requires third party tools.
1 https://en.wikipedia.org/wiki/PostgreSQL
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 10
MySQL and MariaDB2
MySQL is the most widely used OSDB in the world today, and is second
to only Oracle itself overall. Born in the 1990s as an easy-to-use
database for the burgeoning internet, it was originally very small, easy
to install, and with a limited feature set. Nowadays it is generally still
much simpler to operate than both Oracle and PostgreSQL, but its
SQL dialect is poorer, although MySQL 8 and MariaDB 10.5 both have
significant new language features that narrow the gap.
If your database and application are fairly straightforward and you are
not using Procedural Language for SQL (PL/SQL), migration to MySQL
is a viable option. You will find a lot more DBAs available for something
like this than you would with PostgreSQL.
If you do have some PL/SQL, the MariaDB branch of MySQL supports
the Oracle PL/SQL language.
MySQL and the MariaDB branch, through their support of multiple
storage engines, can and do support a very wide array of workloads
including transactional, content management, business intelligence (BI),
and moderate-sized data warehouses.
MongoDB3
MongoDB does not support SQL, is in no way relational – in fact,
MongoDB does not require a schema of any kind for many use cases. A
developer simply opens a connection and specifies which database and
collection (such as a table) to write or read from.
MongoDB has limited support for transactions and should not be
considered a transactional database. MongoDB is an excellent choice
for content management and the storage of plain text. MongoDB also
has an excellent aggregation platform which makes it a good choice for
some BI workloads. It is also great as a persistent object store because
its native storage format is JSON.
MongoDB, first released in 2009, was created by a company not
originally interested in databases at all. Its developers wanted to store
data in a convenient way for later retrieval, so they created their own
database using a modified JSON format (JSON allows a developer
writing code in an object-oriented language to easily store and retrieve
objects). Although MongoDB was branded a document store given its
similarity to databases of this type, it could also have been called a
simple object store, with the exception that it does not support some
object features such as inheritance.
2 https://en.wikipedia.org/wiki/MySQL
3 https://en.wikipedia.org/wiki/MongoDB
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 11
It wasn’t long before MongoDB became more popular than the
developer’s original product, so they changed the name of the company
and became a database company.
MongoDB has built-in replication in the form of replica sets and HA
through the MongoDB library, and a supplied router called mongoS. HA
is a basic feature of the product.
MongoDB also has built-in sharding, allowing it to scale writes across
multiple replica sets. The sharding feature also supports geographic
routing of data to local replica sets.
Although MongoDB is not a candidate for direct migration from Oracle,
it’s often very successfully used in refactored migrations.
Cassandra4
Not being a relational database and having no support for ACID
transactions, Cassandra is, like MongoDB, also not a candidate for direct
migration. Instead, it’s a good potential choice for a write-intensive
redevelopment project (for weblogging or internet of things (IoT)
applications, for example).
Initially released in 2008, Cassandra was spawned from a marriage
of Google’s Bigtable and Amazon DynamoDB. It initially did not have
a query language, just an API. Later, when the Cassandra community
realized that most Cassandra use cases seemed to fit a subset of SQL,
they invented the Cassandra Query Language (CQL).
Cassandra is designed to handle very high volumes of writes with a
moderate level of reads. It is not relational, despite CQL looking much
like SQL. Cassandra was created from the ground up to be sharded –
the Cassandra community calls it partitioned – highly available and
geographically distributed. It is frequently used for IoT applications and
time-series databases (TSDBs). Due to its inherently distributed nature,
it works well with Spark, which is what most use to collect analytic
data from Cassandra.
By its basic design, Cassandra replicates, locally and geographically,
in an asynchronous fashion. There are no primary/replica nodes in a
Cassandra cluster. All nodes are equal. Cassandra is often referred to
as eventually consistent – meaning, you can write to the database and
then read back a different value if care is not taken to ensure a quorum
of replicas are queried.
4 https://en.wikipedia.org/wiki/Apache_Cassandra
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 12
Spark5, Hadoop6, and HBase7
Spark and Hbase do not support ACID transactions and are not
designed to support transactional workloads. They cannot be
considered direct replacements for an Oracle database. Spark can,
however, be used to replace the analytics features of Exadata.
HBase performs well as a large-volume key-value store. These
technologies are good candidates for a redevelopment project where
an Oracle Analytics workload is offloaded to an OSDB. Spark, Hadoop,
and HBase are three very different but related technologies used for
processing massive amounts of data.
Hadoop runs the underlying framework of servers used by HBase and
Spark. It is exposed to HBase and Spark as the Hadoop FileSystem
(HDFS) and consists of a distributed network of servers running in a
single data center. It is never distributed geographically. However, there
are third-party proprietary tools that will replicate Hadoop clusters
geographically.
Spark is a distributed query engine designed to perform data
warehouse-style queries and data transformations. It supports standard
SQL with extensions and features a rich developer API, which goes
well beyond what can be done with SQL. Spark is not in any way
transactional. Spark should be thought of as a query engine and ETL
server.
HBase is a direct, open-source implementation of Google Bigtable.
It supports very wide rows that can handle millions of columns. Like
Cassandra, it can support very high volumes of writes with moderate
read rates. It gives the Spark Hadoop environment a fast way to access
specific data, and often used as a content store to keep dashboards up
to date.
Clickhouse8
Clickhouse is not transactional. It works best when data is loaded in
large batches and is intended for queries passing through billions or
trillions of rows. Clickhouse should be considered only to replace the
analytics functions of an Oracle, likely Exadata, database.
Initially released in 2016, Clickhouse is a distributed column-store
designed to support massive data volumes in a data warehouse. It uses
an extended SQL dialect which includes the ability to handle complex
nested columns.
5 https://en.wikipedia.org/wiki/Apache_Spark
6 https://en.wikipedia.org/wiki/Apache_Hadoop
7 https://en.wikipedia.org/wiki/Apache_HBase
8 https://en.wikipedia.org/wiki/ClickHouse
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 13
CockroachDB⁹
CockroachDB operating as a fully functional relational and ACID-
compliant transactional database may be a good target for less complex
Oracle migrations, where built-in global replication and HA are attractive
options.
Initially released in 2014, it is an open-source project inspired by
Google’s well-known research paper on its Spanner database. It is
designed from the ground up as a relational distributed database
at both data center and global levels. It is also designed to be self-
replicating and highly available.
CockroachDB, like Google Spanner (not open source), is fully relational
and fully supports ACID transactions. If you want to establish a global
presence with a fully relational OSDB, CockroachDB might be a good
choice. The SQL dialect it supports is somewhat limited if you are
coming from Oracle, however, so it’s unlikely to suit a direct migration.
CockroachDB uses the PostgreSQL dialect and wire protocol, allowing
existing PostgreSQL client applications to read and write to the
database without having to change the client code. It also has several
other features:
• Horizontally scalable for writes
• HA is a basic part of the design
• Global replication
Yugabyte10
As in the case of CockroachDB, Yugabyte as a relational and ACID-
compliant transactional database is suitable for some less complex
Oracle migrations, thanks in part to built-in global replication and HA.
Plus its Cassandra API makes it a good fit for heavy write workload
applications like IoT and web-logging. Yugabyte is another open-source,
Spanner-like distributed relational database – but with a twist. Because
it’s multimodal, Yugabyte client applications can access the database
via the PostgreSQL dialect and client libraries, or using CQL and client
libraries.
The primary attractions to Yugabyte are:
• Horizontally scalable for writes
• HA is a basic part of the design
• Global replication
• Multimodal
9 https://en.wikipedia.org/wiki/Cockroach_Labs
10 https://en.wikipedia.org/wiki/YugabyteDB
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 14
On the Cloud
If your intent is to use IaaS to deploy in the cloud, please see the
above database choices. You can deploy any of them by using VMs or
containers in the cloud.
If you are looking for the cloud service to take on significant operational
complexities, then each of the major cloud vendors also has a DBaaS
offering that may work for you.
CloudSQL11
Google’s CloudSQL offers support for standard MySQL and PostgreSQL
Amazon RDB and Aurora12
AWS offers both RDS and Aurora database services. RDS supports:
• MySQL 5.5, 5.6, 5.7 and 8.0
• MariaDB 10.0-10.4
• PostgreSQL 9.6,10,11 and 12
• Aurora for MySQL 5.6 and 5.7
• Aurora for PostgreSQL 9.6, 10 and 11
Aurora for MySQL and PostgreSQL are the standard MySQL and
PostgreSQL releases, with the storage backend re-written to support
a very different clustering technology from standard open-source
releases. While technically proprietary, these changes do not affect
the application code, only performance and some minor differences in
operation.
Azure Open Source13
Azure offers both PostgreSQL and MySQL services as DBaaS.
11 https://cloud.google.com/sql/
12 https://aws.amazon.com/rds/
13 https://azure.microsoft.com/en-us/free/mysql/ and https://azure.microsoft.com/en-us/services/postgresql/
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 15
Tools
A few of the more commonly used tools to help with migrating from
Oracle are:
• Ora2Pg – A Perl script which does an exhaustive job of analyzing
an Oracle database and notifying you of the required changes. It
will also create a new PostgreSQL schema for you and migrate the
data in batch form from the Oracle database to the new PostgreSQL
database.
• SQLines – A web-based utility that converts SQL code, including Data
Definition Language (DDL), from one SQL dialect to another.
• AWS DMS – A set of AWS utilities that can be used to analyze a
schema from one database type and create a new one in another
type. It also supports online replication between the source and
target databases.
Conclusion
Moving away from Oracle and onto your OSDB of choice can be a great
way to get out from under Oracle’s often extremely complex license and
contract structure – especially if you’re worried about getting locked
in, a common concern – while reducing support costs and avoiding
annoying customer audits. If you’re frustrated and thinking about
leaving Oracle, don’t despair: You’ve got options, although it’s worth
noting that selecting the best route for your use case typically requires
deep technical expertise and experience with both Oracle and other
databases.
As we’ve illustrated above, there are three main ways to get off of your
Oracle Database and on to an OSDB:
Direct migration – For migrations involving databases with low to
moderate complexity. Because of the similarity of its SQL dialect to that
of Oracle, PostgreSQL has largely become the default platform for direct
migrations.
Refactoring – Preferred to a direct migration by many because it helps
eliminate technical debt and facilitates a move to a microservices
framework. Use whichever database you like, but make sure you have
a well-tested data migration path, likely using the Kafka/Sink/source
method. Refactoring is a lot of work but the end result is usually worth
the effort.
Migrate to a new, off-the-shelf application – Because you’ll have to get
your data from the old system to your new one, you’ll still need a data
pythian.com
MIGRATING ORACLE DATABASES TO OPEN SOURCE TECHNOLOGIES | 16
migration plan if you go this route – don’t count on your software vendor having
one.
No matter which route you take, your migration is likely to take longer than you’d
prefer, unfortunately. Case in point: A very large company recently completed a
migration away from their various Oracle databases using all three approaches,
and even the smallest and simplest of the migrations took six to eight weeks
to complete – and most took six months to a year, with a few redevelopment/
refactoring efforts taking more than two years.
A strong migration partner, however, can help alleviate some of this pain.
Pythian database experts have years of experience working with Oracle and the
alternative database technologies mentioned in this paper. They can help get your
new OSDB (and your data) up and running faster, for less money, and without
needing to hire specialized IT resources for a one-time operation.
For more information on how Pythian can help you with your Oracle and OSDB
projects, or to set up a discovery call with one of our technical experts, please
contact us.
AUTHOR
John Schulz
Principal Consultant
John has 43 years of experience working with data in files and databases, from flat files
through ISAM to relational databases and, most recently, NoSQL. For the last 17 years, he’s
worked on a variety of open-source technologies including MySQL, PostgreSQL, Cassandra,
Riak, Hadoop, and Hbase. As Chief Database Architect at AOL, he replaced Sybase with
MySQL and has worked hands-on with MySQL databases holding hundreds of billions of
rows and running millions of transactions per second. For the last six years, he’s worked
with Pythian to help customers improve existing databases and select new ones for new
applications.
linkedin.com/company/pythian twitter.com/Pythian Contact us at +1-866-798-4426 or info@pythian.com
ABOUT PYTHIAN
Founded in 1997, Pythian is a global IT services company that helps organizations transform how they compete and win by
helping them turn data into valuable insights, predictions and products. From cloud automation to machine learning, Pythian
designs, implements and supports customized solutions to the toughest data challenges.
© Pythian Services Inc. 2021
OFFICES
Ottawa, Canada New York City, USA Minneapolis, USA London, England Hyderabad, India
