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. The IRS generally expects businesses to keep records that support their tax returns for at least three years from filing, and longer in some situations, and payroll, employment and state tax records have their own retention periods. If you retire the old system, keep an export or a read-only copy you can still open. Other retention rules may apply to your sector, your state or your contracts; check with your accountant or attorney. 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 ID or EIN, or the same email domain and ZIP code.
- 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).
- Standardize values. States, countries, phone formats, 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 registration numbers or item categories.
- Remove what you should not keep. Personal information you no longer need for a legitimate purpose should not be carried forward. Data minimization and retention limits are built into many state privacy laws, such as the CCPA (as amended by the CPRA) and the Texas Data Privacy and Security Act, and the FTC expects reasonable data security (FTC guidance).
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, 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.
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 the United States, personal information will be processed across borders. Many state privacy laws, and sector rules such as HIPAA and the GLBA Safeguards Rule, expect written contracts with service providers and appropriate safeguards, and health data may require a business associate agreement (BAA). Check what your customers, your regulators and your own privacy notice say about where data is processed (FTC guidance). 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 customized source systems may need specialist tooling and more test cycles. For larger programs, 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)
- Privacy and security guidance for businesses, Federal Trade Commission
- IRS home page, United States Department of the Treasury
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.