Introduction

Against the backdrop of soaring Oracle Database license costs, Japanese companies are accelerating the move toward “de-Oracle.” Benesse Corporation migrated from its on-premises Oracle environment to the cloud, reducing hardware procurement and licensing costs. Tanabe Mitsubishi Pharma is progressing through a phased transition of compatible systems to PostgreSQL and SQL Server. Looking globally, Amazon — once one of the largest Oracle users in the world — migrated thousands of databases and achieved hundreds of millions of dollars in cost savings, sending shockwaves through the industry.

（出典：Japan companies accelerate “de-Oracle” trend driven by high license costs and lock-in concerns | Business Journal）

At ALLEXCEED VIETNAM, as a Vietnam offshore development partner, we have supported multiple Oracle→PostgreSQL DB migrations in our clients’ core systems. From that hands-on experience, one thing is clear: DB migration is no longer a question of “whether to do it” — it’s a question of “when and how.”

That said, migrating a core system database is a project with direct implications for business continuity. This article covers not only the benefits, but also the risks and decision criteria — informed by our real-world experience.

Why “De-Oracle” Is Accelerating Now

Reason 1: Structural Problems with Licensing Costs

Oracle Database offers high performance, but its licensing structure is complex. Costs accumulate based on the number of CPU cores and features used, and annual maintenance fees automatically add approximately 20% of the license price. In recent years, Oracle’s policy changes have led to discontinuation of entry-level products and repeated price revisions.

We’re hearing more and more from our clients about considering Oracle→PostgreSQL migration. When reviewing license costs as a trigger for migration, a certain amount of time is needed from scope definition through execution, so starting early is essential.

Reason 2: Business Inflexibility Due to Vendor Lock-in

When systems are built and optimized for Oracle, organizations end up in a state where they “want to switch databases but can’t.” Dependence on a specific vendor restricts freedom in cloud selection and can become a long-term business risk.

IT journalist Takahiro Kodaira notes that “In cloud-era IT strategy, flexible system configurations become increasingly important, but Oracle DB-centric configurations can make cloud migration and multi-cloud strategies more difficult.”

Reason 3: Technical Maturity of PostgreSQL

PostgreSQL is now chosen as a migration target not simply because it’s “free,” but because its technical capabilities are genuinely recognized.

It ranks 4th on the DB-Engines ranking worldwide (effectively 1st among open-source databases), and is offered as a managed service on AWS, Azure, and GCP. It provides transactional processing, JSON support, full-text search, and replication — with a growing track record in enterprise environments. （出典：DB-Engines Ranking | DB-Engines）

Of course, Oracle has a long-standing edge in features and stability developed over many years. However, systems with requirements that truly “can only be met by Oracle” are actually rare, and PostgreSQL is a technically sufficient option for the majority of business systems. Calmly weighing cost against functionality is key.

3 Benefits of Migrating to PostgreSQL

Benefit 1: Significant Reduction in DB-Related Costs

PostgreSQL is open-source, meaning software license fees are zero. Even when commercial support is needed, the cost is a fraction of Oracle’s.

5-Year Cost Comparison Overview

* Oracle’s official price list charges Enterprise Edition per Named User Plus or Processor model. （出典：Oracle Technology Global Price List | Oracle）

For example, if a system with annual Oracle costs of ¥5 million is migrated through an ¥8 million project, the initial investment is recovered in approximately 1.6 years. By leveraging offshore development to reduce project costs by 50–70%, the payback period can be shortened further. From year three onward, the cost savings flow directly to the bottom line.

Furthermore, the migration project cost itself can be reduced through offshore development. Having a Vietnam-based team handle SQL conversion and testing at 50–70% of domestic costs increases the overall return on investment.

Benefit 2: Support for Multi-Cloud Strategy

The challenge of continuing to use Oracle on the cloud isn’t just licensing costs. When bringing Oracle DB to AWS or Azure via BYOL (Bring Your Own License), cloud-side CPU cores become subject to Oracle licensing fees — leading to costs equivalent to or exceeding on-premises. Running Oracle DB outside Oracle Cloud can effectively double costs in some reported cases.

PostgreSQL, by contrast, is offered as a managed service on all major clouds, with only infrastructure usage fees for operation.

More importantly, migrating to PostgreSQL means regaining the freedom to choose your vendor. You can compare and select cloud providers based on cost, features, regional availability, and service richness.

• Availability design for failures: Multi-AZ and multi-region configurations become easier, allowing design aligned with RTO/RPO requirements
• Combining with cloud-native services: No DB-side constraints when combining with AWS Bedrock (generative AI), GCP Vertex AI, and other cutting-edge services
• Room for cost optimization: Leverage pricing competition between cloud providers and gain negotiating power to reduce long-term operating costs

Remaining locked into a specific cloud vendor means losing price negotiation leverage with every contract renewal. Migrating to PostgreSQL is a choice that restores freedom in your cloud strategy.

Benefit 3: Building a DX Promotion Foundation

