Migration cutover: preserve identities, originals and continuity

A billing migration is a transfer of responsibility for ongoing transactions and evidence. It is not simply loading customer names into another product. Plan what happens to historical originals, open balances, integration IDs, active queues and Peppol receiving identity before the first live invoice.

This playbook covers operational planning. Do not assume that OrdoGrid has a bulk-import endpoint, automatic historic-ledger migration or an access-point transfer button. Confirm the available path for your particular data and provider with the implementation team.

Inventory the scope and evidence

For each entity, record current system/provider, legal identity, Peppol participant, source integrations, invoice and credit-note counts, currencies, open balances, outstanding refunds and archive location. Include documents with uncertain delivery and transactions queued but not yet issued.

Separate historical evidence, open commercial items and new operational activity. A new product record is not automatically the original issued invoice. Preserve the old document identity and retrieval reference even if you create a controlled representation for ongoing work.

Prove export before closing the old service

Retrieve a sample covering an outbound invoice, inbound invoice, credit note, attachments and a disputed or corrected transaction. Open the structured original and available PDF. Keep source IDs, invoice numbers, legal parties, dates, delivery evidence and correction links.

The Belgian e-invoicing portal recommends preserving original XML and stresses authenticity, integrity and readability. Have your accounting/records owner document applicable retention categories and retrieval responsibilities; do not shorten retention because the provider changes.

A successful download of one recent PDF does not prove an exit archive. Test an older file, locate it by business reference and verify completeness across the migration population. Agree how records remain accessible after the old subscription ends.

Define the issuance boundary

Choose a date/time and timezone plus the exact entities/flows switching. Decide who assigns invoice numbers and how already-issued numbers remain traceable. Do not have both systems issuing the same source order while the migration runs.

Freeze or drain source queues under an operational owner. Reconcile committed, unattempted and uncertain operations. Keep durable document/movement identities and the correct integration namespace across replacement API keys. Do not reuse an old external identity for materially different financial content.

For open balances, inventory original gross debt, legal credits, confirmed cash and refunds. Do not convert a historical “paid” label into a fabricated payment. Legacy evidence gaps need a documented reconciliation case and accountant decision.

Coordinate receiving and provider changes

Ask current and future providers for their actual participant-transfer sequence and how incoming documents are handled around the boundary. Record who can authorise registration changes. A supplier communication date must match the real receiving setup.

Prove the new entity identity, supported document capability and first receipt. Keep a route for invoices sent just before the cutover or received in the old inbox afterward. Monitor both agreed exception queues during the transition and avoid describing duplicate receiving registrations as an automatic safety mechanism.

Example: staged ERP transition

A group moves consulting on Monday and logistics a week later. Consulting's 420 historical originals remain in a verified archive with their old IDs. Sixty open items reconcile by original total, credits, payments and refunds. Eight queued ERP orders are held while the issuer changes.

After the boundary, the new key confirms consulting and namespace erp. One standard invoice, one deposit case and one inbound supplier receipt pass. Logistics stays in the old flow until its recipient mapping is complete. The scope register prevents staff from treating Monday as a group-wide switch.

Make rollback boundaries honest

Before the first new live issuance, a rollback may return the held queue to the old issuer after reconciling attempts. After new numbered documents or network transmissions exist, rollback cannot mean deleting evidence or blindly issuing again in the old system.

At that point, pause further processing, inventory what each system committed and let finance approve a forward recovery or controlled source rerouting. Resolve uncertain sends with the provider before any replay. Use incident response when the cutover produces material ambiguity.

Accept and transfer ownership

Acceptance requires population totals reconciled by entity/currency, no unexplained duplicate identities, accessible originals, approved numbering treatment and demonstrated send/receive operations in the new scope. Retain residual cases with owner, next action and due date.

Handover the boundary, archive register, source mapping, key and registration owners, open-item reconciliation and old-service access dates. End overlap only after late incoming documents and uncertain transactions are accounted for. Continue with enterprise rollout and month-end reconciliation.