Moving to a new ERP has a reputation problem, and it is mostly deserved. The software demo takes an hour. The migration takes two quarters. Somewhere between the two, finance teams learn that the hard part of switching accounting systems was never the accounting system.

Today we're launching Migration Agent, which moves a company's general ledger into Campfire in minutes rather than months, and produces a reconciliation workbook that proves every account tied out. It has been running real customer migrations for months. With the data work reduced to its shortest step, most teams are live on Campfire by their next monthly close or the one after. This post explains what it does, what it doesn't do, and why the slowest part of ERP implementation is now one of the fastest.

Traditional ERP migration takes months because the work is manual. Someone exports journal data from the old system, reshapes it in spreadsheets, maps the old chart of accounts to the new one, fixes date formats and dimension values line by line, and loads it batch by batch. For a company with years of history, that is weeks of skilled work, usually billed hourly, and every hour of it introduces the possibility of error.

The deeper problem is verification. When the load finishes, most teams have no practical way to confirm that everything came across. They spot-check a few balances, sign off, and hope. The anxiety that makes finance teams delay ERP switches for years is not about learning new software. It is about whether their data survives the move.

A migration agent is AI that performs the data transformation work in an ERP migration: reading the source system's data, mapping accounts and dimensions to the target format, running validation checks, and loading the result.

Campfire's Migration Agent handles the general ledger end to end. It connects to the source system directly where a connection exists and works from exported files everywhere else, which means unusual, legacy, and home-built systems are a normal case rather than an exception. It maintains a runbook for each source system it has seen, and when it encounters a format it hasn't, it derives the mapping and proposes it for review.

It is not autonomous, by design. Every write requires human approval. When the agent encounters something ambiguous, a duplicate account, a mapping conflict, it stops and asks rather than guessing. An accounting team supervises every migration, because the judgment calls in a migration are accounting decisions, not data decisions.

The full general ledger at transaction-level detail: chart of accounts, entities, vendors, departments, and every journal entry, line by line. Not a summarized opening balance, unless a team prefers a clean cutover, in which case the agent builds an opening balance at a chosen date and migrates incrementally from there.

Line-by-line history matters more than it sounds. A migration that carries only opening balances quietly destroys prior-period comparability. Year-over-year reports stop working, drill-downs dead-end at the cutover date, and auditors are handed a discontinuity. Transaction-level migration means prior periods remain queryable in the new system as if they had always lived there.

Subledger records such as invoices and bills come across as well, each carrying a reference to the journal entry it belongs to, so the audit trail holds. Prepaid and fixed asset schedules are built by the implementation team rather than copied, deliberately, because those schedules encode judgment about how a company wants items treated going forward, and copying an old system's assumptions into a new one is how migrations quietly import old problems.

This is the question the whole product is organized around, and the answer is: you check it yourself.

Every migration produces a reconciliation workbook. Your old balance sheet sits beside your new one, account by account, month by month, with a variance column between them. Every figure in it is a live formula tracing back to your own source export, so any number can be clicked and followed to its origin. The balances are verified two independent ways, once programmatically and once through the workbook's formulas, and the two methods are then reconciled against each other.

The workbook goes to the customer. A controller can hand it to an auditor. This is the difference between a vendor saying the migration worked and a finance team being able to prove it did, and we think it is the standard ERP migrations should be held to.

Yes. We build a sandbox environment and you upload your own data into it, so you can run your own numbers through Campfire before committing to anything.

Most ERP evaluations run on the vendor's sample data, which shows how the software behaves but not how it handles your chart of accounts, your dimensions, or the oddities in your history. Given that data risk is the reason teams delay switching, we would rather answer the question before the contract than after.