Migrate from Giva eHelpDesk to HighLevel

HighLevel has no native ticket object — Giva tickets require custom pipeline and field mapping

Giva eHelpDesk is built entirely around tickets: every support interaction is a Ticket record with status, priority, request type, category, and subcategory fields. HighLevel has no native ticket or issue-tracking object — its primary CRM records are Contacts, Companies, and Opportunities. Migrating Giva tickets to HighLevel therefore requires creating a custom Opportunity pipeline (with stages named after Giva ticket status values like Open, Pending, Resolved, and Closed), creating custom fields on the Opportunity object for Giva priority and request type, and storing the Giva ticket body as a Note on the Opportunity. This is not a 1:1 field map — it is a schema transformation that must be planned before any data lands in HighLevel.

HighLevel API rate limits cap migration throughput for large Giva exports

HighLevel's Sub-account API tokens are limited to 100 requests per 10 seconds and 200,000 requests per day per sub-account. Giva does not publish rate limits in its public documentation, but a large Giva export with 5,000+ tickets, 2,000+ customers, and 500+ assets will generate hundreds of API calls during the migration. The HighLevel rate limit is the binding constraint — it governs how fast we can write Opportunities and Custom Object records during the migration run. We implement exponential backoff on 429 responses and segment the migration into batches to stay within the 100 req/10s window. Customers with very large Giva datasets should budget for a longer migration window or consider a staged migration (sample first, then bulk).

Giva knowledge-base articles have no HighLevel equivalent and cannot be natively imported

Giva's KnowledgeBaseArticle object stores internal and customer-facing knowledge base articles with publish status, categories, and rich-text body content. HighLevel has no knowledge-base, article, or self-service content object. Giva KB articles cannot be natively imported into any HighLevel standard object without data loss or rework. FlitStack AI exports Giva KB articles as tagged Notes on the related Contact or Company record, tagged with a system tag (Giva_KB_Export) so they are identifiable. Full knowledge-base functionality — categories, publish status, search, and self-service portals — must be rebuilt in HighLevel using HighLevel's Courses, Campaigns, or a third-party knowledge-base integration.

HighLevel HIPAA compliance is an add-on, not a default feature — PHI migration requires verification

Giva eHelpDesk explicitly markets HIPAA and HITECH compliance as a core, built-in feature of every plan — it is designed for healthcare organizations, hospitals, and regulated industries that handle protected health information (PHI) in tickets, customer records, and attachments. HighLevel offers HIPAA compliance as a paid add-on available only on Enterprise plans (not Starter at $97/month or Unlimited at $297/month). If Giva tickets or customer records contain PHI (patient names, medical record numbers, diagnosis text), migrating them to a HighLevel sub-account that does not have the HIPAA add-on activated would create a compliance violation. We verify the destination HighLevel account's HIPAA add-on status before migrating any records that may contain PHI.

Giva asset management requires HighLevel Custom Object API setup before migration runs

Giva's Asset object stores hardware and software inventory linked to tickets — with fields for asset name, type, serial number, location, assigned user, and maintenance history. HighLevel has no Asset or inventory management object. Migrating Giva assets requires using HighLevel's Custom Objects API to define a Giva_Asset custom object with a schema that includes fields for name, type, serial number, location, and an assigned-contact lookup. This schema definition must be completed before any Giva Asset data can be loaded. If the Giva instance has multiple asset types (hardware, software, contracts), each may require a separate custom object or a type discriminator field within a single custom object — this decision must be made during migration planning.