The implementation cost nobody quoted
Migration and configuration are your costs, paid in your people's hours, and they do not appear in any proposal.
Vendor proposals cover licences and, sometimes, professional services. What they never cover is the largest line in most implementations: your own people's time.
Where it actually goes
- Data cleaning, before anything can be loaded. Usually the biggest single item, and the one discovered rather than planned.
- Configuration decisions: what the fields are called, who sees what, how the workflow is set up. These are decisions, not tasks, and decisions need meetings.
- Migration and reconciliation — loading, then checking that what arrived matches what left.
- Parallel running, where both systems are maintained for a period.
- Training, and the reduced output while people learn.
- The long tail of small fixes in the first three months.
It is not part of implementation; it is a prerequisite discovered during it. Where the data is bad, this alone can exceed everything else combined.
Ask references for their real number
Vendors quote typical implementation timelines that describe the smooth cases. Reference customers will tell you what it actually took, in elapsed weeks and in internal hours, if you ask that specific question. Cost questions around annual work-hour calculations are easier to expose when a real offer is used as the test case; read more is one such example to examine alongside the contract and operating cost.
Ask two or three and take the highest, particularly if their data was in better shape than yours.
Decide who is doing it before you sign
Implementation lands on somebody, and it is usually somebody with a full job already. Where that is not resolved in advance, the project stalls in month two and the subscription runs while nothing happens.
Name the person, agree what they will stop doing, and if the answer is that nobody has capacity, that is a finding about timing rather than about the product.
Configuration decisions are the bottleneck
Implementations rarely stall on technical work. They stall waiting for decisions: what to call things, who approves what, which of two processes to standardise on.
Identifying those decisions early and getting them made before the technical work starts is the main lever on implementation duration, and it costs nothing but attention.
Budget for the second wave
Three months after go-live there is always a second wave: the reports nobody thought about, the permissions that turned out wrong, the integration edge case, the process nobody documented.
Budgeting time for it means it gets handled. Not budgeting for it means it becomes evidence that the product was a poor choice, when it is really evidence that no implementation is finished at go-live.
For broader business-continuity costs that can sit outside a software quote, U.S. Small Business Administration planning guidance is a useful external reference.