This Medicare insurance operation had over 1,600 contacts spread across spreadsheets, and the real problem was never the raw number of records. It was the relationships between them. Policy holders, beneficiaries, agents, carriers, and nine other relationship types all existed and mattered, referral chains and family connections that decide who gets contacted about what and why, but nobody had a system that could actually show how any of it connected. The team knew the relationships were there. They just had no way to see them in one place.
A data model built for the complexity that was actually there
A standard CRM does not handle this kind of relational depth out of the box, and the tempting shortcut is to simplify the model until it fits the software instead of the business. We designed a relational CRM mesh inside GoHighLevel instead, building a data structure for the complexity this operation actually had. Each of the 13 relationship types was mapped and connected so a team member could open any single contact and see its full web of context, not just its own record in isolation.
Before touching a single piece of real client data, we delivered a working proof of concept in one day, so the client could check the model against their own contacts and confirm it actually captured the relationships correctly. Only once that was approved did the real migration begin.
What made the actual migration hard
The legacy system had no direct migration path to GoHighLevel, and moving data between the two surfaced problems that do not show up until you are elbow-deep in the real records. GoHighLevel’s own API would sometimes return a success response while quietly discarding the update if a field was submitted in the wrong format, so a field that looked saved a moment ago would come back empty later, with no error to explain why. Contacts that shared an email address or phone number would get merged automatically using whichever record was processed last, which meant a detailed, well-documented profile could be silently overwritten by a thin, mostly-empty one that happened to come later in the batch. We caught this and preserved the richest version of each contact instead of letting the platform’s default merge logic decide.
The relationship types themselves ran into a hard limit on how many distinct connection labels the platform allows between two contacts, fewer than the 13 types this operation actually needed. Working around a platform ceiling like that without losing any of the real relationship data was its own piece of the puzzle, solved with careful label design rather than dropping any of the categories the client depended on.
Matching people to the right Medicare plan automatically
Each contact also needed to be matched to their record in the Medicare enrollment system the operation uses for plan matching, work that used to mean a manual lookup per contact. We automated it with a layered matching approach: try the Medicare identifier first, fall back to a name-and-date-of-birth match if that comes up empty, and only create a new record if neither approach finds an existing match. What used to be a manual step per contact became part of the migration itself.
What moved over, and what it meant
Once the model was validated, we migrated 1,574 contacts, 1,222 insurance policies, and 32,279 notes into the new structure, with a full backup maintained throughout the process and zero records lost along the way. The policies came in as structured, searchable records instead of details buried inside a contact’s note history, and the notes carried their original timestamps, so the team’s history with each client stayed intact rather than looking like it all happened on migration day. Work that would have meant months of manual re-entry, checking each relationship by hand, was instead validated and moved with nothing left behind.
The team now has one place where the full relational picture is visible and navigable, which is the thing spreadsheets could never actually give them no matter how carefully they were maintained.
If your operation tracks relationships that standard CRM setups cannot hold, our CRM integration work is built for exactly this kind of complexity.