Most ERP implementations fail at the data migration stage, not during configuration. The new system goes live with opening balances and six months of transactions; a year later someone asks a question about the year before, and the answer lives on a server nobody can access.
A good migration preserves reporting continuity. A bad one preserves only the illusion of it. This checklist is what we run for every migration we run.
1. Know what you have
Before moving anything, survey every source:
- Current ERP or accounting system
- Spreadsheets used for reporting
- Legacy databases or Access files
- Bank and payment processor exports
- Any paper-era records that still matter
List the tables, approximate row counts, and the last time each was reconciled.
2. Define the field map
Every source field must map to a target field in AlpineERP. More importantly, the fields that do not map must be named. A migration plan that pretends every column has a home will break the first time it meets a custom field or a business-specific calculation.
The field map should be signed off by the business, not just the technical team. It is the document that answers the auditor's question two years later.
3. Cleanse before you load
Migration is the cheapest moment to fix master data. Duplicate customers, stale item codes and inconsistent supplier names should be resolved before the first trial load. Cleaning after go-live is archaeology.
4. Reconcile after every trial load
Do not accept "it looks right". Compare control totals after each load:
- Opening trial balance against the old system
- Subledger totals against the general ledger
- Stock valuation against the physical count
- Aged receivables and payables
Only proceed when three consecutive trial loads reconcile to zero variance.
5. Load history read-only
Prior-year transactions should land in a read-only state. This preserves trend reporting and customer history without letting anyone edit the past. The cutover date becomes a line, not a wall.
6. Sign off before go-live
The migration is not complete when the data loads. It is complete when the finance lead signs a variance report stating that the new system agrees with the old system at the cutover point.
Our data migration service runs this checklist as standard practice, with full history migration included in most implementations.