Step-by-step: How we migrated from Zendesk Sell to Close.com in one weekend.

Alright, let me start by saying this: I've been through enough infrastructure migrations to know they're never "just a weekend project." But for our sales team, we managed to pull off the Zendesk Sell to Close.com migration with a hard cutover in a 48-hour window. It was like coordinating a major, zero-downtime database migration, but for human workflows.

The primary drivers were cost and API limitations. Sell's API was becoming a bottleneck for our custom reporting and automation. Close.com's API was more flexible, but the data models were *very* different. Our main goal was zero data loss for active deals and contacts, and minimal disruption to the sales team's Monday morning.

Here's the high-level playbook we followed:

**Phase 1: The Mapping (2 weeks out)**
This was the bulk of the work. We exported sample data from Sell and mapped every field to Close.com. The biggest gotcha? Sell's "Full Contact" record vs. Close.com's separate Lead/Contact/Organization model. We had to write a script to normalize and split that data. We also had to decide what to do with custom fields that had no direct counterpart—some were dropped, others were combined into notes.

**Phase 2: The Dry Run (1 week out)**
We created a sandbox account in Close.com and ran a full migration of a subset of our data (about 10% of active records). This wasn't just about the data; it was about testing the import automation and validating that our sales folks could still do their jobs. We found issues with date formats (timestamps in Sell vs. date fields in Close) and some HTML in notes not rendering correctly.

**Phase 3: The Cutover (The Weekend)**
We communicated a hard freeze on all Sell data entry starting Friday 5 PM. The migration script ran in three stages:
1. Contacts, Leads, and Organizations.
2. Opportunities (deals) with linked relationships.
3. Activities (calls, emails, notes).

We used the Close.com Bulk API with careful rate limiting and retry logic. The script logged every record creation with a mapping of old Sell ID to new Close ID—this was crucial for the rollback plan.

```python
# Simplified example of our idempotent record creation function
def create_or_update_contact(contact_data, id_map):
# Use a custom field to store the original Sell ID
external_id = contact_data['sell_id']
# Check if we already migrated this record in a previous attempt
existing = search_close(f"custom.external_id:{external_id}")
if existing:
return update_record(existing['id'], contact_data)
# Otherwise, create new
new_record = create_in_close(contact_data)
id_map.write(external_id, new_record['id'])
return new_record
```

**What Broke (and how we fixed it)**
* **Activity Timelines:** The order of some notes/emails was off because we relied on creation timestamps alone, not modification times. We had to adjust the script to use the last updated timestamp for sequencing.
* **File Attachments:** These had to be migrated separately via a background job post-cutover, as they timed out the main migration. We told the team some attachments might be unavailable for a few hours Monday.
* **Webhook Dependency:** Some internal dashboards broke because they were still listening for Sell webhooks. We had to run a dual-listener for a week to catch stragglers and replay events.

**What I Wish We Knew**
The Close.com UI has limits on bulk actions that aren't immediately apparent from the API docs. We hit a wall trying to bulk update certain fields post-migration, which added manual work. Also, we underestimated the training needed for the new workflow—even a "better" UI has a learning curve that impacts velocity for a week or two.

If you're planning a similar move, my advice is to treat your CRM data like a production database. Have a rollback script ready (we didn't need it, but it was a lifesaver for my anxiety), and plan for at least a week of elevated support post-migration for those edge cases you *will* miss.

-- nightowl