Illustrative sample

A technical ERP workstream the implementation partner can take back under control

A migration is not complete when rows appear in the target system. The workstream must account for every source record and control total, make retries harmless, isolate exceptions, define the cutover and rollback point, and leave the implementation partner with evidence and operating documentation. This example shows that handoff for a bounded migration and integration scope.

Sample outcome

Every record accounted for, one exception owned

Customer records: 2,421 accepted plus 17 held equals 2,438 source records, 0 unexplained
Open receivables: $0.00 unexplained difference
Replay with the same key: Replay safe
Cutover and rollback: Ready for implementation partner approval
Authority: The implementation partner keeps functional and go-live authority

Synthetic totals for a fictional distributor; no client data.

Synthetic data. Every company, record, result and total on this page is synthetic. It shows the delivery approach for a bounded workstream; the implementation partner keeps functional and go-live authority.

Responsibility boundary

The implementation partner keeps functional authority; Libanto owns the technical result

Harborline Distribution, a fictional company, is moving customer and open-receivables data from a legacy ERP into a new ERP while preserving an existing commerce or warehouse integration. The implementation partner has approved the accounting design and source-to-target business mappings. Libanto, the company through which I contract engineering work, owns the technical execution and evidence for this bounded workstream.

Implementation partner retains

end-customer relationship and stakeholder management;
accounting and business-process design;
approval of source-to-target business mappings;
target ERP functional configuration;
user training and business UAT;
final go-live decision; and
final approval of corrections affecting business meaning.

Libanto owns within the agreed workstream

repeatable legacy extraction;
implementation of approved transformations;
stable source identities and idempotent import or upsert behavior;
one bounded nonstandard external-system integration;
record-count, control-total and exception reconciliation;
technical test and UAT evidence;
deployment and cutover preparation;
rollback readiness;
operating runbook and documented handoff; and
a clearly bounded hypercare or warranty window if included in the eventual contract.

The boundary prevents two common failures: a technical supplier silently making business-policy decisions, and an implementation partner receiving code without the evidence or operating knowledge needed to regain control.

Stable identities

The same source record reaches the same target identity every time

The target identity comes from a namespaced source key, not a display name or a generated row order. A retry therefore updates or confirms the same record instead of creating a duplicate.

Source record	Approved transformation	Stable target identity	Result
Customer `CUS-0142`	Normalize legal name; preserve tax and source IDs	`legacy:CUS-0142`	Accepted
Invoice `INV-9031`	Map customer; map approved AR and revenue accounts	`legacy:INV-9031`	Held: missing account mapping
Commerce order `WEB-7721`	Normalize currency and product IDs	`commerce:WEB-7721`	Accepted

Customer CUS-0142
Normalize legal name; preserve tax and source IDsTarget identity: legacy:CUS-0142Accepted
Invoice INV-9031
Map customer; map approved AR and revenue accountsTarget identity: legacy:INV-9031Held: missing account mapping
Commerce order WEB-7721
Normalize currency and product IDsTarget identity: commerce:WEB-7721Accepted

Replay check

Load run: RUN-2026-09-10-01
First execution: Record created
Replayed execution: Same idempotency key: existing record confirmed, no duplicate write
Outcome: Replay safe

An illustrative acceptance condition, not a measured production result.

Reconciliation

Reconciliation is complete only when accepted and held records explain the source

Customer records

Measure	Count
Source records	2,438
Accepted in target	2,421
Held with named exceptions	17
Accounted for	2,438
Unexplained records	0

Open receivables

Measure	Amount
Source open AR	$4,218,771.42
Accepted in target	$4,206,290.92
Held invoice INV-9031	$12,480.50
Accepted plus held	$4,218,771.42
Unexplained difference	$0.00

A zero target difference is not achieved by dropping rejected rows. The held invoice remains visible, owned and included in the control total until the implementation partner approves the missing account mapping.

Exceptions

A rejected record becomes managed work, not silent data loss

Held invoice

Held

Record: INV-9031
Value: $12,480.50
Failure: Approved target revenue-account mapping is missing
System decision: Hold the invoice; do not partially create it
Functional owner: Implementation partner confirms the business mapping
Technical owner: Libanto applies the approved mapping and replays the same source identity
Acceptance evidence: Invoice created once; open balance included once; control totals return to zero unexplained difference

Integration timeout

A provider timeout after an outbound request is treated as an uncertain outcome. Before retrying, the integration checks the stable external key or provider result. It never assumes the first attempt failed and blindly creates a second record.

Cutover

Go-live has an explicit decision point and a route back

Cutover timeline

Freeze the agreed source scope and record the extraction watermark.
Produce the final extract and immutable manifest.
Run transformation and pre-load validation.
Load with stable identities and bounded retries.
Reconcile counts, control totals and every held exception.
Run agreed integration replay and failure-path checks.
Present the acceptance report to the named implementation partner and customer owners.
Activate the workstream only after the implementation partner’s go-live approval.
Observe during the agreed hypercare window and record any correction through change control.

Rollback

The rollback point is defined before cutover. Code rollback, imported data, queued jobs and external side effects are treated separately. If an acceptance gate fails, new processing remains disabled while the agreed data-restoration or compensating procedure is executed under the implementation partner’s authority.

Handoff package

source and target manifests;
mapping version and decision log;
load-run records and idempotency keys;
reconciliation report;
exception register and resolutions;
deployment and configuration inventory;
cutover and rollback runbook;
monitoring and alert ownership;
known limitations; and
operational walkthrough with the implementation partner’s named owner.

Handoff

The workstream ends with evidence, not a verbal assurance

Acceptance condition	Evidence	State
Every source customer accounted for	Record reconciliation	Pass
Open AR has no unexplained difference	Control-total reconciliation	Pass
Held records have a reason and owner	Exception register	Pass
Replay creates no duplicate business object	Idempotency replay test	Pass
External timeout path avoids blind duplicate creation	Failure-path test	Pass
Cutover and rollback owners are named	Approved runbook	Ready for implementation partner approval

Every source customer accounted for
Evidence: Record reconciliationPass
Open AR has no unexplained difference
Evidence: Control-total reconciliationPass
Held records have a reason and owner
Evidence: Exception registerPass
Replay creates no duplicate business object
Evidence: Idempotency replay testPass
External timeout path avoids blind duplicate creation
Evidence: Failure-path testPass
Cutover and rollback owners are named
Evidence: Approved runbookReady for implementation partner approval

Scope

What this proves and does not prove

What the example demonstrates

how to separate technical execution from functional authority;
deterministic transformations and stable source identities;
replay-safe loading and external side-effect handling;
reconciliation that preserves rejected records;
named exception ownership;
explicit cutover and rollback decisions; and
a handoff that returns operational control to the implementation partner.

Outside this example

compatibility with an unknown ERP edition or schema; or
authority to make accounting or business-process decisions.

Is there a technical workstream your team needs someone to own?

If a current or upcoming implementation has a difficult extraction, integration, reconciliation, cutover or handoff scope, describe the workstream by email. The first conversation is to establish the boundary, owners and acceptance conditions.

Describe the workstream