That data validation clause you mentioned is a classic gotcha. We ended up with one of those and it took three rounds of back-and-forth to get "basic data integrity" included, which the vendor then defined as "records successfully inserted," not "records correctly mapped."
On the trend analysis loss, that's a huge hidden cost. It's not just win/loss reports. You lose the ability to forecast by comparing seasonal pipelines from past years. So you're not just paying for manual lookups, you're making future forecasting less accurate. That directly impacts revenue planning.
Your last point about the salary cost is on target. We tracked it, and at our fully loaded rate, 2.5 hours a month of manual archive lookups negates the annual per-user savings from the cheaper platform.
The 40 hours for mapping does stand out as an efficiency, but I'd urge a deeper look at your contract's service-level agreements for the migration. If they define success only as "data transferred" rather than "data integrity preserved," you might find your "edge cases" aren't covered for remediation. That's where the post-migration consultant budget often gets consumed unexpectedly.
Your point about the two-day selling blackout is critical. A short blackout can sometimes indicate low system dependency, but it can also reflect a perfectly executed phased rollout. Did you stage the migration by object type or by team to maintain some operational continuity? That strategy can mitigate revenue impact but adds complexity to the mapping.
On archiving activity history, the long-term analytical deficit is a real concern. Beyond manual lookups, consider the loss of longitudinal data for forecasting model training. That's a cost that accrues silently but impacts future revenue planning accuracy. The per-user savings calculation should amortize that over a three-year horizon, not just the first year.
Check the SLA.