Migrate from Legl to HubSpot

Legl workflow definitions do not migrate to HubSpot Workflows

Legl Workflows encode legal-specific automation logic — AML escalation triggers, client onboarding state machines, CDD review sequences, and internal escalations — built on Legl's own workflow engine. HubSpot Workflows are a separate automation layer with a different event model, trigger syntax, and action library. The logic encoded in Legl workflow definitions cannot be ported automatically. We export each Legl workflow as a JSON definition and deliver a rebuild-reference document that maps Legl workflow steps to equivalent HubSpot Workflow triggers and actions, but the automation rebuild must be done manually by a HubSpot admin or partner.

HubSpot custom objects require Pro or Enterprise tier — Starter and Basic cannot host Legl compliance data as separate objects

HubSpot custom objects (where we would place Legl RiskAssessment, Payment, and EngageRequest as standalone objects) are only available on HubSpot Sales Hub Pro, Enterprise, and the full CRM platform tiers. Legl migrations targeting HubSpot Starter or Basic tiers require Legl compliance data to live as custom properties on the standard Contact, Company, and Deal objects instead. This reduces the schema clarity of the migrated data and may require consolidating multiple Legl record types into a smaller set of HubSpot properties. We confirm the destination HubSpot tier before building the migration plan.

Legl API rate limit of 3,600 requests per hour constrains extraction speed for large matter histories

Legl's API enforces a sustained rate limit of 3,600 requests per hour with a burst ceiling of 120 requests per minute. For migrations involving thousands of Legl EngageRequests, RiskAssessments, and historical Payments, pagination through Legl's list endpoints (GET /listEngageRequests, GET /listRiskAssessments, GET /listPayments) must respect this limit. We implement request throttling with exponential backoff and use Legl's sandbox environment (api.sandbox.legl.com) to validate the full extraction payload before production runs, avoiding repeated production API calls that could exhaust the rate limit during planning.

HubSpot lifecycle_stage is one-directional — Legl onboarding progress cannot preserve its full state machine in HubSpot

HubSpot's lifecycle_stage property only moves forward on a contact record; there is no native way to represent a multi-branch legal onboarding state machine (Client Intake → ID Verification → Risk Review → Matter Opened → Ongoing Monitoring) as HubSpot lifecycle stages because HubSpot lifecycle is a single linear dimension. Legl onboarding states that branch or loop cannot be accurately represented in HubSpot's flat lifecycle_stage pick-list. We map the final Legl onboarding state to a HubSpot lifecycle_stage value and preserve the full state history as a custom text property (onboarding_history__c) for audit and reference, but the branching logic must be rebuilt as HubSpot Workflows.

Legl sanctions and AML data contain sensitive personal information that requires HubSpot field-level security configuration

Legl SanctionsReport and RiskAssessment records contain personally identifiable information used for AML compliance — sanctions check results, reviewer decisions, and CDD data. When this data migrates to HubSpot custom properties on Company and Contact records, HubSpot admins must configure field-level permissions to restrict visibility to appropriate roles, since HubSpot's default sharing model makes all CRM properties visible to all users with record access. We flag sensitive Legl fields in the migration plan and document the HubSpot field-level security settings required post-migration.