We've watched enough ERP rollouts — our own and others' — to have an opinion that's a little uncomfortable to state plainly: when a new system gets abandoned within a year, the software is rarely the actual reason, even when it gets blamed as the reason. The real causes are almost always process ones, and they're predictable enough that we think they're worth saying out loud.
"The team went back to spreadsheets" almost always has one of three causes
Historical data didn't come with them. If go-live means starting from a blank slate — no past deals, no account history, no open invoice status — every conversation for the first few weeks starts with "let me check the old system." That's not a minor inconvenience; it's a structural reason to keep the old system open, and once it's open "just to check," it's open for everything.
Nobody configured it for how the team actually works. A generic rollout — modules switched on with default settings, no adaptation to the business's actual approval chains, territories, or terminology — produces a tool that technically works but doesn't fit. People don't abandon tools that fit their workflow. They abandon tools that force them to work around the tool's assumptions instead of their own.
Training happened once, at launch, for people who joined later. Six months after go-live, half the team that's using the system wasn't there for the original training. If there's no ongoing onboarding process, new hires learn an informal, inconsistent version of "how we use the system" from whoever happens to show them — and that version drifts further from correct usage every time it's passed along.
The uncomfortable part: this is true regardless of the software
We'd say this even if we had no stake in it. A well-designed platform rolled out with a blank data slate, no workflow adaptation, and one-time training will fail the same way a poorly-designed one would. The software quality determines the ceiling of what's possible; it doesn't determine whether the rollout actually succeeds, because success is mostly determined by decisions made during implementation, not by features.
What "adoption erosion" looks like month by month
Illustrative pattern, not a specific study — the shape of the curve is what matters here, not the exact numbers.
A rough pattern we've seen repeat across rollouts that skip data migration, configuration and ongoing training, versus ones that don't:
| Time since go-live | Rollout that skipped the fundamentals | Rollout that didn't |
|---|---|---|
| Week 1 | ~90% daily active use — everyone's still in launch mode | ~90% daily active use |
| Month 2 | ~65% — "let me just check the old system" becomes routine | ~85% — historical data means there's no old system to check |
| Month 6 | ~40% — new hires learn an informal, drifting version from peers | ~80% — structured onboarding keeps usage consistent |
| Month 12 | Often back to spreadsheets for the parts that felt like friction | Still the primary system of record |
The drop-off in the left column rarely has one dramatic moment behind it. It's a slow erosion, one workaround at a time, until by month 12 "we tried an ERP and it didn't stick" becomes the story — when the actual cause was decided in the first few weeks of implementation, not by anything the software did wrong later.
What we think actually works
Migrate the history, not just start clean. Even messy historical data, cleaned up and imported, beats a blank system — because it means day one doesn't feel like starting over.
Configure before you launch, not after complaints arrive. Discovery — actually mapping how a team works before switching modules on — takes real time upfront, but it's cheaper than re-configuring a system people have already decided doesn't fit.
Treat training as ongoing, not an event. New hires need the same structured onboarding six months after go-live that the original team got on day one — otherwise "how we use the system" degrades into tribal knowledge.
Why we built implementation this way
This is a large part of why DexVee's implementation process treats data migration and role-based training as core parts of the engagement rather than optional add-ons — not because it's a nice thing to offer, but because we've watched what happens when those steps get skipped, on our own systems as much as anyone else's.
If you're evaluating any ERP — DexVee or otherwise — ask harder questions about the implementation process than about the feature list. The feature list mostly determines what's possible. The implementation process mostly determines what actually happens.