The 5 UAT Mistakes I Made (So You Don't Have To)
I've run UAT on probably forty ERP implementations. I've made every mistake there is to make, some of them more than once. Here are the five biggest, what went wrong, and what I should have done instead.
Mistake #1: Trusting "It Works in Dev"
What I Did
On a Business Central implementation for a wholesale distributor, the development team assured me that inventory transfers between warehouses were working perfectly. They'd tested it in the development environment. Multiple times. I took their word for it and didn't include it in the UAT test plan.
What Went Wrong
Week one post-go-live, the client's warehouse team transferred £80,000 worth of stock between locations. The transaction posted. The stock physically moved. But the inventory value didn't update correctly in the receiving warehouse because a rounding rule in the costing logic behaved differently in production than it did in dev.
Finance couldn't reconcile inventory for two weeks whilst we debugged it. The client lost confidence in the system. The project manager lost confidence in me.
What I Should Have Done
Include everything in UAT, even if the developers swear it's working. Development environments and production environments are never identical. Data volumes differ. Security contexts differ. Integrations differ. If the client is going to use it in production, it gets tested during UAT. No exceptions.
Lesson: "It works in dev" is not the same as "it works in production". UAT tests production configuration with production data volumes and production security contexts. Don't skip it.
Mistake #2: Letting Testers Write Their Own Test Cases
What I Did
On a NetSuite implementation for a manufacturing client, I handed the finance team a blank spreadsheet and said, "Write down how you'll test the month-end close process." I thought it would save time and increase their ownership of the testing.
What Went Wrong
The finance manager wrote nine test cases. All of them were variations of "check that the GL balances". None of them tested:
- Inter-company eliminations
- Foreign currency revaluation
- Accruals and deferrals
- Period lock enforcement
Two weeks after go-live, the first month-end close took four days instead of two because we discovered issues in all four areas that should have been caught during UAT.
What I Should Have Done
Business users know their processes, but they don't always know what needs to be tested in a new system. They test what they're worried about (usually the happy path), not what's most likely to break (edge cases, integrations, system-generated transactions).
The consultant should write the test cases based on the configured functionality, then review them with the client to ensure nothing's missed. It's the consultant's job to know what breaks.
Lesson: Don't outsource test case creation to business users. They'll test the obvious stuff and miss the risky stuff. You write the cases; they validate and execute them.
Mistake #3: Accepting "Tested and Passed" Without Evidence
What I Did
On a Dynamics CRM implementation, the client's sales team marked fifty test cases as "Passed" in the spreadsheet. I checked the spreadsheet. Everything was green. I moved the project to sign-off.
What Went Wrong
Three days after go-live, the sales director asked where the monthly pipeline report was. It was supposed to be automated. It wasn't working. When I asked the tester who'd signed off that test case, they said, "I thought someone else was testing that one."
No screenshot. No notes. No evidence. Just a green tick in a spreadsheet.
What I Should Have Done
Require evidence for every test result. Screenshots, exported reports, system-generated confirmations. If a tester marks something as passed but can't show me proof, it didn't happen.
This also protects you when clients claim "we tested that and it worked" after go-live. If there's no evidence in the UAT records, it wasn't tested properly.
Lesson: "Tested and passed" without evidence is worthless. Require screenshots, exports, or system confirmations for every passed test.
Mistake #4: Not Tracking What Was Actually Retested
What I Did
On a Business Central project, we logged 45 defects during UAT. The developers fixed them. I asked the client's testers to retest the fixes. Two weeks later, I asked, "Are all the defects retested?" They said yes. I believed them.
What Went Wrong
First week post-go-live, three of the "fixed" defects reappeared. When I asked why they hadn't been retested, the answer was: "We thought they were fixed, so we didn't bother checking."
Turns out twelve defects were never retested. Some were marked "fixed" in the tracker without verification. Some were forgotten entirely.
What I Should Have Done
Treat retest tracking as seriously as initial test tracking. Every defect that gets marked "fixed" should have a corresponding retest record with evidence. No exceptions.
Use a proper defect workflow: Logged → Assigned → Fixed → Retested → Closed. If a defect is marked "Closed" without a "Retested" record, it's not actually closed.
Lesson: Fixing a defect and retesting a defect are two different things. Track retests explicitly, or defects will resurface post-go-live.
Mistake #5: Signing Off UAT Before the Client Was Ready
What I Did
On a SAP Business One implementation, we hit the planned go-live date. The test completion dashboard showed 94% complete. Two critical defects remained open, but the project sponsor said, "We'll deal with those after go-live. Let's sign off and move forward."
I signed off UAT.
What Went Wrong
One of the "minor" open defects turned out to block the entire purchasing workflow. The client couldn't raise purchase orders for three days. The other defect corrupted inventory data during goods receipt, which meant stock reconciliation was broken.
We spent the first week post-go-live in crisis mode. The client's operations director sent an email to our MD asking why we'd signed off UAT when the system wasn't ready. I had no good answer.
What I Should Have Done
UAT sign-off means "the system is ready for production use". If critical defects remain open, the system is not ready. Delaying go-live by one week to resolve blockers is better than going live with known issues and spending three weeks firefighting.
The sign-off criteria should be explicit and non-negotiable: 100% test completion, zero critical defects, zero high-priority defects unless formally accepted as risks by the client sponsor in writing.
Lesson: UAT sign-off is not a formality. It's a declaration that the system is production-ready. If it's not ready, don't sign off, no matter what the project timeline says.
What I Learned
These five mistakes cost real time, real money, and real client trust. Every one of them was preventable. Here's the summary:
1. "It works in dev" ≠ "it works in production"
Test everything in UAT, even if developers claim it's working. Production is never identical to dev.
2. Consultants write test cases, clients validate them
Business users test what they're worried about. Consultants test what's most likely to break.
3. Require evidence for every test result
No screenshot = not tested. Evidence protects both the consultant and the client.
4. Track retests as rigorously as initial tests
Fixed ≠ Retested. Defects don't close until someone has verified the fix works.
5. Don't sign off UAT until the system is actually ready
Delaying go-live beats firefighting post-go-live. Every time.
I built LogicHive because these mistakes kept happening, project after project, regardless of which consultancy or which tooling we used. Spreadsheets made it too easy to skip evidence capture. Email chains made it impossible to track retests. Manual status updates meant sign-off criteria were negotiable.
LogicHive forces the right behaviours: evidence is mandatory, retests are tracked separately, sign-off criteria are explicit. It's the tool I wished existed when I was making these mistakes.
Avoid These Mistakes on Your Next Project
LogicHive was built to prevent the five most common UAT failures. Evidence capture is mandatory, retests are tracked separately, and sign-off criteria are enforced automatically.
Written by Reece Hallam
Sales Director
Reece brings over 15 years of experience in ERP implementations, specialising in Business Central and Dynamics 365. He has led UAT programmes for mid-market manufacturing and distribution clients across the UK and Europe.
View all articles by Reece Hallam