From Oracle to OceanBase: The Practical Migration Path for Xinchuang in Fund Valuation and Accounting Systems

📌 Core Argument The fund valuation and accounting system is the “production heart” of public funds—calculating NAV (Net Asset Value), asset valuation, and profit distribution for thousands of fund products after daily market close. It is the cornerstone of regulatory reporting and investor subscriptions/redemptions. This system has long been deeply dependent on Oracle databases (complex stored procedures, PL/SQL packages, DBLink cross-database queries), making its Xinchuang (Domestic IT Substitution) migration akin to “changing the engine while the plane is flying at high speed.”

In 2026, Ping An Fund, in collaboration with Yingshisheng, achieved full-stack domestication of its Valuation and Accounting System V5.5 Xinchuang edition (OceanBase + Kylin OS + proprietary Rockyas middleware), with over 96% of products completing EOD valuation before 19:00, and batch processing performance basically on par with the Oracle environment. Meanwhile, Harvest Fund replaced Oracle with KingbaseES for its TA (Transfer Agent) system, achieving 70TB of data migration, 230+ complex stored procedures, and financial-grade disaster recovery with RTO≤15 seconds, setting a benchmark for the domestication of core registration systems in China’s first batch of trillion-level public fund companies.

These two cases have outlined a five-stage practical path: “Assessment → Dual-track → Migration → Tuning → Single-track” for the industry. Understanding every link, every pitfall, and every performance breakthrough method along this path is critical for fund companies to make the right migration decisions before the 2027 Xinchuang deadline.

I. Why is Oracle Migration for Valuation Systems the “Most Formidable Challenge”

#

1.1 The Core Status of the Valuation and Accounting System

#

The core daily operational production chain for public funds is:

Market Close → Receive Quotes/Holdings/Trade Data → Valuation & Accounting (Core)
           → Calculate NAV/Gross Asset Value → Regulatory Reporting → Information Disclosure → Investor Sub/Red

The valuation and accounting system is the “computing heart” of this chain. Its outputs (fund NAV, gross asset value) directly impact:

• Regulatory Compliance: NAV calculation errors will lead to regulatory penalties.
• Investor Interests: NAV is the basis for subscription and redemption pricing.
• Information Disclosure: The data source for daily NAV announcements, quarterly, and annual reports.

1.2 The Four “Technical Debts” of Deep Oracle Dependency

#

Core systems in the fund industry have long run on Oracle, forming four layers of deep technical debt:

① Complex Stored Procedures (230+)

Taking Harvest Fund’s TA system as an example, there were 230+ complex Oracle stored procedures before migration, encapsulating:

• Share registration and transfer logic
• Dividend reinvestment calculations
• Massive redemption judgment and processing
• Management/custodian fee accruals
• Performance fee calculations

These stored procedures heavily use Oracle-specific PL/SQL syntax, built-in packages (DBMS_, UTL_), and dynamic SQL. Migrating them directly to domestic databases requires line-by-line rewriting or adaptation.

② PL/SQL Packages and Object Types

Oracle’s object types (OBJECT TYPE), collection types (TABLE TYPE, VARRAY), and pipelined functions (PIPELINED FUNCTION) are widely used in valuation and accounting for:

• Batch data processing
• Intermediate result passing for complex calculations
• Report generation

The support for these features varies greatly in domestic databases, posing a core challenge for migration compatibility.

③ DBLink Cross-Database Queries

The valuation system usually needs to interact with the TA registration system, investment trading system, and fund clearing system, using Oracle DBLink for cross-database queries and data synchronization. Domestic databases need to replace this capability (e.g., OceanBase’s DBLink, KingbaseES’s cross-database queries).

④ High-Concurrency Batch Processing and Performance Requirements

EOD batch processing is the heaviest load for the valuation system:

• Concurrent calculation for thousands of fund products
• A single product may involve millions of holding records
• The batch window is limited (usually required to be completed before 19:00 for evening regulatory reporting)
• Performance degradation directly leads to overtime for operations staff and delayed regulatory reporting

💡 Core Challenge: Migrating the valuation system from Oracle is not a simple “database replacement,” but a systematic engineering project involving business logic re-adaptation + performance re-tuning + full-process business continuity assurance. This is why the Ping An Fund case (96% of products valued before 19:00) and the Harvest Fund case (70TB data migration) are considered industry benchmarks—they prove this path is viable and stable.

