Should we implement AP automation before or after an ERP migration?

A well-built, ERP-abstracted AP platform carries over: the AP experience, workflows, vendor records, and invoice history stay constant while the integration is re-pointed from the old ERP to the new one. What gets remapped is the connector's field mapping - chart of accounts, dimensions/segments, entities - to the new ERP's structure. A deeply ERP-coupled or custom integration does not carry and is rebuild work. Ask your vendor explicitly what re-pointing involves.

Build an AP continuity plan: freeze a clean cutoff, keep capturing and approving in the AP layer (which is ERP-agnostic for the work), and stage postings to release once the new ERP is live and validated. Decide whether to pause posting briefly or run a controlled parallel, communicate the payment timeline to critical vendors, and keep an exception path for must-pay items. The AP layer staying constant is what makes "keep the lights on" feasible.

Often yes: a stable AP front-end removes one moving part from the migration, gives the team a familiar workspace during a stressful change, and cleans vendor/coding data up front (which the migration needs anyway). It also de-risks rollback - AP keeps running even if the ERP cutover hiccups.

A parallel run posts AP to both old and new ERPs to validate the new system before cutting over, typically for a close cycle or two. Keep AP in sync by driving from the AP layer as the single source of truth for invoice work, then comparing postings. Longer than a couple of cycles usually signals the new ERP isn't ready, not that parallel is helping.

Convert open bills, unapplied credits, and partial payments as opening balances in the new ERP, and pay down what you cleanly can before cutover to shrink the migration set. Reconcile the converted open AP to the old ERP's aging so nothing is lost or doubled.

Migrate open items and recent history needed operationally; archive older invoice images, closed history, and prior-year 1099 data. Keep images and approval trails accessible for audit - ideally in an AP platform that holds them independent of the ERP - so you're not resurrecting a dead system for a sample request.

Designate one system as the AP source of truth for the interim (usually the AP layer driving the still-live old ERP), avoid configuring the new ERP's AP until go-live is firm, and keep a single posting target at any moment to prevent split data. Extended dual-system pain is worst when both ERPs are treated as live AP destinations simultaneously.

Common failures: dirty vendor master carried into the new ERP, open AP that doesn't reconcile after conversion, lost invoice history, and a workflow rebuilt from scratch under time pressure. Early warnings: slipping go-live dates, unreconciled test conversions, and "we'll clean the vendors later." A stable AP layer and pre-migration data cleanup neutralize most of these.

Dedupe by tax ID and normalized name, merge confirmed duplicates, refresh remit/banking and W-9 data through controlled channels, deactivate dormant vendors, and map old IDs to new. Do this before load - a clean vendor master is the single highest-leverage migration prep for AP and 1099 accuracy.

A clean period boundary (month-end at minimum) simplifies the AP cutoff and the opening-balance conversion. Fiscal year-end is cleanest for full reset but concentrates risk; month-end is the common pragmatic choice. Avoid mid-period go-lives, which force messy split-period AP.

Yes - the "stable front-end, swap the back-end" argument: AP keeps running in a familiar workspace, data gets cleaned up front, and rollback is safer because AP doesn't depend on the new ERP being perfect on day one. It converts the ERP swap from an AP crisis into an integration re-point.

Very little day-to-day - they keep capturing, coding, approving, and conversing in the same AP workspace, which is the point. The retraining shrinks to ERP-side tasks (reporting, lookups) rather than the daily AP workflow, dramatically lowering change-management load.

Mapping the new ERP's chart of accounts, dimensions/segments, and entities into the connector; re-establishing authentication; validating in a sandbox (post test invoices across periods, entities, and matches); and cutting over. It's a configuration-and-test exercise, not a rebuild - assuming the AP platform abstracts the ERP.

Plan records access as part of the migration, not after: retain a read-only instance, export to an archive/warehouse, or keep invoice images and approval trails in an AP platform that holds them independent of the ledger. Decide the retention model before decommissioning, so audit lookback never requires reviving a dead ERP.

Because Stampli is ERP-native by design and mirrors the ERP rather than maintaining a competing ledger, AP keeps the same workspace, workflows, and history through a migration while the integration is re-pointed to the new ERP - the "stable AP front-end, swap the back-end" pattern in practice. Invoice images, approvals, and the immutable audit trail stay in Stampli regardless of which ERP is underneath, which protects continuity at cutover and audit lookback afterward. Stampli AI keeps performing on average 87% of finance work across 2,700+ unique fields throughout, with human review before posting.