1. Start with a clear cutover decision
Before launch week, agree on what must be true before the new ERP can go live. This should cover open sales orders, outstanding stock counts, debtors balances, month-end timing, approval levels and any third-party systems that must talk to the new platform. For SMEs in Johannesburg, Pretoria, Durban, Cape Town and Gqeberha, the pressure is often around trading hours, courier collections, branch access and finance sign-off, so the cutover plan must suit the way the business actually works.
A good readiness check also defines who can say yes or no. If the Managing Director, finance lead and operations manager all have a say, make that decision path practical and time bound. In many projects the biggest delay is not software, it is waiting for someone to approve a final data load or a workaround for a stock item that still needs cleaning up. Set the rules early and write them down.
2. Test the full process, not only the screens
User testing should follow real business steps from start to finish. It is not enough to confirm that a sales order can be entered or that a report opens. Test the full chain, from quote to invoice, from purchase requisition to supplier payment, and from stock receipt to dispatch. If your team works across Centurion and the East Rand for example, check that branch transfers, approval routing and stock visibility behave correctly at each site.
During testing, include edge cases that often cause trouble later. These usually include partial deliveries, cancelled orders, credit notes, price overrides, backorders and user permissions. If a process needs three manual exports and two re-imports, it is not ready. Keep notes on what failed, what was accepted as a temporary workaround and what must be fixed before go-live. A clean test register saves a lot of confusion later.
- Run at least one end-to-end test for each major department
- Include backup users, not only key managers
- Check reports, dashboards and printed documents, not just data entry
- Test after-hours access if teams work around load shedding or shift patterns
3. Prepare users for the first week on the system
Go-live readiness depends on people as much as it depends on data. Users need to know where to log in, what changed, who to contact and which tasks must be done in the new system from day one. In our experience, short role-based training works better than broad general sessions. A warehouse supervisor does not need the same detail as a finance clerk, and a branch manager does not need every step that a data capturer uses.
Training should finish close enough to go-live that the steps are still fresh, but not so late that users feel rushed. Provide quick reference notes for common tasks, such as creating a customer account, posting a receipt or checking a report. If staff are working in humid coastal conditions in Durban or under pressure in a busy distribution centre in Cape Town, keep the instructions simple and easy to find. Confidence on day one reduces errors and support calls.
- Nominate super-users in each department
- Share short task guides for daily work
- Confirm who handles first-line support internally
- Make sure login details and access rights are ready before launch
4. Clean the data before the final load
Bad data will slow down go-live even if the system itself is working well. Before final migration, check customer records, supplier details, item codes, units of measure, tax settings and account mappings. Duplicate accounts and incomplete addresses are common problems, especially where the business has grown by branch, product line or acquisition. A proper clean-up also helps with reporting and compliance.
For South African businesses, this is where practical details matter. VAT codes must be right, customer credit limits must reflect reality, and any municipal or site-specific billing rules should be mapped properly. If old records include outdated email addresses or partial delivery notes, fix them before they move across. It is much easier to correct information at source than to chase errors after the first live invoice has been sent.
Before the final load, confirm the following:
- Customer and supplier master data is current
- Stock balances match counted quantities
- Open transactions are agreed and signed off
- Control accounts tie back to the finance records
- Duplicate and inactive records are removed or flagged
5. Plan for launch week decisions and downtime windows
Launch week needs a simple operating plan. Decide when the final cutover starts, how long the business can afford to run on limited processing and what happens if a key step slips by a few hours. For some SMEs, a Friday evening cutover with Monday morning support is suitable. For others, especially those that trade continuously or depend on dispatches, a phased changeover is safer.
Because South African businesses often have to plan around load shedding, internet outages and local access constraints, the support plan should include practical backup measures. That may mean keeping printed picking notes ready, scheduling data loads outside peak usage times, or having a standby device available for critical approvals. The aim is not to avoid all disruption, but to keep the business operating while the team adjusts.
During launch week, make sure these decision points are clear:
- What triggers a go or no-go call
- Who approves the final migration sign-off
- Which manual workarounds are allowed temporarily
- How urgent issues are escalated
- When the first post-go-live review takes place
6. Review the first 10 days and fix what matters fast
The job does not end once the system is live. The first 10 days are for checking daily output, watching user behaviour and dealing with issues before they become habits. Monitor the tasks that affect cash flow, customer service and stock movement first. That means invoices, orders, receipts, dispatches, approvals and any integration points with payroll, banking or external systems.
Keep a short issue list and rank it by business impact. A display problem on a report is annoying, but a failed stock sync or a blocked approval chain can stop work completely. The support team should give clear feedback on what was fixed, what still needs attention and whether any additional training is required. If a process is repeatedly misunderstood, the solution may be simpler training, not more system changes.
By the end of the first review period, the business should know whether users are comfortable, whether the data is holding up and whether any process needs adjustment. That review is also a good time to decide on ongoing support retainer levels, upgrade planning and the next round of improvements.