II. Two Verified Migration Paths

#

2.1 Path A: The OceanBase Route (Ping An Fund + Yingshisheng)

#

Applicable Scenarios: Full-stack Xinchuang for core production systems like valuation and accounting, unified payment platforms, and operational risk control.

Tech Stack:

Database: OceanBase (Native distributed, Oracle compatibility mode)
OS: Kylin
Middleware: Ping An's proprietary Rockyas middleware
Security: Full-stack Xinchuang architecture with high availability and high security

Core Achievements (Ping An Fund V5.5 Xinchuang Edition):

• The first benchmark of full-stack domestication for valuation-related systems in the public fund industry.
• Covers a full series of Xinchuang solutions including Valuation & Accounting 5.5, Unified Payment Platform 5.5, Operational Risk Control 2.0, automated valuation, daily reports, information disclosure, and PCF baskets.
• As of March 2026, it has been running smoothly for half a year, successfully passing the year-end settlement test.
• Over 96% of products can complete EOD valuation before 19:00.
• Overall batch processing performance is basically on par with the Xinchuang version in the Oracle environment.
• Achieved the core goal of “no performance degradation.”

2.2 Path B: The KingbaseES Route (Harvest Fund TA System)

#

Applicable Scenarios: Oracle migration and replacement for TA registration systems and core registration systems.

Tech Stack:

Database: KingbaseES V8 (Oracle compatibility mode)
Migration Tools: KDTS full migration tool + KFS real-time incremental sync platform
OS: Domestic OS (Xinchuang environment)

Core Achievements (Harvest Fund TA System):

• Total data volume of nearly 70TB.
• Daily clearing peak concurrency of 16 paths.
• Migration and replacement of 230+ complex Oracle stored procedures.
• Financial-grade disaster recovery requirement of RTO≤15 seconds.
• Successfully achieved the three core outcomes of “smooth business transition, complete and reliable data, and significantly improved performance.”
• Became an important practical reference for the domestication of core registration systems in China’s first batch of trillion-level public fund companies.

2.3 Comparison of the Two Paths

#

💡 Selection Insight: For valuation and accounting systems (compute-intensive, sensitive to batch windows), prioritize the OceanBase distributed route (distributed architecture naturally adapts to high-concurrency batch processing). For TA registration systems (transaction-intensive, many stored procedures), KingbaseES is a good choice (strong Oracle compatibility, mature experience in migrating 230+ stored procedures).

III. Five-Stage Practical Path: From Assessment to Single-Track

#

Synthesizing benchmark cases like Ping An Fund and Harvest Fund, the Oracle→OceanBase migration for fund valuation systems can be summarized into a five-stage practical path:

Stage 1: Assessment and Compatibility Analysis (4-8 Weeks)

#

Goal: Understand the “baseline” and assess migration feasibility and workload.

Core Actions:

① Object Inventory

• Table structures (number of tables, partitioned tables, indexes, constraints)
• Stored procedures/functions/triggers (quantity, complexity, proportion of Oracle-specific syntax)
• Sequences, synonyms, DBLinks, materialized views
• Scheduled tasks (DBMS_JOB/DBMS_SCHEDULER)

② Compatibility Assessment

Assessment of OceanBase Oracle compatibility mode support:

③ Performance Baseline Establishment

• Collect baseline performance data for EOD batch processing in the Oracle environment (valuation time for each product, total batch time, peak concurrency).
• Use as the baseline for post-migration performance comparison.

④ Risk Assessment Report

• Identify high-risk Oracle-specific dependencies (e.g., deep use of UTL_FILE, DBMS_PIPE).
• Assess rewriting workload.
• Formulate a compatibility adaptation plan.

Ping An Fund Experience: Yingshisheng collaborated with the database vendor to conduct special technical research, identifying performance bottlenecks in advance through index reconstruction, SQL splitting, code refactoring, and fine-tuning of concurrency parameters.

Stage 2: Dual-Track Parallel Environment Setup (4-8 Weeks)

#

Goal: Set up the OceanBase production environment to run in parallel with the legacy Oracle system.

Core Actions:

① OceanBase Cluster Deployment

• Production environment: Recommend a 3-replica (or 5-replica) OceanBase cluster, deployed across data centers/racks.
• Resource configuration: Determine the number and specifications of OBServer nodes based on the number of fund products and data volume.
• High availability: RPO=0, RTO<30 seconds (financial-grade DR).