The Ministry of Economy, Trade and Industry’s “DX Report” warns of the “2025 Cliff” — a state where organizations are consumed by maintaining legacy systems, leaving no people, money, or time for DX advancement. If left unaddressed, economic losses of ¥12 trillion or more annually are estimated after 2025. （出典：DX Report — Overcoming the IT System “2025 Cliff” | METI）

Being bound by Oracle DB’s high licensing fees and person-dependent maintenance is the very embodiment of this “cliff.” Refreshing the database cuts those annual costs, man-hours, and dependencies, freeing up resources for DX investment.

PostgreSQL has high affinity with modern data utilization platforms:

• Native integration with BI tools: Tableau, Looker, Redash and other major BI tools natively support PostgreSQL, enabling data visualization and analysis without additional middleware
• Data lake connectivity: Easy integration with AWS Glue and Google BigQuery, enabling cross-departmental data utilization
• AI/ML readiness: The “pgvector” PostgreSQL extension enables vector search, serving as an implementation foundation for RAG and internal knowledge search AI features
• Easier engineer hiring and training: The market supply of PostgreSQL engineers far exceeds Oracle, lowering recruitment costs and internal education burden

Rather than viewing DB migration as “replacing an old system,” treating it as an investment in rebuilding the foundation for using data in business management makes it a starting point for DX advancement.

3 Key Risks to Understand Before Migrating

Proceeding with migration while only seeing the benefits is dangerous. Core system DB migrations have inherent risks — understanding and preparing for them is the key to success.

Risk 1: The “Conversion Wall” from SQL Dialect and Feature Differences

Oracle SQL and PostgreSQL SQL are similar but not fully compatible. Differences arise in the following areas:

• Oracle-specific function rewrites (NVL→COALESCE, DECODE→CASE, etc.)
• PL/SQL package features (no equivalent concept in PostgreSQL)
• NULL and empty string handling (Oracle treats as identical; PostgreSQL distinguishes them)
• Trigger and sequence syntax differences

When we handled the DB migration of a power company’s core system, identifying these differences and verifying conversions required the most man-hours. In that project, we introduced an AI-powered automated conversion process to prevent manual conversion errors across a large volume of DB objects and SQL, significantly improving work efficiency. Handling this carefully dramatically reduces post-migration issues. （Case Study: Power Company Business Management System DB Migration）

（参考：What to Watch Out for When Migrating from Oracle to PostgreSQL: 3 Key Points | SCSK Corporation）

Risk 2: Differences in Performance Characteristics

Queries that run fast in Oracle may experience performance degradation in PostgreSQL. This is due to differences in internal processing (optimizer) behavior.

For systems that rely heavily on Oracle-specific hint-based tuning or Oracle-proprietary features such as bitmap indexes, post-migration performance testing is essential.

From over 800 project experiences, we can say that the testing phase is the most critical step that determines the success or failure of DB migration. Make sure to include testing with production-equivalent data volumes in your migration plan.

Risk 3: Impact on Surrounding Systems

Even if only the database is replaced, if the connected business applications, batch processes, report outputs, and external integrations were built assuming Oracle, those will also need modification.

What’s particularly easy to overlook are indirect dependencies not directly connected to the DB. For example, if the SQL generated by an application is assembled by an ORM or framework, you also need to verify that library’s PostgreSQL compatibility. Conducting a broad impact assessment in the early stages of a project is the single biggest factor in preventing rework in later phases.

4 Decision Criteria for a Successful Migration

Criterion 1: Visualize Migration Difficulty Through a Current Environment “Inventory”

Before deciding to migrate, the starting point is understanding how much your current system depends on Oracle.

Specifically, confirm the following:

• Data structure scale: Number of tables, data volume, growth trends
• Location of logic: How much processing is written in stored procedures, triggers, and views
• Number of connected systems: The full picture of DB-dependent processes including business apps, batch processing, and external integrations
• Oracle-specific feature usage: Sequences, partitioning, proprietary functions, etc.

The results of this inventory assessment dramatically change the man-hours, timeline, and risks involved in migration. Before deciding “whether it can be migrated,” understanding “the approximate scale” is a prerequisite for investment decisions.

Note that much of this inventory work can be automated using migration support tools like ora2pg. Running ora2pg’s --type SHOW_REPORT option outputs a list of Oracle-specific objects, SQL compatibility scores, and estimated man-hours. （参考：ora2pg Documentation | ora2pg.darold.net）

Criterion 2: Compare Costs Using 5-Year TCO

Migration projects require upfront investment. However, the judgment should be based on 5-year TCO (Total Cost of Ownership), not single-year costs.

As seen with Tanabe Mitsubishi Pharma, a phased switching approach — starting with systems that can be migrated — rather than migrating everything at once is also effective. Starting small, demonstrating results, and expanding in stages distributes risk and cost.

By leveraging offshore development, the execution cost of the migration project itself can be reduced to 50–70% of domestic costs. Including this option in your TCO calculation can change the conclusion of your investment decision.

Criterion 3: Choose Migration Method Based on System State

Assessing the balance of cost and effectiveness, and selecting the method appropriate for “the current state of your system” is critical.

