An Acumatica implementation reaches a critical point when the new system begins carrying the business’s real records. A successful import confirms that data passed a technical process. The business still needs to establish whether customers, suppliers, items, outstanding documents, and financial balances mean what users expect them to mean.
Acumatica’s implementation guidance treats migration as part of a broader project involving requirements, planning, testing, and deployment. Its migration guidance emphasizes an organized process rather than treating data transfer as a last-minute file upload. Acumatica implementation process, Acumatica data migration guidance
The practical approach is to define acceptance before the import begins. That gives the project a way to identify success beyond “the records are in the system.”
Decide which history must become operational
Begin by separating three needs: records required for current operations, outstanding transactions that must continue after launch, and historical information needed for reference or analysis.
These categories may require different treatment. An open customer invoice must remain actionable if the business expects to collect and apply payment against it. An old closed transaction may be needed for inquiry without needing to behave like a new operational document.
Ask the implementation team to explain the proposed method for each category and the consequences for reporting. If historical information remains outside the new ERP, establish how authorized staff will retrieve it and how long that access will be maintained under the company’s requirements.
Avoid making “bring everything” the default scope before understanding the source data. More history can mean more mapping, validation, and explanation, particularly where old records use different definitions.
Assign business owners to the records
A technical consultant can map fields, but the business must decide whether two supplier records represent the same supplier or whether an item description is still valid. Those decisions require people who understand the operations.
Create a short ownership list for customers, suppliers, inventory items, account structures, and opening financial information. Give each owner a defined review task and a place to record unresolved questions.
For example, a customer record may contain an obsolete billing address while the finance team has been using a corrected address in a separate system. Importing the older value faithfully would preserve the wrong operational answer.
The migration should resolve that discrepancy through an approved decision. It should not rely on whoever happens to notice it during the final import.
Reconcile totals and inspect individual records
Validation needs both an overall view and a detailed view. A total can agree while individual records are wrong, and a sample of correct records does not establish that the complete population is accurate.
Use control totals appropriate to the scope, then inspect representative exceptions. Include records with unusual terms, multiple currencies where relevant, inactive statuses, credits, and incomplete information.
A simple hypothetical example illustrates the limitation of totals. Two customer balances of $4,000 and $6,000 add to $10,000. If the imported records assign those balances to the wrong customers, the control total still agrees. The migration has preserved the amount while damaging the collection process.
Validation therefore needs to confirm identity and meaning alongside arithmetic.
Make opening balances and open documents agree
The implementation team should document how detailed open transactions relate to the opening financial balances. This is especially important where different migration procedures can affect the general ledger and subsidiary records.
Do not assume that importing a trial balance and importing open documents are independent actions with no interaction. Ask the team to explain which process establishes each balance and how duplication is prevented in the chosen method.
The business’s accountant should be able to reconcile the resulting receivables, payables, cash, and inventory information as applicable. This article does not prescribe migration journal entries; those depend on the approved method and configuration.
The accounts receivable guide and accounts payable guide explain why the detailed documents must remain usable after launch, not simply contribute to an agreeing total.
Test transactions that cross departments
A migrated database is useful only if people can continue operating with it. Test a representative transaction through the complete process using the roles expected to perform the work.
For a distributor, that might include receiving an item, fulfilling an order, invoicing the customer, recording payment, and examining the resulting reports. The exact sequence should match the proposed scope.
Include corrections and incomplete cases. A transaction that works only when every field is ideal does not establish readiness for ordinary business. Record what happened, the expected result, the responsible reviewer, and whether the issue is resolved.
Keep test results distinct from a sales demonstration. A demonstration can establish a capability; acceptance testing establishes whether the configured arrangement supports the agreed business scenario.
Define the final transfer window
Before launch, identify when source records stop changing for the final transfer and how activity occurring afterward will be handled. Assign responsibility for capturing that activity so it does not disappear between systems or get entered twice.
The plan should state who authorizes the cutover and which unresolved conditions would change the decision. A target date alone does not explain what happens if opening balances fail to reconcile.
Also establish the contingency process appropriate to the project. The business should know how it will continue critical operations if the planned transition cannot proceed, without improvising conflicting records in multiple places.
Finish with a usable acceptance record
The acceptance record should identify the migrated scope, reconciled totals, completed tests, known limitations, and remaining owners. It should be understandable to the people who will operate the system after the project team steps back.
Connect that record to the reporting review. If management expects a historical comparison on the first day, the reporting scope and migrated history must support it.
The implementation has reached a meaningful milestone when users can explain what the records represent, continue the agreed processes, and trace a result back to its source. That is a stronger standard than an import log showing no technical errors.