ERP go-live: data migration, superuser access and a payment fraud

Recommendation: do not go live on the current date. Defer four to six weeks and set dated exit criteria. The KSh 2,500,000 a month of delay cost is real, but it is not the largest number in this decision.

The migration statistic is the headline risk, and it is being read backwards. 96% by count sounds acceptable. The 4% that failed includes the twelve largest suppliers representing 38% of spend - roughly KSh 1.14 billion of annual purchases. Failure modes in a supplier master are not cosmetic: wrong bank details, duplicate vendor records that split spend and break rebate tiers, missing payment terms, wrong tax status, and blocked payments that halt deliveries. A distributor that cannot pay its top twelve suppliers for a fortnight loses shelf space in supermarkets it took years to win. The question the board must ask is not "what percentage matched?" but "what value matched, and is every supplier above a materiality threshold clean?" A 96% by count / 62% by value reconciliation would fail any reasonable acceptance test.

The access position is worse, because it is permanent from day one. Twelve unrestricted profiles with no named approval and no expiry means the audit trail at go-live - the period for which you most need it - is worthless. Superusers can create a vendor, approve it, release a payment and amend it afterwards. The database will record that a superuser did it and nothing more. This is the exact control that the recent fraud exploited.

The fraud is not history; it is a forecast. A beneficiary was changed and KSh 1,400,000 released; only KSh 900,000 came back. The root cause - no independent verification of beneficiary changes - has not been stated as fixed, and a new ERP will reimplement the payment workflow with new (untested) controls. Moving to a new system while the old control failure is unresolved imports the weakness into the new platform.

Backups are not backups. Twenty months without a restore test and a single copy in the same room means a fire, flood or ransomware event during cutover is unrecoverable. Cutover is precisely the window of highest data-loss risk.

The contract removes your leverage. No uptime commitment and no go-live penalty means a failed implementation costs the vendor nothing. Accepting go-live is accepting the vendor's risk on your balance sheet.

Balancing. Set the deferral against the downside: a failed month-end with 38% of supplier spend disrupted, plus the possibility of a second successful fraud, is plausibly several times KSh 2,500,000. Deferral is cheaper.

Access controls - must be complete before go-live

1. Withdraw all twelve superuser profiles. Access is granted to named individuals only. No shared or generic accounts, and no account whose name is a job title.
2. Rebuild roles from a segregation-of-duties matrix, not from who asked. The incompatible combinations to separate absolutely: vendor master creation / invoice approval / payment release / bank reconciliation / journal posting. Test the matrix against the actual user list and resolve every conflict.
3. Temporary or emergency access only with: written approval from two people (not the requester), a defined scope, an automatic expiry date, full logging, and review of the activity within 24 hours. Keep a register of every grant.
4. Multi-factor authentication for all finance, administrator and remote access. Disable dormant and default accounts. Enforce password and session policies.
5. Independent review of all superuser activity monthly by someone outside IT - the audit committee or internal audit - with the evidence retained.
6. Change control: no direct data changes in production; changes go through a tested, approved, logged path.

Incident response - for the phishing loss and for anything during cutover

1. Contain: disable the compromised account, reset credentials, block the sender domain, and check whether the attacker planted a forwarding rule or a mailbox rule.
2. Preserve evidence: mailbox and payment-system logs, the email headers, and the beneficiary-change audit trail. Do not let anyone "clean up" the account first.
3. Scope the breach: review every beneficiary change in the last 90 days and every payment released to a new beneficiary. Assume the KSh 1,400,000 was one of several attempts; the successful one is rarely the only one.
4. Pursue recovery of the outstanding KSh 500,000 with the bank immediately and record the loss, the recovery and the write-off properly.
5. Root-cause and fix: independent callback verification to a number from the master record (never from the email) before any beneficiary change; dual authorisation for beneficiary amendments; a cooling-off period between change and first payment.
6. Report: to the audit committee and board; to the regulator if personal data was exposed (data protection law applies to customer and employee records); and consider whether the bank or insurer requires notification.
7. Reduce repeat risk: targeted phishing simulation and training for finance, and a documented incident response plan with named roles, escalation times and a communication template.

Testing before go-live. Script at least these: a duplicate vendor attempt, a payment to a new beneficiary, a backdated journal by a superuser, and a failed batch run. If the controls cannot be demonstrated in test, they do not exist in production.

Vendor contract - negotiate before signing off go-live, not after The board's leverage is highest in the weeks before go-live; it evaporates on the day the old system is switched off. Use it now.

1. Service levels: uptime commitment of at least 99.5% measured monthly, with defined severity levels, response and resolution times, and service credits that bite. A credit of 2% of annual fees is a gesture, not a remedy; link credits to the cost of downtime.
2. Remedy for the strike-out: you cannot easily reinstate the penalty clause, but you can withhold final acceptance and the retention payment until defined exit criteria are met. Withhold 10–15% of fees against measured acceptance.
3. Data: confirm the company owns its data; require it to be returned in a usable format and destroyed at exit; escrow the source code or secure contractual continuity if the vendor fails.
4. Security obligations written into the contract, with a right to audit and a breach notification period measured in hours.
5. Liability: check the cap. It should be at least the annual fees, and ideally not capped for breaches of confidentiality or security.
6. Remediation schedule for the migration defects, signed by the vendor, with dates.

Business continuity

• Back up to an offsite or immutable cloud target, not a drive in the same room as the servers. A backup that burns with the server is not a backup.
• Test the restore quarterly, and record the result. Twenty months is not a plan; it is an assumption.
• Agree and document an RTO and RPO with the business - for a distributor, how many hours can order capture be down before customers buy elsewhere? Probably four.
• Maintain a cutover fallback: the legacy system read-only and reconcilable for at least one full month after go-live, so that a failure is a delay rather than a loss.

Governance of the decision

1. The go-live decision belongs to the board or its audit committee, on a written readiness assessment, not to the finance director alone. The finance director is also the person with the strongest incentive to stop paying duplicate costs - a classic conflict.
2. Require sign-off from the data owner, the IT/security lead, the internal auditor and the vendor against a checklist of exit criteria: 100% of suppliers above materiality reconciled, zero unreviewed superuser accounts, a successful restore test, and a closed-out fraud root-cause action.
3. Minute the decision and the dissents. If the board proceeds against advice, the record will matter.
4. Report post-implementation at 30, 60 and 90 days against the same criteria, and hold a lessons-learned review.
5. Consider a phased or parallel go-live - one region or one product line first - which converts an all-or-nothing risk into a contained one at modest cost.