Data migration vs real-time integration for expense management transition

ERP Oracle Fusion Cloud
, , , , , , , ,
1

We’re transitioning from Concur to Oracle Fusion Expense Management and debating the best approach. Should we do a one-time bulk data migration using FBDI for historical expenses, or implement real-time integration to sync data continuously during a transition period?

Bulk migration is cleaner - migrate all historical data once, then cutover. But we’d lose 2-3 months of expense history during implementation. Real-time sync keeps systems aligned during transition but adds complexity. Some team members suggest a hybrid approach using FBDI for historical data plus REST API for ongoing expenses during the transition window.

What factors should drive this decision? What’s worked well for others managing expense system transitions?

system 2

Concur → Oracle Fusion Expense: Migration Architecture Decision

The hybrid approach your team suggested is correct. Pure real-time sync during a Concur-to-Fusion transition introduces unnecessary risk; pure bulk migration creates the history gap you’ve identified. The architecture decision hinges on three factors: expense report lifecycle state, reporting obligations, and parallel-run duration.

Pre-Upgrade / Pre-Migration Checks

  • Audit Concur data quality before any extraction: orphaned cost centers, inactive employees, currency codes not mapped to Fusion ledger configuration
  • Confirm your Fusion Chart of Accounts and expense type mapping is finalized — FBDI loads will fail silently on unmapped values if validation is set to Warning rather than Error (verify in your version)
  • Validate that employee records are live in HCM Core before migrating expense data; FBDI expense imports require a valid PersonId reference
  • Identify which historical expenses are in closed periods vs. open periods — closed-period data is reference-only, open-period data may require reprocessing
  • Check your Corporate Card reconciliation state in Concur; partially reconciled transactions are the most common source of migration corruption
  • Confirm REST API rate limits for your Fusion environment (verify in your version for tenant-specific throttling)

Recommended Sequence

  1. Freeze historical cutoff date — typically the last closed accounting period before go-live. Everything prior = FBDI bulk load; everything after = native Fusion entry or REST integration.
  2. Extract Concur historical data to the FBDI Expense Report template (EXM_EXPENSE_REPORTS_INT interface table). Scope: submitted/approved/reimbursed reports only. Skip draft reports — migrate those as manual entry tasks assigned to employees.
  3. Load FBDI in validation-only mode first (Import Mode = Validate). Review the ESS job output in Scheduled Processes before committing.
  4. Run parallel entry window (your 2–3 month transition): new expense reports entered directly in Fusion; Concur locked to read-only for reference. Use REST API (/fscmRestApi/resources/latest/expenseReports) only if you have a system generating expenses programmatically (e.g., a travel booking tool still integrated to Concur mid-transition). Ad-hoc employee entry does not require REST.
  5. Validate reimbursement reconciliation — run the Expense Report Status Report and cross-reference against Concur payment history for the overlap period.
  6. Decommission Concur only after one full accounting period closes cleanly in Fusion with no reconciliation exceptions.

Rollback Procedure

  • FBDI loads to the interface tables are reversible before final import commit — reject the ESS job before the Process Expense Report Import step completes
  • Post-commit rollback requires mass update via SOAP/REST to void imported reports; there is no bulk undo in UI (verify in your version whether expenseReports DELETE endpoint supports bulk operations)
  • Maintain Concur in read-only mode (not terminated) for minimum 90 days post-cutover to support rollback reference and audit queries
  • Document the FBDI batch job IDs and ESS request IDs for every load — these are your rollback audit trail

The key architectural principle: REST API overhead during transition is only justified if a third-party system must remain the system of record temporarily. If employees can enter directly in Fusion from go-live, skip the real-time sync entirely and let FBDI carry the historical load cleanly.

This draft is based on general Oracle Fusion Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Hybrid is the way to go. Use FBDI to migrate closed expenses from previous fiscal year - these won’t change. Then implement REST API integration for current fiscal year expenses that are still in approval workflow. This gives you complete history while allowing ongoing business during transition. We did this for a client and it worked smoothly.

4

Consider your audit and compliance requirements. If you need complete expense history for audit purposes, bulk migration is mandatory. Real-time sync during transition is risky - what happens if sync fails and some expenses exist only in Concur? We migrated everything via FBDI, including in-progress expenses, then manually re-submitted active expenses in Fusion after cutover. More work but cleaner data.

5

Good point on audit requirements. We do need 7 years of history. How did you handle expenses in mid-approval during cutover? Did employees have to re-enter expense reports?

6

