The short answer
Migration problems are almost always data and ownership problems, not tool problems. Before you move anything into a new CRM or ERP, make sure you have:
- an owner for each record type who signs off on its quality,
- a scope that says what moves, what is archived and what is left behind,
- clean data, with duplicates merged and required fields filled,
- a field mapping that every owner has reviewed,
- at least one full test migration that reconciles against the old system, and
- a cutover and rollback plan with a clear go or no-go decision point.
1. Name the owners
Every record type needs a business owner, not only a technical lead. The owner decides which duplicates to merge, which values are correct and whether a test migration is acceptable.
| 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 |
If two teams both claim a record type, settle it now. The new system will not settle it for you.
2. Decide what moves
Not everything needs to come across. A common split:
- Master data (customers, suppliers, items, accounts): migrate, after cleaning.
- Open transactions (unpaid invoices, open orders, stock on hand, open opportunities): migrate, because the business needs to act on them.
- Closed history (paid invoices from past years, closed deals): migrate in summary, or keep in an archive that stays readable.
Archiving has a legal side. Nigerian tax and company law require businesses to keep their books, invoices and supporting documents for a number of years, and the Nigeria Revenue Service (formerly FIRS) or your state internal revenue service may ask to see them during an audit, including records for VAT and withholding tax. If you retire the old system, keep an export or a read-only copy you can still open and search. Confirm the retention periods that apply to you, and any sector rules on top of them, with your accountant or legal adviser. This is general information, not legal advice.
3. Clean and deduplicate
Clean data in the source system, or in a staging copy, before migration. Do not plan to "tidy it up afterwards".
- Agree matching rules. For example, two customer records are the same if they share a tax identification number (TIN) or CAC registration number, or the same email domain and phone number.
- Agree which record wins. When duplicates merge, decide which field values survive (the most recent, the most complete, or the value from a named system).
- Standardise values. States, countries, phone formats (with the +234 prefix), units of measure and payment terms in one consistent form.
- Fill required fields. The new system will enforce fields the old one did not, such as tax identification numbers or item categories.
- Remove what you should not keep. Personal data you no longer need for the purpose it was collected for should not be carried forward. Data minimisation and storage limitation are among the data protection principles in the Nigeria Data Protection Act 2023 (NDPA), explained in the NDPC's General Application and Implementation Directive.
4. Map every field
For each record type, record the source field, the destination field and any transformation. Keep the mapping in a shared spreadsheet that the owner signs off.
| Source system and field | Destination field | Transformation or rule | Required? | Owner sign-off |
|---|---|---|---|---|
- Every destination field that is required has a source or a default value.
- Code lists (tax codes, payment terms, units, customer groups) are mapped value by value.
- Identifiers from the old system are kept in a reference field, so records can be traced back.
- Currency (naira and any foreign currencies), date and number formats are confirmed.
5. Run test migrations
Run at least one full trial migration into a test environment, using a recent copy of production data. Most business systems support bulk loading; ERPNext, for example, imports CSV or Excel files to insert new records or update existing ones. Whatever the tool, the test should:
- load every record type, in dependency order (accounts and items before invoices),
- log every rejected record with a reason,
- be repeatable, so you can fix the data and run it again,
- be timed, so you know how long the real cutover will take.
Expect more than one round. The first test usually reveals mapping gaps and data problems nobody knew about.
6. Reconcile
A migration is not finished when the load completes. It is finished when the numbers agree.
- Record counts match by type (customers, suppliers, items, open orders), with every difference explained.
- Open receivables and payables agree in total and by 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, if migrating a CRM.
- Sample checks: owners open a selection of records, including awkward ones, and confirm them.
- Users can do their jobs: each team runs a few real transactions end to end in the test environment.
7. Plan cutover and rollback
Write the cutover plan as a timed runbook: the freeze on changes in the old system, the final extract, the load, the reconciliation, and the go or no-go decision. Plan the cutover window around power and connectivity as well: make sure the servers, network equipment and key workstations are on UPS or generator backup, and that a second internet link is available if the main one drops mid-load.
A rollback plan answers three questions:
- When do we decide? A named decision point, and named people who make the call.
- What makes it a no-go? Agreed criteria, for example an unreconciled trial balance or users unable to create orders.
- How do we go back? The old system stays intact and can be reopened; transactions entered in the new system during the window are recorded so they can be re-entered.
Keep the old system read-only, not deleted, for an agreed period after go-live.
Privacy and hosting
If the new system is hosted outside Nigeria, which is common because there is no major public cloud region in the country, personal data will be transferred abroad. The NDPA sets rules for transfers of personal data outside Nigeria (for example, an adequate level of protection in the destination country or another recognised basis), and you remain responsible for how your processors handle the data, so put a data processing agreement in place with the hosting provider. Tell people in your privacy notice if their data may be processed in another country, and check any sector rules (for example from the CBN or NITDA) that limit where certain data can be held. Also limit who can see full production data in test environments; masked or reduced data is often enough for early test rounds.
Limitations
This guide covers readiness, not every migration technique. Very large volumes, complex manufacturing data or heavily customised source systems may need specialist tooling and more test cycles. For larger programmes, see planning a big data migration.
Next step
If you are still choosing a system, start with the ERP evaluation checklist. If the system is chosen and you want 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.