Migrate from GAIA.law to Microsoft Dynamics 365 Sales

Contract-centric schema requires custom table creation before data lands

GAIA.law's entire data model orbits the Contract object — there is no standard Dynamics 365 entity that captures contract name, counterparty, effective date, expiration, value, type, and e-sign status in one record. FlitStack AI creates the Contract__c custom table on Dataverse with all mapped fields before migration begins. Dynamics 365 Sales Professional limits custom tables to 15; Enterprise removes this cap. If your GAIA.law instance uses more than 15 custom contract properties, you must be on Dynamics 365 Sales Enterprise before migration or FlitStack will surface the overflow fields for your admin to prioritize.

Workflow and approval-chain definitions cannot migrate — they must be rebuilt in Power Automate

GAIA.law's approval chains, deadline reminders, and stage-gating rules are a purpose-built workflow engine specific to legal operations. Dynamics 365 Sales has no native workflow engine — all automation runs through Power Automate. FlitStack AI migrates data only; workflow definitions are exported as a structured JSON reference file that your Power Automate team uses to rebuild the logic. The JSON names every workflow trigger, approver, condition, and SLA metric. Legal teams frequently underestimate this rebuild effort; FlitStack includes a workflow inventory as part of the migration plan deliverable so the rebuild scope is visible before go-live.

Dataverse API rate limits cap bulk migration throughput

Dynamics 365 Sales runs on Dataverse, which enforces 100,000 API requests per 24 hours per user license pool. GAIA.law contract exports with large attachment payloads can exceed single-batch limits. FlitStack uses Dataverse Bulk API (ExecuteMultiple requests) rather than row-by-row API calls to maximize throughput within the limit. For estates with over 50,000 contracts or high-resolution document attachments, we phase the migration into tranches and run delta pickups between tranches. Pre-migration API audit confirms your Dynamics 365 environment's remaining quota before the migration run starts.

E-signature status is a reference field in Dynamics 365 — not native tracking

GAIA.law tracks e-signature lifecycle states (Sent, Viewed, Signed, Declined, Expired) as first-class record properties. Dynamics 365 Sales has no e-sign status field on any standard entity. FlitStack stores the last-known e-sign status as a custom pick-list field (ESign_Status__c) on Contract__c and the status-change timestamp as ESign_Timestamp__c. The current state of any in-flight signature at migration time is preserved, but Dynamics 365 will not automatically update these fields — a Power Automate flow or third-party e-sign integration (DocuSign, Adobe Sign) must be re-connected post-migration to keep status current.

Multi-party contracts require N:1 split or junction table

GAIA.law supports N:1 and N:N party-to-contract relationships natively, allowing a single contract to have multiple counterparties of different types. Dynamics 365's Contract__c custom table can hold only one primary AccountId lookup. For contracts with multiple counterparties, FlitStack maps the primary (first-listed) counterparty as the AccountId lookup and surfaces additional parties as a Contract_Party__c junction custom table with role labels. Your admin decides whether to map all parties or collapse to the primary counterparty based on your Dynamics 365 reporting requirements.