Six months after a system goes in, somebody in accounts is still keeping their own spreadsheet. Not out of stubbornness -- because the last time they relied on the system, it was wrong, and they were the one who had to explain it.
That spreadsheet is the most important piece of feedback the project will ever get, and it is usually treated as a compliance problem rather than a diagnosis.
What the shadow copy tells you
It tells you the system is not trusted for something specific. Rarely for everything. Usually there is one number, one report, or one situation where it produced a wrong answer at a bad moment.
People are quite rational about this. If a tool has burned you once in front of your manager, you will keep a backup, and you will keep it indefinitely. The cost of maintaining the spreadsheet is much lower than the cost of being wrong again.
So the question is never "why are you not using the system properly". It is "what happened".
The usual causes
The migration was incomplete. Historical records came across partially, or with dates and categories mangled. Every time somebody looks up something from before the switch, they find a gap. After a few of those, they stop looking.
A report disagrees with reality and nobody resolved it. The system says stock is forty and the shelf has thirty-one. Instead of finding out why, everyone quietly agrees the system is unreliable and works around it.
The process changed but the system did not. The business started doing something new, the system has no place to record it, so it gets recorded somewhere else. Now two places hold the truth.
Nobody was trained on the awkward parts. Staff learned the everyday path and never learned how to handle a return, a partial payment, or a correction. So those go in the spreadsheet.
Permissions block the obvious. Someone needs a number they cannot see, so they maintain their own copy of it.
Why it compounds
One private spreadsheet is an inconvenience. The problem is that it spreads.
Once one person keeps their own figures, others start asking that person rather than the system, because they know that copy is maintained. The spreadsheet becomes the real system, held by one individual, on one laptop, with no backup and no history. You have paid for software and are running on a document.
At that point the business has acquired a single point of failure it did not have before the project started.
Getting trust back
Ask, without blame. Sit with whoever keeps the parallel copy and ask what it holds that the system does not. Frame it as a fault in the system, because it is. If they think they are in trouble, you will get a promise to stop rather than an explanation.
Fix the specific thing. Almost always there is one concrete cause, and it is usually fixable in days. Repair the migrated data. Reconcile the disagreeing report and explain why it disagreed. Add the missing field. Grant the missing permission.
Reconcile in public. When the stock count does not match, find out why in front of the people who use it. One properly explained discrepancy does more for trust than any amount of encouragement.
Retrain on the exceptions, not the basics. Everyone knows the everyday path by now. The training that matters covers refunds, corrections, part-payments and the month-end.
Then agree it is the only record. Not before. Mandating single-source discipline while the system is still wrong is how you get people hiding the spreadsheet rather than closing it.
The prevention
Most of this traces back to two decisions made at the start.
Migrating data without anyone checking it against the old records, and training people on a demonstration rather than on their own real work with their own real awkward cases.
Both are unglamorous, both take days rather than hours, and both are the first things cut when a project runs late. They are also the difference between a system people rely on and an expensive piece of software running alongside the spreadsheet that actually holds the business together.