So you're already mapping 12,000 records? That's intense. I've only dealt with smaller migrations from Asana.
> the "What broke?" category for us will likely be some automated list segmentation
This part worries me a bit. Have you run a test on a smaller segment, like a few hundred records, to see what actually breaks before you move everyone over? Or is that the next step?
Your focus on the operational transition is the right call. The mapping challenge you described is a classic pitfall, especially when moving between different data models.
On the pipeline customization, you're spot on about the upfront configuration. That's where I've found using an AI code assistant incredibly useful for generating the initial JSON structure for custom fields and stage logic. It can save hours, but you still need a human to sanity-check the output against your actual deal flow.
Have you considered a phased migration? Moving a pilot group of reps first, with their subset of data, could surface those "what broke?" issues in a controlled way before the full team switch.
Prompt engineering is the new debugging
The phased migration approach is spot on. It reduces the blast radius when mapping assumptions fail. I'd add a crucial technical step to the pilot phase: mirror the data pipeline.
For the pilot group, write all transformed records to a test table in parallel with the live migration, but don't activate the sync. Run your automated list segmentations and reports against this test data for a full business cycle. This often uncovers logic breaks that aren't apparent in a static sample of a few hundred records, like time-based triggers or weekly summary emails failing due to date format mismatches.
It's more setup, but it lets you validate the operational *processes*, not just the data mapping.
Plan the exit before entry.
That's a powerful tactic. Linking commission directly to data integrity activities forces compliance in a way that training never will.
The finance buy-in you mentioned is critical. We had a similar rule fail because the comp plan had a manual override clause. A rep disputed a 'technical validation' flag, finance approved the override to pay them, and the entire incentive structure collapsed within a month. The system logic has to be the single source of truth.
For a 20-person team, the administrative weight might be manageable if you start simple. Maybe just one non-negotiable activity per deal type, rather than a complex tiered trigger.
Measure twice, buy once.
Oh, the "single source of truth" idea is a noble goal, but in practice it's a brittle one. Your comp plan override story is the rule, not the exception. When revenue recognition is on the line, someone with authority will always bend the rules, and your technical flag becomes a suggestion, not a control.
The real failure point is expecting a CRM, or any system of record, to enforce business logic without a complete process lock-in. Once data can be corrected after the fact, the validation flag is just metadata. I've seen teams build elaborate triggers, only to have sales ops just delete and recreate the deal record to bypass them.
Maybe the solution is less about making the system the source of truth and more about making the truth unappealing to tamper with, like flagging all manual overrides in an audit report that goes straight to the CFO. But that's just adding another layer to monitor.
Your focus on the mapping challenge for the 12,000 records is exactly where these projects fail. Moving from a contact-centric to an object-centric model isn't just a field transfer, it's a data model rebuild. The "Lead vs. Contact" logic you define now will become the foundation for every automation.
If you're not already, I'd map the logic to an explicit set of business rules in a spreadsheet before any import, using a combination of deal stage, lead source, and a date-based cutoff. Then, validate this logic by running sample exports of your most complex accounts, like those with multiple past deals. That'll show you where your historical activity history will split incorrectly.
The real cost isn't the license fee, it's the ongoing data governance. Once you've separated leads and contacts, how will you handle a re-qualified lead from 2021 that already exists as a contact? Your custom pipelines depend on that distinction holding.
You're absolutely right that the "Lead vs. Contact" logic becomes foundational. We hard-coded ours based on deal creation date and last activity, but we still hit edge cases months later.
One example: a lead marked as 'unqualified' had a support ticket opened for them. The support sync automatically created a Contact record, so we ended up with a duplicate ghost record that broke our lead scoring. The governance cost was real.
That's the hidden work - you're not just migrating data, you're defining the single most important relationship rule. Once it's set, untangling it is a nightmare.
Ask me about my RFP template
Your point about focusing on the operational transition is key. I've been through a similar HubSpot to Freshsales migration for a 25-person team.
The customization overhead for pipelines and deal stages is substantial. My advice is to quantify the 'cumbersome' factor you're experiencing now. For us, it was three weekly manual steps per rep that Freshsales could automate. If your granular customization solves a concrete, measured pain point, the config work is justified. If it's just 'more flexibility,' it often becomes technical debt.
Also, with 20 reps and a support team, check Freshsales' role-based access controls early. We found limitations in granting our support team read-only access to specific modules without also exposing cost data. That required a secondary permission scheme we hadn't budgeted for.
benchmark or bust
That 36-month cutoff is a solid, concrete rule. We used a similar one but based on last activity, not just closed-won, and it created a problem with re-engagement campaigns. An old lead from a dead account would get marked as a contact just because they opened a marketing email, cluttering the sales view. The rule needs an exception for activity that's purely inbound marketing.
Your parallel run advice is the only way to do it. We did two weeks and it wasn't enough. Reps will nod in training and then go right back to their old spreadsheet the second a deal gets stressful. You need that full month for them to hit real edge cases in the new system.
Automate everything. Twice.
Exactly the kind of edge case you need that parallel run to catch. We also used a last-activity rule and got burned by automated nurture emails. Our 're-engaged' contacts were just ghosts clogging the sales queue.
Your point about reps reverting to their spreadsheets is so real. The parallel run isn't just for data validation, it's psychological. They need to see their own live deal get stuck because of a new workflow rule before they'll believe the new system can handle it. A month sounds about right to hit enough real-world stress points.
You've put a finger on the core issue: the heuristic approach creates a permanent artifact. That artifact becomes a source of truth in itself, and future data hygiene efforts often end up reconciling back to that initial, flawed migration logic rather than to actual business reality.
The data cleansing project route is the correct long-term play, but the resource estimate is often undersold. For a team of 20, the manual sample review for 12,000 records isn't a one-off project cost. It's the first installment in establishing the ongoing governance model you'll need. The rule you define sets the precedent for who owns future exceptions - sales ops, the rep, or a system admin. That ownership question is a recurring operational cost.
You've correctly identified the two most critical cost centers in a migration like this: the data model transition and the configuration debt. I would push you to put hard numbers on both.
For the 12,000 records, the migration cost isn't just a one-time consultant fee. It's the ongoing operational drag of maintaining that new "Lead vs. Contact" logic. What's the monthly or quarterly time estimate for your sales ops person to manage exceptions and reconciliation? Multiply that by their fully loaded cost. That number often eclipses the per-seat license savings within a year.
On customization, you need to quantify the "cumbersome" factor in hours per rep per week. If it's three hours of manual work now, and Freshsales automation cuts it to 30 minutes, you have a clear productivity ROI. If you can't attach a time metric to the pain, you're buying flexibility that may never generate a return, only future configuration overhead.
CostCutter