Over thirty years of implementing accounting and ERP software, certain mistakes show up again and again. They are not random. They follow patterns, and they cost businesses far more than the software itself ever did. Here are the five I see most often, and what to do instead.
1. Letting the software dictate the workflow
The most damaging mistake is treating the software as the master and your business as the apprentice. Teams will sit through a training session, hear how the platform expects a sales order to flow, and then quietly reorganize their entire process to match — even when the platform's default flow makes no sense for how their business actually works.
The result is a team that resents the system, processes that take longer than they did before, and an implementation that everyone privately considers a failure even though nobody says so out loud.
Good implementations work the other way around. We sit with the team, watch how the work actually happens, understand why it happens that way, and then configure the software around their workflow. Both Spire and Adagio are flexible enough to support how your business actually operates. The trick is doing the listening work first.
2. Trying to move all the data
This one is counterintuitive because it sounds responsible. Surely you want all your historical data in the new system, right? Wrong, most of the time.
Moving twenty years of transaction history into a new platform makes the new platform slow, clutters the views with information nobody uses, and introduces dozens of edge cases that complicate the migration unnecessarily. Old transactions from 2014 will not reconcile to today's chart of accounts, because the chart of accounts has evolved.
The right approach is usually: bring over open transactions, current-year activity, and master data. Archive the rest in a read-only export of the old system that anyone can search if they need to. You keep the history without dragging it into the new platform's working memory.
3. Skipping parallel runs
A parallel run means operating both the old and new systems side by side for one full close cycle. Same transactions go into both. At the end of the period, you reconcile.
It feels redundant. It is the single most important step in any migration.
Parallel running is where you find the configuration mistakes, the data mapping issues, and the workflow gaps that will absolutely show up in production but are dramatically cheaper to fix in parallel than after go-live. Every implementation I have seen go badly skipped this step. Every implementation I have seen go smoothly did it.
4. Underestimating training
Companies will spend six figures on software and implementation services and then try to train the team in a single afternoon. The result is predictable. People do not know the workflows. They make mistakes. They develop workarounds. Within three months, the system has been bent into shapes the implementer never intended, and nobody remembers why.
Training has to be role-specific, hands-on, and spread over time. Not a single session. A series. The AP clerk learns AP. The order desk learns order entry. The controller learns the close process. Each role walks through their actual workflow, with their actual data, until they can do it without hesitation.
Then — and this is the part people skip — there is a follow-up two weeks later, after the team has been using the system in production. Questions have come up. Workarounds have emerged. The follow-up session catches these before they calcify into bad habits.
5. Letting the implementer disappear after go-live
The cruellest pattern in our industry is the implementer who shows up for the project, hits go-live, collects the final invoice, and is never seen again. This is structurally the worst possible model, because the questions and issues that matter most show up two months, six months, or two years after go-live — when the team has internalized the platform enough to ask hard questions.
If your implementer is not still available a year later, you do not have a partner. You have a vendor. The relationships that produce great long-term outcomes are the ones where the implementer is on speed-dial five years on, because they understand your business, your configuration, and your history. That continuity is worth far more than the initial implementation fee.
What these all have in common
If you read these five mistakes together, a pattern emerges. The mistakes that cost businesses years are not technical. They are relational and procedural. Listening properly. Migrating thoughtfully. Validating carefully. Training deeply. Staying available.
The technical work is the easy part. The discipline around it is what determines whether the implementation succeeds.