② Initial Data Migration

• Use OceanBase migration tools (or third-party tools) to complete full data migration.
• Verify data consistency (row count check, checksum comparison, sample data comparison).

③ Application Adaptation and Rewriting

• Stored procedures/functions/packages: Rewrite line-by-line according to the compatibility assessment.
• Application SQL: Adapt to OceanBase syntax differences.
• Connection pools/middleware: Configure OceanBase data sources.

④ Dual-Track Parallel Architecture

                    ┌──→ Oracle (Legacy system, read-only/main write)
                    │
App Layer ──→ Traffic Distribution Layer
                    │
                    └──→ OceanBase (New system, running in parallel)

• The app layer routes requests for some products/businesses to OceanBase via the traffic distribution layer.
• Both systems run in parallel, with regular data comparison and verification.

Ping An Fund Experience: Adopted a dual-track parallel strategy to avoid the business interruption risk of a “one-size-fits-all” switchover. Launched a proprietary one-click data migration tool supporting product/table-level migration, with breakpoint resume and rollback capabilities. The system fully maintains users’ original habits in UI design, operational processes, and data interfaces.

Stage 3: Data Migration and Consistency Verification (2-4 Weeks)

#

Goal: Complete full data migration, ensuring absolute consistency between the old and new systems.

Core Actions:

① Full Migration

• Use migration tools to complete full data migration.
• Harvest Fund case: 70TB of data completed via the KDTS full migration tool.

② Incremental Sync

• Oracle continues to run during migration; incremental data is captured via real-time sync tools.
• Harvest Fund case: KFS real-time incremental sync platform captures Oracle incremental REDO and syncs it to KingbaseES in real time.

③ Data Consistency Verification

• Row Count Check: Ensure row counts match for every table.
• Checksum Comparison: Calculate and compare checksums for critical tables.
• Sample Data Comparison: Extract critical business data for field-by-field comparison.
• Business Metric Verification: Compare key metrics like fund NAV, shares, and gross asset value.

④ Rollback Drill

• Verify the ability to roll back from OceanBase to Oracle (emergency assurance).
• Ping An Fund’s migration tool features a “rollback function” to ensure the switchover is reversible.

Stage 4: Performance Breakthrough and Tuning (4-8 Weeks)

#

Goal: Bring the batch processing performance in the OceanBase environment to or near the Oracle baseline level.

This is the most technically demanding and decisive stage of the entire migration.

Core Tuning Methods (Ping An Fund practical experience):

① Index Reconstruction

• Analyze execution plans of batch SQLs to identify full table scans.
• Establish appropriate indexes for high-frequency query conditions, join conditions, and sorting fields.
• Delete redundant indexes (to reduce write overhead).

② SQL Splitting

• Split large transactions into smaller ones to reduce lock contention.
• Split complex nested SQLs into multi-step executions.
• Change batch operations to batch commits.

③ Code Refactoring

• Rewrite incompatible PL/SQL code.
• Rewrite pipelined functions as regular functions.
• Optimize loop logic to reduce context switching.

④ Concurrency Parameter Tuning

• OceanBase parallelism parameters (parallel_degree_policy, parallel_degree).
• Connection pool size tuning.
• Memory parameter tuning (MemStore size, minor compaction threshold).

⑤ Partition Strategy Optimization

• Partition large tables by product/date to reduce single-partition data volume.
• Use partition pruning to improve query performance.

Performance Acceptance Criteria (Referencing Ping An Fund benchmark):

Ping An Fund Results: Through index reconstruction, SQL splitting, code refactoring, and fine-tuned concurrency parameters, over 96% of products can complete EOD valuation before 19:00, with overall batch performance basically on par with the Oracle Xinchuang environment.

Stage 5: Single-Track Go-Live and Legacy System Decommissioning (2-4 Weeks)

#

Goal: Switch all production traffic to OceanBase; the legacy Oracle system enters read-only/decommissioning mode.

Core Actions:

① Grayscale Switchover

• Batch 1: Low-risk products (e.g., money market funds, bond funds) switched to OceanBase.
• Batch 2: Medium-risk products (e.g., hybrid funds) switched.
• Batch 3: High-risk products (e.g., QDII, structured funds) switched.
• Observe for 1-2 batch cycles after each batch; proceed only after confirming stability.