We froze Concur for new submissions two weeks before cutover. Employees completed all in-progress reports. Then we migrated everything via FBDI including those final reports. After Fusion went live, any expenses from the freeze period were entered directly in Fusion. The two-week freeze was manageable - we scheduled cutover right after month-end close to minimize impact.

7

The hybrid approach is technically sound but consider operational complexity. Running two expense systems in parallel means dual training, dual support, dual reconciliation. We tried this and it was a nightmare. Users were confused about which system to use. Finance struggled with reconciliation. A clean cutover with FBDI migration is operationally simpler even if technically more challenging upfront.

8

Think about your data volume and quality. FBDI can handle millions of expense records efficiently. REST API is better for smaller, incremental updates. If you have years of historical data with quality issues, FBDI lets you cleanse during migration. Real-time sync just perpetuates bad data. We migrated 5 years of expenses via FBDI with data cleansing rules - took 3 weeks but resulted in clean Fusion data.

9

Let me provide a comprehensive framework for this decision based on multiple expense system transitions:

FBDI for Bulk Migration: FBDI (File-Based Data Import) is Oracle’s preferred method for large-scale data migration. Advantages:

  • Handles millions of expense records efficiently in batch mode
  • Supports complex validations and data transformations during import
  • Provides detailed error reports for data quality issues
  • Can migrate historical data including closed expenses, reimbursements, audit history
  • One-time effort with clear success criteria
  • Native Fusion tool - no custom development required

FBDI templates for expense management:

  • Expense Reports (ExpenseReportsInterface.csv)
  • Expense Items (ExpenseItemsInterface.csv)
  • Cash Advances (CashAdvancesInterface.csv)
  • Credit Card Transactions (CreditCardTransactionsInterface.csv)

Best practice: Migrate expenses by fiscal period, starting with oldest closed periods. Validate each batch before proceeding. This allows data quality issues to be caught and fixed incrementally.

REST API for Real-Time Integration: REST API supports ongoing integration between systems. Use cases:

  • Syncing expenses during transition period when both systems are active
  • Ongoing integration if you’re keeping legacy system for certain functions
  • Incremental updates for expenses that change after initial migration

API endpoints for expense management:

  • /fscmRestApi/resources/11.13.18.05/expenseReports (create/update reports)
  • /fscmRestApi/resources/11.13.18.05/expenseReportHeaders (query reports)

Challenges with real-time integration:

  • Complex error handling for API failures
  • Need middleware for transformation and orchestration
  • Dual system support during transition increases operational burden
  • Risk of data inconsistency if sync fails
  • Requires monitoring and alerting infrastructure

Hybrid Integration Pattern: Recommended approach for most transitions:

  1. Historical Data (FBDI): Migrate all closed expenses from prior fiscal years

    • These expenses won’t change - safe for bulk migration
    • Provides complete audit history
    • Use FBDI templates with validation rules
    • Timeline: 2-4 weeks for migration and validation

  2. Current Fiscal Year (Decision Point):

    • Option A: Freeze legacy system, migrate all current year via FBDI, cutover cleanly
    • Option B: Keep legacy active, use REST API to sync current expenses during transition

    Option A (Clean Cutover) preferred when:

    • You can schedule 2-3 week freeze period around month/quarter end
    • User population is manageable for rapid training
    • Finance can complete reconciliation during freeze

    Option B (Parallel Systems) needed when:

    • Business can’t tolerate expense submission freeze
    • Geographic distribution requires phased rollout
    • Complex approval workflows need gradual transition

  3. Go-Forward State: All new expenses in Fusion only

Our recommended hybrid approach:

  • Use FBDI to migrate 2+ years of historical expenses (closed periods)
  • Implement 3-week freeze before cutover
  • During freeze: Complete all in-progress expenses in legacy system
  • Migrate current year expenses via FBDI including just-completed reports
  • Cutover to Fusion with clean slate
  • Any expenses incurred during freeze period entered directly in Fusion

This avoids complexity of parallel systems while ensuring complete data migration. The 3-week freeze is manageable if scheduled strategically:

  • Right after month-end close when fewer expenses are pending
  • Communicate freeze period well in advance
  • Provide Fusion training during freeze period
  • Have support team ready for cutover

Data quality considerations:

  • FBDI allows data cleansing during migration (standardize merchant names, categories)
  • REST API sync perpetuates data quality issues from legacy system
  • Use migration as opportunity to implement better data standards

For your specific situation with 7-year audit requirement, definitely migrate all historical data via FBDI. The question is whether to run parallel systems during transition or do clean cutover. Unless you have compelling business reason to keep both systems active, the clean cutover approach with freeze period is operationally simpler and results in better data quality.