Updated September 2026: the original 2021 post listed a few points to consider when replacing a business application, such as interfaces, payment customisations and data conversion. I have expanded it into a practical checklist for upgrading or replacing a business system such as an ERP.
When an existing application can no longer meet basic functions or reporting needs, replacing it becomes a business decision rather than an IT one. The new system has to do everything the old one did that still matters, plus what the business now needs. Most failed upgrades underestimate the first half of that sentence.
How do you define requirements for the new application?
Start from what the business does, not from the old system's screens. List each process, such as order-to-cash or procure-to-pay, and map the functions the old application performs within it. Mark each as must keep, change or retire. Then add the new needs that triggered the upgrade. The result is the requirement set the new system is tested against.
What should you check on integrations?
Every interface between the application and other systems: banks, payment gateways, tax portals, CRM, warehouse and payroll. For each, confirm the new system supports the connection, who builds it and how it will be tested. Custom payment processes and approval flows deserve particular attention, because they are often undocumented.
What data needs to move, and how?
- Open transactions: quotes, contracts, orders and invoices still in progress.
- Master data: customers, suppliers, items and price lists, cleaned before migration rather than after.
- Project costing and billing: open projects mapped to the new structure, with balances reconciled.
- Finance: the chart of accounts mapped to the new one, with opening balances and consolidation rules tested.
- Documents: signed contracts and records kept accessible, digitally or on paper, as regulations require.
How do you know the migration worked?
Reconcile. Trial balances, open item totals and sample transactions should match between old and new systems at cut-over. Run at least one full dress rehearsal of the migration before the real one, and involve finance users in checking the results.
What is most often forgotten?
Reports. Users judge a new system by whether their familiar reports still exist, and nobody lists them until the week after go-live. Collect the reports people actually use, and rebuild or retire each one deliberately, before cut-over.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.