# Cutover exception worked example, step by step | SourceX

Canonical: https://refer.sourcex.si/guides/integration-cutover-reconciliation-exception-examples
Last updated: 2026-10-19

The records that explain a cutover exception are the mapping version in force, the load log that surfaced the problem, the reconciliation count that measured it, the ticket where people argued about the cause, and the sign-off that accepted what could not be fixed. Read in order, they show a judgment: who saw the mismatch, who decided, and how the result was checked. Below is one Illustrative hard case traced decision by decision, then the signs of a similar case at a client.

This walk-through belongs to the [integration cutover reconciliation guide](/guides/workflow-integration-cutover-reconciliation), which covers what to inventory before a legacy system is switched off. Here the job is narrower: show one exception from first symptom to accepted outcome, and name the record that captured every step.

## The case at a glance (Illustrative)

A fictional 380-person industrial parts distributor is moving order management from a legacy order-entry application to a new ERP. The integrator runs trial loads through an ETL tool, tracks defects in a project tracker and keeps reconciliation results in a shared workbook.

The trap is a status code. In the legacy application, code H meant credit hold until 2019. After that, branch staff also used H for orders held for customer pickup, without adding a new value. The only trace of the change sits in free-text order notes. Every trial load is technically clean: no rejected rows, no failed jobs. The problem only appears when someone compares the result against a list kept outside the system.

| Fact | Value (Illustrative) |
|---|---|
| Order lines in scope | 248,300 |
| Lines coded H in the legacy system | 6,900 |
| Lines on the credit team's own hold list | 500 |
| Mapping versions before sign-off | 3 |
| Weeks from first symptom to accepted outcome | 2 |

## Step by step: what went wrong and who decided

Each step names the person who acted and the record their action left behind. That pairing is what makes the case reconstructable.

1. **Mar 2: trial load with mapping v1.** The integration engineer maps every H to the ERP's credit hold status. The load completes. *Record:* mapping specification v1 and the ETL run history for that load.
2. **Mar 3: the count does not match.** The reconciliation analyst compares credit holds in the new ERP (6,900) with the credit team's list (500). 6,400 holds are unexplained. *Record:* a reconciliation workbook row citing the run and the count tested.
3. **Mar 4: the credit manager is asked.** The credit manager confirms that most of those customers have no credit issue and suggests H may have two meanings. The project manager opens a defect. *Record:* the ticket, with the credit manager's comment.
4. **Mar 6: a rule is proposed and approved.** The implementation director proposes remapping H lines dated from 2019 that carry a pickup location to a pickup hold. The operations director approves the rule on the ticket. *Record:* the approval comment and the ticket's field history.
5. **Mar 9: trial load with mapping v2.** 5,150 lines move to pickup hold. Unexplained holds fall to 1,250. *Record:* mapping v2, a new run, a new workbook row.
6. **Mar 12: the remainder cannot be classified from data.** The 1,250 lines have neither a clear date pattern nor a pickup location. Reviewing them one by one before go-live is not feasible. The controller and the operations director agree to load them as a new "review hold" status, to be worked by branch staff after cutover. *Record:* a signed exception on the ticket, naming both approvers and mapping v3.
7. **Mar 16: trial load with mapping v3.** Credit holds now equal the credit team's list: 500 against 500. Unexplained lines: zero. *Record:* mapping v3, its run and the closing workbook row.

The arithmetic closes: 6,400 unexplained, minus 5,150 remapped, leaves 1,250, all accepted with named approvers.

## The decision log: one row per ruling

The same case, read as a list of decisions rather than events. This is the shape an evaluator or reviewer needs: the trigger, the ruling, the authority and the evidence.

| Date | Trigger | Ruling | Decided by | Record that holds it |
|---|---|---|---|---|
| Mar 3 | 6,400 holds not on the credit list | Treat as a defect, not a data error | Project manager | Ticket opened, workbook row |
| Mar 6 | Credit manager says H has two meanings | Remap post-2019 lines with a pickup location | Operations director | Ticket approval, field history |
| Mar 12 | 1,250 lines still ambiguous | Load as review hold, resolve after go-live | Controller and operations director | Signed exception on ticket |
| Mar 16 | Counts match | Close the defect, freeze mapping v3 | Implementation director | Ticket resolution, final workbook row |

Jira, for example, records who changed a field and when, and shows it in the issue's History tab, which is how the Mar 6 and Mar 16 rows can be dated without relying on memory.

## Why this sequence is useful evidence

A successful load proves very little. This case is valuable because it contains a mismatch that tooling did not catch, a domain expert's explanation, a rule written in response, a measured improvement and a residual risk accepted by people with authority. Each step is linked to the next by a mapping version, a run or a ticket.

That chain is also fragile. Three things commonly break it:

- **Run history expires.** ETL tools keep run logs for a limited period set by the product and its configuration, so the first trial run may be gone long before the old application is retired. The [system map](/guides/integration-cutover-reconciliation-records-across-systems) gives a documented example.
- **Ticket history is exported separately.** Atlassian's data pipeline export writes issue history to its own file, and only includes history after the export's start date. A ticket list without that file loses the order of decisions.
- **Mapping files are overwritten.** If v3 replaced v1 in place, the case looks like a clean first attempt.

Day-to-day integration failures produce a similar pattern at lower intensity; the [integration error handling records](/data-types/integration-error-handling-records) page covers that steady-state version.

## How to recognize a similar case at a client

Partners rarely see the tickets, and should not ask to. Listen instead for these signals in ordinary project conversations:

- **"The load was clean but finance didn't agree."** A count tested against an outside list usually means a reconciliation trail exists.
- **"We had to add a status."** A new value created during cutover, like review hold, almost always has a signed decision behind it.
- **"That code meant something else back then."** Undocumented changes of meaning are the richest cases.
- **"We went through several mapping versions."** Ask whether old versions were kept.
- **Acquisition-driven cutovers.** Moves after a deal, such as those in the [3PL acquisition WMS guide](/guides/3pl-acquisition-integration-wms) or a [portfolio finance transformation](/guides/finance-transformation-private-equity-portfolio), tend to produce many exceptions under deadline.

Then ask metadata questions only: how many exceptions were logged, how many were accepted rather than fixed, where approvals sit and who owns the project archive. The [system map](/guides/integration-cutover-reconciliation-records-across-systems) shows which identifiers join the records, and the [who-can-say-yes tree](/questions/who-can-license-integration-cutover-reconciliation-records) shows whom to introduce.

The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Buyer interest, the rights result, what must be excluded and any offer stay unknown until SourceX reviews the opportunity. Partners sign the Channel Partner Agreement before submitting, and the first valid introduction within the 90-day window is credited when the company submits a verified application.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a client's cutover produced exceptions like this one and the decisions still sit beside the data, [register as a partner](/register), check the company on [who qualifies](/who-qualifies) and read the [program terms](/terms) before you introduce the executive who owns the records.

## Sources

- https://refer.sourcex.si/terms
- https://support.atlassian.com/jira/kb/how-to-identify-and-list-when-a-field-value-was-changed-in-jira/
- https://confluence.atlassian.com/adminjiraserver/data-pipeline-export-schema-1027142325.html