ERP Migration: A Step-by-Step Guide for Finance Teams
Every finance leader who has been through an ERP migration describes it the same way: the software demo took an hour, and the migration took two quarters. The gap between those two numbers isn't really about the new software. It's about what has to happen to a company's financial history before it can live safely inside it.
This guide walks through what ERP migration actually involves step by step, why the data migration portion specifically has traditionally been the slowest part, and what's changed recently for companies going through it.
ERP migration is the process of moving a company's financial data, chart of accounts, vendors, entities, and historical journal entries, from an old accounting system into a new one, while preserving enough detail and verification that the new system's books can be trusted from day one. Software selection gets most of the attention in this process. Data migration is usually where most of the actual time goes.
Key takeaways
- The bottleneck is data transformation, not software setup. Configuring a new ERP's settings and workflows is comparatively fast. Extracting, reshaping, and verifying years of journal entries is what traditionally consumes months.
- Verification has historically been the weak point. Once a legacy migration finishes loading data, most teams have no practical way to confirm everything came across correctly beyond spot-checking a handful of balances.
- AI-assisted migration changes the timeline of the data step specifically, not the entire implementation. Configuration, training, and process setup still take real time; the 15-minute figure you may see refers to the general ledger load itself.
- A real migration should be checkable by your own team, with a reconciliation record you can review yourself, not just a vendor or consultant's word that it worked.
- This isn't just an internal Campfire observation. Deloitte's CFO Insights research has found that data quality issues, insufficient testing, and data migration specifically are common causes of delayed go-live dates, and that problems disrupting launch tend to be especially costly to fix after the fact.
The step-by-step process
1. Scope and discovery
Before any data moves, the team maps what actually needs to migrate: which entities, how many years of history, which subledgers (accounts receivable, accounts payable, fixed assets, prepaids), and which edge cases exist in the current chart of accounts that won't map cleanly to a standard structure.
2. Chart of accounts mapping
The old chart of accounts gets mapped to the new system's structure. This is also typically the point where a company cleans up chart of accounts drift that's accumulated over time, duplicate accounts, inconsistent naming, accounts nobody remembers the purpose of.
3. Data extraction and transformation
Journal entries, vendor records, and entity data are exported from the old system and reshaped into the new system's format. Dates, dimensions, and account codes typically need reformatting here, and this step is where most manual migration hours have traditionally gone.
4. Load and validation
Data loads into the new general ledger. Balance and format checks should run before anything writes to the books, catching problems before they become part of the permanent record rather than after.
5. Reconciliation against the old system
The new system's balances get checked against the old system's balance sheet, account by account, period by period. This is the step that actually proves the migration worked, as opposed to assuming it did because the load finished without an error message.
6. Parallel run and cutover
Many teams run the old and new systems in parallel for a short period, or at minimum reconcile the first live close carefully, before fully retiring the old system.
Why this traditionally takes months
Migration delays aren't just an anecdotal complaint. A Deloitte survey of 185 finance leaders found that 70% describe their finance transformations as either less impactful or slower than expected, and Deloitte's own CFO research specifically names data quality issues, insufficient testing, and data migration as common causes of delayed go-live dates, noting that problems disrupting launch are especially costly to fix once they've happened. The pattern this guide describes isn't unique to any one vendor's customers; it's a documented, industry-wide experience.
The core problem is that most of steps 1 through 3 have historically been manual, skilled work: someone exports journal data, reshapes it in spreadsheets, maps the old chart of accounts to the new one by hand, and fixes formatting inconsistencies line by line. For a company with several years of financial history, that's weeks of work, usually billed hourly by an implementation consultant, and every hour of manual reshaping introduces a chance for error.
The deeper issue is verification. Once a legacy migration finishes loading, most teams have no practical way to confirm everything came across correctly. They spot-check a few balances, sign off, and hope. That uncertainty, not the learning curve of new software, is usually the real reason companies delay switching systems for years.
| Legacy implementation | AI-assisted migration | |
|---|---|---|
| Who does the work | Legacy implementationConsultants, billing hourly | AI-assisted migrationAn AI agent plus a supervising team |
| Data migration timeline | Legacy implementationWeeks of manual work | AI-assisted migrationMinutes for the general ledger load |
| History migrated | Legacy implementationOften opening balances only | AI-assisted migrationFull journal entry history, line by line |
| Chart of accounts cleanup | Legacy implementationHandled as a separate change order | AI-assisted migrationPart of the migration itself |
| Overall implementation timeline | Legacy implementationCommonly six to twelve months | AI-assisted migrationCommonly six to eight weeks |
| How you verify it worked | Legacy implementationLargely trusting the consultant | AI-assisted migrationA reconciliation workbook you check yourself |
How Campfire's Migration Agent approaches this
Campfire's Migration Agent automates the data transformation step specifically. It connects directly to the source system where a connection exists, and works from exported files everywhere else, which means legacy, customized, and home-built systems are a normal case rather than an exception. It maintains a mapping runbook for source systems it has seen before, and when it encounters an unfamiliar format, it derives a proposed mapping for a person to review rather than guessing silently.
The process, described in more detail in Campfire's Migration Agent launch post, runs in four stages: the chart of accounts, vendors, departments, and entities load first; journal entries are then normalized into Campfire's format, with anything ambiguous flagged for review rather than resolved automatically; the general ledger loads with balance and format checks running before anything writes; and finally every account is reconciled against the prior balance sheet, with a live, traceable workbook rather than a one-time confirmation.
Two things are true by design. First, every write requires human approval. When the agent hits something genuinely ambiguous, a duplicate account, a conflicting mapping, it stops and surfaces the question rather than resolving it on its own, because those are accounting judgment calls, not data-formatting ones. Second, the result is a migration you can check yourself: a reconciliation workbook with live formulas tracing every figure back to source data, rather than a consultant's assurance that everything landed correctly.
As one accounting firm partner who has overseen the change put it: "Cleaning up the journal entry import file used to be where most of my time on a migration went. That step is essentially gone."
With the data step compressed this way, most teams are live by their next monthly close or the one after, rather than the six to twelve months a legacy implementation typically requires.
FAQ
How long does an ERP migration actually take?
It depends what's being measured. The data migration step itself, moving journal entries, chart of accounts, and vendor records into the new system, can now run in minutes with AI-assisted tools. The full implementation, including configuration, training, and process setup, more commonly takes six to eight weeks with a modern approach, versus six to twelve months for a traditional consultant-led implementation.
Can historical transactions migrate, or only opening balances?
Both approaches exist. Some migrations move only summarized opening balances, which is faster but leaves less detail for future audits or historical analysis. A full migration moves every journal entry at transaction-level detail, so prior periods stay queryable and auditable after the move.
How do you verify that a migration actually worked?
The most reliable method is a reconciliation workbook comparing the old system's balance sheet against the new system's, account by account and period by period, with formulas that trace back to source data. Spot-checking a handful of balances after a load finishes is common but doesn't provide the same level of assurance.
Is it common for ERP implementations to run behind schedule?
Yes. Deloitte's research on finance transformations found that 70% of surveyed finance leaders describe their ERP-led transformations as either less impactful or slower than expected, with data migration and insufficient testing cited as common, specific causes of delayed go-live dates.
What is a migration agent?
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, typically with human review built in for ambiguous decisions.
What does Campfire's implementation cost?
Campfire offers tailored pricing based on company size and complexity. Contact the team for a demo and custom quote.