Migrate from Virtual Case Management to HighLevel

VCM clients map directly to HighLevel Contacts. The client's name, email, phone, address, and demographic fields become Contact properties. FlitStack resolves any duplicate email addresses before insertion to avoid HighLevel's duplicate-matching behavior. Phone numbers are normalized to E.164 format, and the original VCM client creation timestamp is stored in a custom field for audit purposes. Duplicate detection uses a combination of email, phone, and name to minimize false positives.

VCM stores address as structured fields (street, city, state, zip, country). These map to HighLevel's street, city, state, postal code, and country contact properties. HighLevel uses a single address block per contact; multi-address VCM clients use the most-recently-updated address. Any secondary address lines in VCM are concatenated to the primary street field using a line break, and no geocoding is performed during migration.

VCM client status values (Active, Inactive, Closed, On Hold) map to a custom pick-list field (Client_Status__c) on the HighLevel Contact. Each VCM status label is matched to an equivalent HighLevel pick-list value; unrecognized statuses are preserved as-is in the custom field for admin review.

VCM case files are the core object with no direct HighLevel equivalent. FlitStack creates a HighLevel Custom Object named 'Case' and maps fields to custom fields on that object. The Custom Object is associated to the Contact (client) via a one-to-many relationship in HighLevel's Custom Object schema. Each Case record also stores the VCM case ID and maps any case priority values to a custom pick‑list on the Case object.

VCM's auto-generated case ID number is stored as a text custom field (Case_ID__c) on the Case Custom Object. This preserves traceability back to the source system and supports lookups during the delta-pickup phase. If a VCM case ID contains non‑numeric characters, they are preserved as‑is. The field is indexed in HighLevel to speed up lookups, and any duplicate IDs are flagged for manual resolution before the final migration run.

VCM case statuses (Open, In Progress, Pending, Closed, Archived) map to a custom pick-list field (Status__c) on the Case Custom Object. Each value is mapped one-to-one; any VCM statuses not found in the target pick-list are added before migration runs.

VCM service categories (housing, mental health, legal aid, employment, etc.) map to a custom pick-list field (Service_Type__c) on the Case Custom Object. Value-by-value mapping ensures no drop-down mismatch in HighLevel after import. If VCM includes a category not yet in the pick-list, FlitStack adds it automatically before the migration run, and the original category label is preserved in a separate text field for audit.

The date a VCM case was opened is stored as a Date field (Opened_Date__c) on the Case Custom Object. HighLevel date fields accept ISO 8601 format; FlitStack converts VCM date strings before insertion. If the opened date is missing, the field is left null and the record is flagged for manual review. All dates are normalized to UTC midnight to align with HighLevel's date storage conventions.

VCM target completion dates map to a custom Date field (Due_Date__c) on the Case Custom Object. Null values in VCM are preserved as null — not defaulted — so HighLevel reports reflect the same data completeness. If a due date falls in the past, it is retained as-is to preserve the original timeline, and any due dates that are missing are left null.

VCM case notes and service plan text map to a multi-line text custom field (Notes__c) on the Case Custom Object. Rich-text formatting from VCM is stripped to plain text to avoid HighLevel field-type compatibility issues. If a note exceeds HighLevel's 10,000‑character limit, it is split across multiple notes records with a sequence indicator.

VCM referral records (referrer name, agency, date, source channel) map to a second Custom Object named 'Referral' associated to the Case Custom Object. HighLevel's Custom Object relationships handle the one-case-to-many-referrals cardinality. Each Referral record also stores a status pick‑list and a notes text field, and the original VCM referral identifier is preserved in a custom field for cross‑system reference.

VCM referral source values (hospital, school, court, self, community organization) map to a custom pick-list field (Source__c) on the Referral Custom Object. Unknown source labels are added as new pick-list values before migration. If a referral lacks a source, a default 'Unspecified' value is used, and any 'Other' free‑text entries are stored in a secondary text field (Source_Other__c) for later categorization.

The date a referral was created in VCM maps to a Date field (Referral_Date__c) on the Referral Custom Object. Preserves the original referral timestamp for outcome tracking and reporting continuity. If the VCM date is missing, the field is left null, and the record is flagged for manual review. All dates are converted to UTC midnight for consistency with HighLevel's date storage.

VCM agencies and service providers map to HighLevel Companies. Each provider's name, address, phone, and email become a Company record. HighLevel's Contact-to-Company relationship then links the client Contact to the serving Agency Company. FlitStack checks for duplicate Company names and merges them if needed, and any VCM agency custom fields are added as custom fields on the Company record.

Any VCM custom fields beyond the standard set are created as custom fields on the appropriate HighLevel object (Case Custom Object, Contact, or Referral). Field type mapping follows: VCM text → HighLevel text, VCM number → HighLevel number, VCM date → HighLevel date, VCM pick-list → HighLevel pick-list.

VCM file attachments and uploaded documents are downloaded and re-uploaded to the associated Case Custom Object in HighLevel. File size limits match HighLevel's upload constraints; oversized files are flagged for manual handling before the migration run. FlitStack preserves the original file name and adds a prefix with the VCM case ID to avoid naming conflicts, and duplicate files are detected by hash to prevent redundant uploads.

VCM case-management workflows and referral-trigger automations have no equivalent in HighLevel's Workflows builder. FlitStack exports workflow definitions as a structured reference document for the HighLevel admin to rebuild using HighLevel's trigger-action model. The export includes trigger events, action steps, condition logic, and any custom field references, along with a visual flow diagram and notes on priority ordering.