Criterion 4: Build a Team with Both “Business Knowledge” and “Migration Technology”

DB migration cannot succeed without both people who understand the business and people with the technical expertise for migration.

• Internal members who understand the data’s meaning and business workflows
• Technical specialists proficient in SQL conversion, performance tuning, and test design

When internal engineering resources are limited, collaboration with an external partner with migration experience is a realistic option. For common pitfall patterns in selecting offshore partners, please also refer to Offshore Development Failure Patterns: 5 Patterns to Avoid and Countermeasures.

A practical structure is where “internal members handle business knowledge and decision-making, while the external partner handles technical execution.” The internal side focuses on business specification review and acceptance testing, while SQL conversion, unit testing, and integration testing are delegated to the external party.

In practice, for a 20 man-month Oracle→PostgreSQL migration of a power company’s core system, this structure achieved significant license cost reductions while maintaining the high stability required for social infrastructure. （See Case Study: Power Company Business Management System DB Migration）

In the printing industry, we also developed a dedicated migration tool for an Oracle→MariaDB migration, reducing manual conversion errors and advancing the project efficiently. （See Case Study: Oracle to MariaDB Data Migration Tool Development）

Conclusion: DB Migration Is an “Offensive Business Decision”

Oracle→PostgreSQL DB migration is not merely a cost-cutting measure.

• Significantly reducing annual fixed costs, freeing up the budget for DX investment
• Breaking free from vendor lock-in, regaining freedom in cloud strategy
• Building the foundation for future DX promotion

As the examples of Benesse, Tanabe Mitsubishi Pharma, and Amazon show, this trend is not a passing fad — it’s a structural shift in which companies reclaim control of their IT infrastructure.

We have stood in the field of Vietnam offshore development for approximately 20 years and over 800 projects. From that experience, one thing we can say is that DB migration has moved beyond “whether to do it” to the stage of “how to do it.”

For success, keep the following four points in mind:

1. Inventory your current environment to quantitatively assess migration difficulty
2. Make a calm investment decision using 5-year TCO (including offshore development as an option)
3. Select the migration method appropriate for your system’s state
4. Build a structure that covers both business knowledge and migration technology

Frequently Asked Questions

Q. What is the typical timeframe for an Oracle to PostgreSQL migration project?
It varies significantly by scale, but for a core system at a power company (20 man-month scale), approximately 6–9 months from start to completion is a realistic target. The number of tables, volume of stored procedures, and number of connected systems directly affect the schedule, so conducting an inventory assessment to understand the scale first is essential.

Q. Why are Oracle’s annual maintenance fees so high?
It’s because the contract structure automatically adds approximately 22% of the license price annually. The license itself is expensive, and downgrading or canceling is not easy, so costs accumulate the longer you continue using it.

Q. Can ora2pg handle fully automated migration?
ora2pg is an excellent tool that can automatically output Oracle-specific object lists, SQL compatibility scores, and estimated man-hours, but it does not support fully automated migration. Areas such as PL/SQL package conversion and differences in NULL/empty string handling always require human judgment and correction. Performance testing with production-equivalent data volumes is also a mandatory step.

Q. Is phased migration realistic for core systems?
Absolutely. As seen in the Tanabe Mitsubishi Pharma example, the approach of “switching systems in order of feasibility” distributes risk and cost, making it effective even before full deployment to core systems. Starting small and demonstrating results before expanding is a well-established approach in practice.

Q. What are the typical costs for outsourcing a DB migration to a Vietnamese offshore partner?
Focusing on high-volume processes such as SQL conversion, test design, and integration testing, the target is approximately 50–70% of domestic outsourcing costs. Combining with AI-powered automated conversion processes can further reduce costs and timelines in some cases.

Q. Will operations and maintenance become more difficult after migrating to PostgreSQL?
In many cases, it actually becomes easier to build a solid structure. The market supply of PostgreSQL engineers far exceeds Oracle, lowering recruitment costs and internal education burden. Using managed services on AWS or Azure also allows delegating much of the DB operational management to the cloud side.

Q. How does PostgreSQL compare to other migration targets like MySQL or MariaDB?
MySQL and MariaDB are also strong candidates, but PostgreSQL has a slight edge for enterprise use. It offers broader data utilization potential with JSON support, full-text search, window functions, and vector search via pgvector, with higher affinity for BI tools and AI. While we have migration experience from Oracle to MariaDB as well, more of our clients are now choosing PostgreSQL as their DX promotion platform.

Q. Can we request just the inventory assessment first, before committing to a full migration?
Yes, absolutely. We frequently handle cases where clients want to commission only the dependency assessment of the current Oracle environment and difficulty score calculation before deciding on a full migration project. This is the right approach when you want to gather the information needed for a management-level decision on “whether to migrate.” Please feel free to contact us for a consultation.

We will propose the best approach for your project

As a leading Japanese IT solutions company with approximately 20 years of experience in Vietnam offshore development, we provide software and system development services.
Please feel free to contact us when considering offshore development.

Vietnam Offshore Development

Case Studies | Download Materials | Free Consultation | Contact via LINE