Operations guide
A software implementation checklist for a small South African team
Who owns it, what data moves, what runs in parallel and when you stop paying for the old system. The plan most small projects skip.
Small software projects fail for large reasons, and almost always the same ones. Nobody owned it, the data was worse than anyone admitted, and there was no agreed moment when the old system stopped.
Name the owner first
One person owns the outcome. They do not have to be technical, but they need enough authority to make decisions about process, to insist on data quality, and to escalate when the vendor goes quiet.
Projects run by a committee drift, because every open question waits for a meeting. Projects run by nobody fail quietly and get blamed on the software.
Decide what actually moves
List every category of data and decide, explicitly, whether it moves, is archived, or is abandoned. Customers, suppliers, the chart of accounts, opening balances, open invoices, stock items, employee records.
The honest answer for historical transactions is usually that they stay in the old system with read only access retained. That is fine, provided somebody has confirmed you can still retrieve them when SARS or an auditor asks.
Clean before you migrate
Every dataset is worse than its owner believes. Duplicate customers, suppliers who ceased trading years ago, stock items with no cost, employees with missing tax numbers.
Clean it in the old system before it moves. Migrating rubbish gives you a new system full of the same rubbish, plus a general suspicion that the new system is unreliable.
Run in parallel and define the exit
Run both systems for at least one full cycle, whether that is a month of accounting, a payroll run, or a stock count. Compare properly, at line level rather than totals.
Then agree in advance what has to be true before the old system goes off. A reconciled trial balance, a payroll that matched to the cent, a stock count that agrees. Write those conditions down before you start, because deciding them under pressure produces optimism rather than judgement.
Train the people who will actually use it
Training the manager who chose it is not training. The people who capture invoices, run payroll or pick stock need time in the system before go live, on their own work rather than a demonstration dataset.
Budget the hours and protect them. Every hour skipped here comes back as an error in the first month, at a much worse moment.
Agree what happens when it goes wrong
Before go live, decide who you call, in what order, and what the fallback is if the new system cannot process something urgent. For payroll that means knowing you can still pay people. For accounting it means knowing you can still invoice.
Write it down and tell the team. A plan that lives in one person's head fails on the day that person is on leave, which is reliably the day it is needed.
Common questions
01How long does a software implementation take?
Cloud accounting or payroll can be days to a few weeks including a parallel run. An ERP is months. The variable is rarely the software and almost always data quality and the availability of your own people.
02Should I run old and new systems in parallel?
Yes, for at least one full cycle. It is duplicated work and it is the cheapest insurance available, because it finds setup errors before they reach an employee or a customer.
03Who should own a software implementation?
One named person with enough authority to decide on process and data, and to escalate to the vendor. Committees drift and unowned projects fail quietly.
Editorial note
This guide is general buying guidance and not accounting, legal or tax advice. Amounts and deadlines set by SARS change, so confirm the current figures for your own business before you rely on them.