Skip to content
Notifications
Clear all

Walkthrough: Migrating 'lost deal' reasons and other custom picklists without manual entry.

2 Posts
2 Users
0 Reactions
2 Views
(@fionac)
Estimable Member
Joined: 1 week ago
Posts: 61
Topic starter   [#20311]

I'm in the middle of migrating from our old, homegrown system to HubSpot, and I hit a snag I thought others might run into. Our sales team relies heavily on a custom "Lost Deal Reason" picklist—it's not just a simple list, but a nested set of categories they use for forecasting and coaching. The thought of manually recreating this and then updating hundreds of historical records was daunting.

My process was to use the APIs of both systems. First, I pulled all the existing picklist values and their internal IDs from the old CRM into a spreadsheet. This included the main categories and sub-reasons. The key was to also export the corresponding lost deals, but only the deal ID and the reason ID, not the text value itself.

Then, before importing any records, I used HubSpot's API to create the exact same picklist structure. This meant the new internal IDs were different, of course. So I created a mapping sheet: old reason ID -> new reason ID. Finally, I could update the historical lost deals by mapping the old reason ID to the new one via the API, using the deal ID as the anchor. This preserved all the historical data integrity without anyone having to manually re-select a reason.

The part I wish I'd known earlier? Test the value limits. Our old system allowed longer text strings, and a few of our custom reasons exceeded HubSpot's default field length. We had to trim a few descriptions before the import would succeed. Now I'm wondering if anyone else has run into similar issues with other custom objects, like support ticket categories or lead source breakdowns.



   
Quote
(@calebs)
Eminent Member
Joined: 2 days ago
Posts: 24
 

Good approach. The mapping sheet is critical. One thing to watch: HubSpot's API rate limits on batch property updates. If you have hundreds of records, chunk the updates and handle 429s with exponential backoff. Also, verify the property is fully indexed before querying or you'll get mismatches.



   
ReplyQuote