The short answer
Migration problems are data and ownership problems, not tool problems. Before moving anything, have:
- OwnersOne per record type, signing off quality.
- ScopeWhat moves, is archived or stays behind.
- Clean dataDuplicates merged, required fields filled.
- Field mappingReviewed by every owner.
- Test migrationAt least one full run that reconciles.
- Cutover and rollbackClear go or no-go decision point.
1. Name the owners
Each record type needs a business owner, not just a technical lead, to decide which duplicates merge, which values are right and whether a test passes.
Two teams claim the same records? Settle it now; the new system will not.
Typical owners by record type
| Record type | Typical owner |
|---|---|
| Customers, contacts, leads | Sales or customer service lead |
| Suppliers | Purchasing lead |
| Items, prices, units of measure | Operations or product lead |
| Chart of accounts, open balances, tax settings | Finance lead |
| Users and roles | IT lead, with each department head |
2. Decide what moves
Master data
Customers, suppliers, items, accounts: migrate, after cleaning.
Open transactions
Unpaid invoices, open orders, stock on hand, open opportunities: migrate, as people act on them.
Closed history
Past years' paid invoices, closed deals: migrate in summary or keep a readable archive.
3. Clean and deduplicate
Clean in the source or a staging copy before migrating, never "afterwards".
Matching rules
For example, same TIN or CAC registration number, or same email domain and phone.
Which record wins
Most recent, most complete, or the value from a named system.
Standard values
States, countries, phones (+234 prefix), units of measure, payment terms: one form each.
Required fields
The new system enforces new ones, like tax identification numbers or item categories.
Drop what you should not keep
Personal data no longer needed for its purpose stays behind (NDPA minimisation and storage limitation, NDPC GAID).
4. Map every field
Source field, destination field and transformation for each record type, in a shared spreadsheet the owner signs off.
| Source system and field | Destination field | Transformation or rule | Required? | Owner sign-off |
|---|---|---|---|---|
- Every required destination field has a source or a default.
- Tax codes, payment terms, units and customer groups mapped value by value.
- Old-system identifiers kept in a reference field for tracing back.
- Currency (naira and any foreign currencies), date and number formats confirmed.
5. Run test migrations
Run at least one full trial into a test environment from recent production data. Most business systems bulk-load; ERPNext, for example, imports CSV or Excel files to insert or update records. Any tool's test run needs:
- Every record type, in dependency order (accounts and items before invoices)
- Rejected records logged with a reason
- Repeatable after fixes
- Timed, to size the real cutover
Expect several rounds: the first exposes mapping gaps and unknown data problems.
6. Reconcile
A migration is finished when the numbers agree, not when the load completes.
- Record counts match by type, every difference explained.
- Open receivables and payables agree in total and per customer or supplier.
- Trial balance at the cutover date matches the old system.
- Stock quantities and values agree by item and location.
- Open opportunities or pipeline value agree (CRM migrations).
- Sample checks: owners confirm selected records, including awkward ones.
- Users can work: each team runs real transactions end to end.
7. Plan cutover and rollback
Write cutover as a timed runbook: freeze the old system, final extract, load, reconcile, then go or no-go. Plan the window around power and connectivity: servers, network equipment and key workstations on UPS or generator backup, and a second internet link in case the main one drops mid-load. The rollback plan answers three questions:
When we decide
A named decision point and the named people who call it.
What makes it no-go
Agreed criteria, such as an unreconciled trial balance or users unable to create orders.
How we go back
The old system stays intact to reopen; new-system entries are logged for re-entry.
Keep the old system read-only, not deleted, for an agreed period after go-live.
Privacy and hosting
With no major public cloud region in Nigeria, hosting abroad is common, and it means transferring personal data outside Nigeria. The NDPA sets transfer rules (for example, adequate protection in the destination country or another recognised basis), and you stay responsible for your processors: sign a data processing agreement with the host. Say in your privacy notice that data may be processed abroad, and check sector rules (for example CBN or NITDA) on where data may be held. Limit who sees full production data in test: masked or reduced data often suffices early on.
Limitations and next step
This covers readiness, not every technique: huge volumes, complex manufacturing data or heavily customised sources may need specialist tooling and more test cycles (planning a big data migration). Still choosing? Use the ERP evaluation checklist. For help planning or running the migration, see ERP implementation.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- Data Import, ERPNext documentation (Frappe)
- Nigeria Data Protection Act 2023: General Application and Implementation Directive (GAID) 2025, Nigeria Data Protection Commission
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.