Migrate from CDK Global to HighLevel

CDK customer records map to HighLevel Contacts. CDK's customer is not a standalone entity by default — it is linked to a vehicle. FlitStack extracts the customer sub-record separately and creates a HighLevel Contact, preserving name, email, phone, and address fields. Original CDK create dates are preserved as a custom datetime field since HighLevel's createdAt is set at migration time.

CDK stores address line, city, state, postal code, and country as customer sub-fields. These map to HighLevel's address fields on the Contact object. HighLevel stores address as a structured object with street, city, state, postalCode, and country sub-fields — FlitStack maps each CDK address component to the corresponding sub-field by name.

CDK customer email maps directly to the HighLevel Contact email field. FlitStack runs format validation on each email address during staging and flags any malformed entries for admin correction before the migration commits. If a contact has multiple email addresses, the primary address becomes the Contact email while additional addresses are stored in a custom text field for reference.

CDK phone and mobile phone fields map to HighLevel phone and mobilePhone fields respectively. If CDK stores multiple phone types (work, home, cell) as labeled fields, the primary labeled phone becomes HighLevel phone and others are stored as custom fields.

CDK vehicle inventory — VIN, year, make, model, trim, mileage, stock number, lot location — has no standard HighLevel equivalent. FlitStack creates a HighLevel Custom Object named Inventory and maps CDK vehicle fields to custom fields on that object. The Inventory custom object links to the Contact record via a relationship field so each vehicle is traceable to its owner.

CDK deal jackets (sales deals, F&I products, service deals) map to HighLevel Opportunities. Deal amount, stage, and close date map to HighLevel's amount, stage, and closeDate fields. CDK's deal name becomes the HighLevel Opportunity name. Deal owner is resolved by email match against HighLevel users.

CDK deal stages (Lead, Presentation, Negotiating, Sold, Delivered) map to HighLevel pipeline stages. Each CDK stage name maps to a corresponding HighLevel stage by value. If CDK has custom stage names, FlitStack creates matching stages in HighLevel's pipeline builder and maps them one-to-one before migration validation.

CDK links a customer to a vehicle (one customer can have multiple vehicles). In HighLevel, the Inventory custom object links to the Contact via a relationship field. FlitStack creates the relationship records during migration so the Contact's vehicle history is visible on the contact record and each Inventory record is traceable to its owning Contact.

CDK F&I products (extended warranties, GAP coverage, service contracts) attached to a deal have no standard HighLevel equivalent. FlitStack maps F&I product names, types, and amounts to custom fields on the HighLevel Opportunity record — product_type__c, product_name__c, product_amount__c — and creates a pick-list for F&I product categories so filters and reporting work in HighLevel.

CDK engagement logs (calls, notes, emails) attach to customer or vehicle records. These map to HighLevel Tasks linked to the Contact record. FlitStack preserves the original activity date, owner (resolved by email), and subject. Task type is set to 'Call' for phone logs, 'Note' for written engagement records, and 'Email' for email interactions.

FlitStack stores CDK's internal record ID on every migrated record as a custom field (cdk_id__c) on both Contact and Inventory custom object. This field enables delta-run de-duplication, prevents duplicate record creation on re-migration, and gives your admin a traceability anchor for auditing without querying CDK's API again.

HighLevel's createdAt timestamp is set when the record is inserted in HighLevel, not when the record was created in CDK. FlitStack preserves the original CDK created date as a custom datetime field (original_create_date__c) on Contact and Inventory so historical reporting continuity is maintained and CSAT or tenure calculations are accurate after migration.