ERP implementation often fails in the gap between a feature name and daily work: unresolved data, unclear ownership and testing that stops when a screen opens. A manageable implementation starts with clear scope and measurable success.
Migration also carries existing problems
The plan moves through discovery, workflow and data design, configuration, migration, testing, training, cut-over and support. Steps are not perfectly linear; testing may reopen a data or process decision, but change should remain documented.
Two codes for one item distort planning
One product exists under two names and codes: sales use one, purchasing the other. Migrating both records makes one appear to sell quickly without replenishment while the other accumulates without demand. Purchasing suggestions and turnover reports conflict even though the software follows its inputs correctly. Product identity needs reconciliation before movements and opening balances are imported.
Assign an owner to each data set: products and units, customers and terms, suppliers and details, accounts and balances. That owner approves correct values and mappings between old and new codes. Complete cells are not enough: the selling unit may be a carton while the conversion treats it as one piece.
Prepare an operating sample covering purchase, receipt, sale, collection and return. Compare stock quantity, receivables, bank and cost of sales before and after it. This exposes linking errors that a successful file upload cannot detect. Retain independently calculated expected results so acceptance means more than a screen appearing to work.
At cutover, agree the final old-system document, first new-system document and handling of open transactions. Posting in both without a plan duplicates activity; leaving it between systems omits it. Initially inspect a small daily sample of invoices, transfers and receipts, then expand usage as results stabilise and responsibilities become clear to users.
Opening data and acceptance criteria
- Define objectives, excluded workflows and decision owners.
- Clean data and approve templates and control totals.
- Test normal and exception scenarios with different roles.
- Plan cut-over, support, fallback and post-go-live measures.
Instead of “customers imported,” use: 1,248 active customers imported without duplicates, balances total SAR 325,410, sampled sales and collections pass, and the owner approves every documented variance.
Acceptance needs measurable results
Before migration, establish customer and supplier totals, inventory quantities and value, bank balances and expected record counts. Afterwards compare the same scope and inspect detailed samples. Matching totals cannot rule out a balance assigned to the wrong customer; both aggregate and detailed checks matter.
Agree who can stop cutover when acceptance conditions fail and how work resumes from a sound position without losing new activity. Retain source files, mappings and reconciliations. Hand this knowledge to the operational owner when the project ends, so the next change does not become a search for why a code, balance or setting was chosen.
Sources & further reading
Visit the original source to explore the concept and its wider context.
General educational content. Appropriate treatment depends on your business and accounting policies; consult your accounting professional when applying it to business records.