② Full Switchover

• All product batch processing is completed in the OceanBase environment.
• The legacy Oracle system enters read-only mode (kept for 1-3 months as an emergency fallback).

③ Legacy System Decommissioning

• Data archiving (according to regulatory retention requirements).
• Oracle environment decommissioned.
• Complete Xinchuang acceptance.

Ping An Fund Experience: The system has been running smoothly for half a year, successfully passing the year-end settlement test, verifying the stability of single-track operation.

IV. Key Risk Checklist and Mitigation Strategies

#

4.1 Compatibility Risks

#

4.2 Performance Risks

#

4.3 Data Consistency Risks

#

4.4 Business Continuity Risks

#

V. OceanBase vs. KingbaseES: Selection Decision Guide

#

5.1 When to Choose OceanBase?

#

✅ Prioritize OceanBase in these scenarios:

1. Valuation and Accounting Systems: High-concurrency batch processing, parallel computation for thousands of products; OceanBase’s distributed architecture is a natural fit.
2. Continuously Growing Data Volume: Strong distributed scaling capabilities, supporting PB-level data.
3. Need Oracle Compatibility + Distributed: Require both Oracle syntax compatibility and distributed horizontal scaling.
4. Financial-Grade High Availability: Native Paxos multi-replica, RPO=0, RTO<30 seconds.
5. Cloud Deployment: OceanBase Cloud supports multi-cloud deployment.

Representative Case: Ping An Fund Valuation & Accounting V5.5 Xinchuang Edition (OceanBase + Kylin + Rockyas)

5.2 When to Choose KingbaseES?

#

✅ Prioritize KingbaseES in these scenarios:

1. TA Registration Systems: Transaction-intensive, many stored procedures (e.g., Harvest’s 230+); KingbaseES has strong Oracle compatibility.
2. Centralized Architecture Preference: No need for distributed scaling; centralized deployment is simpler.
3. Legacy Oracle App Migration: Deep accumulation in Oracle syntax/data type/stored procedure compatibility.
4. High Requirement for Domestic Autonomy: KingbaseES is a CETC-affiliated product with strong domestic attributes.

Representative Case: Harvest Fund TA System (70TB data, 230+ stored procs, RTO≤15s)

5.3 Selection Decision Matrix

#

💡 Decision Advice: Choose OceanBase for valuation systems (compute-intensive, sensitive to batch windows); choose KingbaseES for TA systems (transaction-intensive, many stored procedures). Large fund companies can adopt a “dual-database parallel” approach—selecting the most suitable database for different business systems.

VI. Migration Toolchain Recommendations

#

6.1 OceanBase Migration Toolchain

#

6.2 KingbaseES Migration Toolchain

#

6.3 General Tools

#

VII. Deep Dive into Industry Benchmark Cases

#

7.1 Ping An Fund: The “No Performance Degradation” Benchmark for Full-Stack Xinchuang in Valuation

#

Project Background:

• The first full-stack domestication of valuation-related systems in the public fund industry.
• Covers a full series of Xinchuang solutions including Valuation 5.5, Unified Payment 5.5, Operational Risk Control 2.0, etc.
• Partners: Ping An Fund + Yingshisheng + OceanBase + Kylin + Ping An’s proprietary Rockyas.

Migration Path: Dual-track parallel → One-click data migration (product/table-level + breakpoint resume + rollback) → Performance breakthrough (index reconstruction + SQL splitting + code refactoring + concurrency tuning) → Full-stack single-track.

Core Results:

• Smooth operation for half a year, passing the year-end settlement test.
• Over 96% of products complete EOD valuation before 19:00.
• Batch performance basically on par with the Oracle Xinchuang version.
• Achieved the “no performance degradation” goal.

Replicable Experience:

1. Dual-track parallel avoids “one-size-fits-all” risks.
2. Proprietary one-click migration tool supports product/table-level migration + breakpoint resume + rollback.
3. The “four axes” of index reconstruction, SQL splitting, code refactoring, and concurrency tuning are effective means for performance breakthroughs.
4. Maintaining original habits in UI/processes/interfaces reduces the learning curve for business staff.

7.2 Harvest Fund: The “Heavyweight” Practice of TA System Oracle Migration

#

Project Background:

