Concur migration cutover runbook for Concur to Oracle Fusion Expenses. Month-end-aware sequencing, in-flight expense handling, corporate-card feed re-pointing, warm rollback plan, 2–4 week parallel reconciliation window.
A month-end-aware weekend runbook covering Concur freeze, in-flight sweep, final delta replay, corporate-card feed re-cutover, Fusion go-live, parallel reconciliation and warm rollback.
The concur migration cutover is where many T&E migration projects go wrong — not in the months of planning that preceded it, but in the 72 hours where the platform actually changes hands. Receipt-image streaming has been running for weeks; corporate-card feed coordination with Amex GBT has been booked since project kick-off; Fusion expense templates and AMX flows have been tested in non-prod. None of that matters if the freeze window slips, if in-flight expense reports lose their approver chain, or if the corporate-card feed gets cut to Fusion before the last Concur file is reconciled.
Syntra ETL's concur migration cutover runbook is the work-stream playbook used in every Concur to Fusion migration. It's sequenced around the month-end financial close so the close before cutover runs cleanly on Concur and the close after runs cleanly on Fusion — no split-close where entries straddle both systems. The freeze window is 48–72 hours, picked based on the customer's submission velocity. The in-flight expense sweep categorizes every submitted-but-not-paid report into four buckets with owner-assigned handling.
Most importantly: the runbook keeps a real rollback plan warm for 4–6 weeks post-cutover. Trigger conditions are pre-defined, the procedure is rehearsed, and Concur stays in restorable read-only mode until the parallel-reconciliation window closes with finance and internal audit sign-off.
The week before cutover weekend. Every item has an owner, a target time and a roll-back trigger if it doesn't complete.
Final pre-cutover month-end close on Concur confirmed complete and signed off. Any open close items resolved or formally accepted. Goes-no-go for the cutover weekend depends on this gate.
Three-staged communication: T-7 days (cutover is coming), T-3 days (freeze window starts Friday), T-1 day (Fusion login details). Includes mobile-app re-download instructions for cardholders.
Concur freeze config (disable new submission, disable approval actions) tested in the staging tenant. Restore-to-writable procedure rehearsed for the rollback plan.
Amex GBT / Visa / Mastercard provider cutoff date confirmed in writing. Late-posting transaction lag (5–15 days) factored into the parallel reconciliation window.
Approvers for in-flight reports on standby for Friday/Saturday — nudge approval queue through to clear as much in-flight as possible before freeze locks records.
Full end-to-end test load to non-prod, including receipt-image binding, AMX approval flow, corporate-card matching and OTBI reporting. Zero-defect pass required for go.
Friday evening through Monday morning. Every item time-boxed. Rollback trigger active if any item fails its time-box.
Friday 18:00 local. New submission and approval actions disabled in Concur. Concur tenant captured to immutable snapshot for rollback restore-point.
Saturday 06:00. Final REST extract of any Concur records changed during the freeze window. Hash-signed manifest. Routed to Fusion via REST API replay.
Saturday afternoon. Each of the four in-flight buckets processed by its assigned owner. Cleared counts logged. Sign-off captured before next gate.
Saturday evening (provider-dependent). Last Concur card file reconciled to provider statement. Feed switched at provider. First Fusion file validated.
Sunday afternoon. Test users log into Fusion Expenses, file a test report, submit through AMX, receive cardholder confirmation, validate receipt-image attachment. Smoke test pass required.
Sunday evening. Initial period-to-GL reconciliation run for the final pre-cutover month. Variance < 0.5% required. Finance lead signs off. Cutover gate cleared.
A 72-hour orchestrated sequence. Every step time-boxed, owner-assigned, rollback-conditional.
Concur new-submission and approval-action endpoints disabled at the Concur tenant level. Immutable snapshot captured for rollback restore. T-7-days, T-3-days and T-1-day user comms already delivered. Approver queue nudged through pending items.
REST API extract of any records that changed during the 12-hour freeze window. Hash-signed manifest. Receipt-image hash chain validated. Delta replay to Fusion via REST API begins.
Each of four in-flight buckets (awaiting approval, returned, approved-awaiting-payment, paid-not-GLed) processed by its owner. Sign-off captured per bucket. Counts logged for audit pack.
Final Concur card file reconciled to provider statement to the cent. Feed switched at provider (Amex GBT typically requires a 4-hour switch window). First Fusion card file received and validated against provider statement.
Test users (one per BU) log in, file expense report, submit through AMX, validate receipt-image attachment, validate cardholder corporate-card matching. Smoke test pass required for next gate.
Initial period-to-GL reconciliation for final pre-cutover month. Variance acceptance threshold < 0.5%. Finance lead, T&E ops lead, compliance officer sign-off. Monday 06:00 normal user access enabled.
Concur migration cutover is the orchestrated weekend (typically Friday evening through Monday morning) during which Concur is moved to read-only mode and Oracle Fusion Expenses takes over as the system of record for new expense submissions. The work-stream covers: (1) Concur freeze — new submissions disabled 48–72 hours pre-cutover; (2) in-flight expense sweep — every submitted-but-not-paid report categorized and handled; (3) final delta extract — anything that changed in Concur during the freeze captured and replayed to Fusion; (4) corporate-card feed re-cutover at provider level; (5) Fusion go-live — users switched, training reinforced; (6) parallel reconciliation — 2–4 weeks where late-posting card transactions and disputed expenses are caught; (7) rollback plan — kept warm until reconciliation closes.
The freeze window exists because expense reports in flight at the moment of cutover are the single highest-risk class of records. A report that's been submitted in Concur but not yet approved when cutover happens needs its approval state and approver chain preserved end-to-end. A 48–72 hour freeze before the concur migration cutover lets the in-flight inventory be swept, categorized and handled: reports awaiting approval get nudged through if approvers are available, returned-for-revision reports get cancelled (and re-filed in Fusion post-cutover), already-paid reports get closed. Without a freeze, cutover would have to handle a moving target — every additional new submission in the last hours adds another in-flight record needing categorization, and the cutover window stretches indefinitely.
In-flight expense reports fall into four buckets at the freeze. Bucket 1 (submitted, awaiting first-level approval): if approvers are available, nudge through to next state pre-freeze; otherwise migrate to Fusion with approval state and approver chain preserved via AMX. Bucket 2 (returned to user for revision): cancel the Concur version, instruct user to re-file in Fusion post-cutover. Bucket 3 (approved, awaiting payment): close on Concur side, route the reimbursement payment file to Fusion Payables for execution. Bucket 4 (paid but not yet hit GL): post to Concur GL as final, migrate the closed report to Fusion as historical. Each bucket gets a count, an owner and a target-cleared timestamp on the concur migration cutover runbook.
Corporate-card feed cutover is the single most provider-dependent task on the concur migration cutover runbook because the card provider (Amex GBT, Visa, Mastercard) controls the feed switching, not the customer. Sequence on cutover weekend: Friday — process last Concur card file, reconcile to provider statement to the cent; Saturday — confirm cutoff with provider, switch feed destination to Fusion; Sunday — process first Fusion card file, validate against provider statement, verify cardholder PersonNumber matching and posting-account derivation; Monday morning — cardholders confirmed receiving card transactions in Fusion. Late-posting transactions (transactions that posted to the provider after the Concur feed was cut but before the Fusion feed received them) are caught in the parallel reconciliation window.
A real rollback plan, kept warm for 4–6 weeks post-cutover. Trigger conditions: (a) period-to-GL reconciliation defect over 1% of expense volume per BU; (b) receipt-image substantiation defect on any sampled receipt during the 7-year retention validation; (c) corporate-card transaction loss exceeding 50 transactions per cardholder. Rollback procedure: (1) freeze Fusion expense submissions; (2) restore Concur from the freeze snapshot to writable mode; (3) re-cutover corporate-card feed to Concur; (4) replay any Fusion-side expense submissions back to Concur via REST API; (5) communicate to users. Rollback is rare — across dozens of Concur migrations Syntra ETL has run, the plan has been triggered twice, both for receipt-image substantiation defects that were resolved within 48 hours.
Typically 2–4 weeks. The window is driven by two factors. First, corporate-card late-posting transactions: card transactions can post to the provider 5–15 days after the transaction date, so transactions made before cutover can still appear in the post-cutover feed. The reconciliation window has to cover that lag — 2 weeks for a US-only domestic card programme, 4 weeks for a global multi-currency programme. Second, in-flight expense report close-out: a submitted-but-not-yet-paid report at cutover might take 2–3 weeks to fully clear through approval, reimbursement and GL posting in Fusion. The parallel-reconciliation window keeps Concur read-only and the rollback plan warm until both factors are fully resolved.
It can — and the runbook explicitly sequences the cutover around month-end close to minimize the impact. The recommended pattern is: cutover the weekend after the month-end close that follows the final parallel-run cycle. That means the close before cutover is run entirely on Concur with normal procedures, and the close after cutover is run entirely on Fusion — no split-close where some entries are on Concur and some on Fusion. The month-end-close team's runbook gets a one-page addendum: 'this month, expense data sources from Fusion, here's where to find the new reports.' The first full month-end close on Fusion is also the period where finance and IA pay closest attention to the period-to-GL reconciliation.
Concur moves through three phases post-cutover. Phase 1 (cutover weekend through end of parallel-reconciliation): Concur is in read-only mode. No new submissions, no approvals, no payments. Operational reports still queryable for reconciliation. Phase 2 (after parallel-reconciliation, through 12–24 months): Concur is in long-term archive mode. Tenant subscription downgraded to read-only tier where the SAP contract supports it. Used only for audit retrieval. Phase 3 (after 12–24 months, depending on regulatory window): Concur tenant decommissioned. Receipt-image archive moved to long-term cloud object storage with the same IRS Pub 463 retrievability guarantee. Tenant subscription fully cancelled. The cancelled-tenant date becomes the 7-year retention countdown anchor for the residual archive.
Book a discovery call. We'll walk through your Concur footprint, month-end calendar and card-provider relationships — and produce a customised concur migration cutover runbook with owner-assigned items in under 30 minutes.