• Domestication of core registration systems for China’s first batch of trillion-level public fund companies.
• Total data volume of nearly 70TB.
• Daily clearing peak concurrency of 16 paths.
• 230+ complex Oracle stored procedures.
• Financial-grade DR requirement of RTO≤15 seconds.

Migration Path: KDTS full migration + KFS real-time incremental sync + KingbaseES Oracle compatibility adaptation.

Core Results:

• Smooth business transition, complete and reliable data, significantly improved performance.
• 70TB of data completely migrated.
• 230+ stored procedures successfully migrated and replaced.
• Financial-grade DR of RTO≤15 seconds achieved.

Replicable Experience:

1. The KDTS+KFS full + incremental toolchain is mature and reliable.
2. KingbaseES’s Oracle compatibility supports the migration of 230+ complex stored procedures.
3. Financial-grade DR (RTO≤15s) is feasible under a trillion-level data scale.

VIII. Time Window Before the 2027 Xinchuang Deadline

#

8.1 Migration Cycle Estimation

#

8.2 Time Window Recommendations

#

2026 Q3 (Now): Initiate assessment and compatibility analysis
    ↓
2026 Q4: Complete dual-track environment setup + data migration
    ↓
2027 Q1: Complete performance breakthrough + grayscale switchover
    ↓
2027 Q2: Full single-track go-live + legacy system decommissioning
    ↓
2027 Q3-Q4: Complete Xinchuang acceptance, leave buffer time

⚠️ Key Reminder: 2027 is the critical node for Xinchuang compliance. Fund companies should initiate the Oracle→OceanBase migration assessment in the second half of 2026, and complete single-track go-live no later than the first half of 2027, leaving buffer time for Xinchuang acceptance. Delaying the start until the second half of 2027 will face the risk of an insufficient time window.

IX. Conclusion: The “Acceleration” of Fund Valuation Xinchuang Migration

#

Back to the core question at the beginning—What is the practical migration path for fund valuation systems from Oracle to OceanBase?

💡 This is a “five-stage path” verified by benchmark cases like Ping An Fund and Harvest Fund: Assessment & Compatibility Analysis → Dual-track Environment Setup → Data Migration & Consistency Verification → Performance Breakthrough & Tuning → Single-track Go-Live & Legacy Decommissioning. The entire cycle is about 4-8 months, with the core being “dual-track for continuity, performance tuning for experience, grayscale switchover for safety.”

Three Core Insights:

1. Choose OceanBase for valuation, KingbaseES for TA—matching the database to system characteristics is the prerequisite for migration success.
2. The “Four Axes” of performance tuning (index reconstruction + SQL splitting + code refactoring + concurrency tuning)—Ping An Fund’s practical experience of 96% of products valued before 19:00 proves that Xinchuang migration can achieve “no performance degradation.”
3. Dual-track parallel + one-click migration + rollback assurance—This is the engineering paradigm for smooth transition and risk control, avoiding the business interruption risks of “one-size-fits-all” switchovers.

A Consensus:

📌 Author’s Note: The Oracle→OceanBase migration of fund valuation systems is the core battle in the fund industry’s Xinchuang transformation, featuring the highest technical difficulty, strictest business continuity requirements, and strongest performance sensitivity. Ping An Fund, with Yingshisheng, achieved full-stack Xinchuang for valuation with 96%+ products valued before 19:00; Harvest Fund used KingbaseES to replace Oracle, migrating 70TB of data and 230+ stored procedures for its TA system. These two benchmark cases jointly prove: the Oracle dependency of fund core systems is not an irreplaceable technical barrier, but a systematic engineering challenge that can be overcome.

When OceanBase’s Oracle compatibility mode can support EOD batch processing for thousands of fund products with performance on par with Oracle, and when KingbaseES can handle a core registration system with 70TB of data and 230+ complex stored procedures with an RTO≤15s, the “computing heart” of China’s public fund core systems is finally beating to the rhythm of China’s own databases. Before the 2027 Xinchuang compliance node, this five-stage path of “Assessment → Dual-track → Migration → Tuning → Single-track” will become the core migration methodology for fund companies—those who choose the right path, use the right tools, and hit the right rhythm will win the initiative in the wave of Xinchuang.

Appendix: Oracle→OceanBase Migration Practical Path Quick Reference

#

Appendix: OceanBase vs. KingbaseES Selection Quick Reference

#