Migrate from Clarra to Microsoft Dynamics 365 Sales

Dynamics 365 Sales Professional caps custom tables at 15 — enterprise-tier licensing required for full custom object model

Clarra setups with more than 15 distinct custom object types (e.g., separate case types for litigation, corporate, IP, employment) will exceed the Sales Professional ceiling once each type needs its own table in Dataverse. The 15-table limit includes both standard entities that have been customized and fully custom tables. We audit your Clarra schema during discovery and flag whether your migration requires a Sales Enterprise license or whether multiple Clarra object types can be consolidated into a smaller set of shared custom tables using type-discriminator fields. Overlooking this before provisioning your Dataverse environment results in schema errors mid-migration that require re-licensing and re-provisioning.

Clarra billing and time-entry data has no native Dynamics 365 Sales equivalent — historical records require a custom billing table or Business Central

Clarra stores billing line items, time entries, and invoice totals against each matter as native data. Dynamics 365 Sales has Quotes, Orders, and Invoices but these are CRM transactional constructs tied to Opportunities, not billing history for legal matters. Migrating billing records as standard Dynamics records creates misaligned entity relationships (invoices without Opportunities). We preserve Clarra billing data as a custom Matter_Billing_History__c table on the Account or Case for historical reference. Ongoing billing automation must be rebuilt in Dynamics 365 Sales workflows or in D365 Business Central — this is a rebuild, not a migration item, and should be scoped separately.

Document re-hosting to SharePoint requires the SharePoint-integrated environment to be configured before record migration

Dynamics 365 document management depends on SharePoint Online being enabled and the SharePoint Sites relationship being configured in your Dynamics environment. If SharePoint integration is not set up before migration day, documents exported from Clarra cannot be linked to Dynamics records and will need manual re-attachment or a separate bulk-upload step. We include SharePoint site provisioning in the pre-migration checklist. Documents are downloaded from Clarra using the export API, re-uploaded to the correct SharePoint library, and then linked via the Dynamics SharePoint Document Location entity. This step adds 1–2 days to the overall timeline if SharePoint was not pre-configured.

Dataverse API request limits cap bulk-load throughput — large migrations require batch sizing tuning

Dynamics 365 on Dataverse enforces API request limits per user license tier (4,000–100,000 requests per 24 hours depending on license). A Clarra migration with 50,000+ records writing to multiple tables simultaneously can exhaust default API quotas within hours, causing 429 Too Many Requests responses that stall the migration run. We configure Dataverse batch sizes (default 1,000 records per ExecuteMultiple request), distribute load across off-peak hours, and use the Dynamics 365 Bulk API (soap-based) for high-volume initial loads to stay within quota. We monitor request telemetry via Power Platform admin center during the run.

Clarra workflow rules and automation sequences do not transfer to Dynamics — export definitions as-is for rebuild reference

Clarra automations (matter-initiated notifications, deadline escalation triggers, status-change rules) are platform-specific workflow definitions stored in Clarra's execution engine. They cannot be exported as executable logic and re-imported into Dynamics 365. We extract the JSON definition of each active Clarra workflow as a text export so your Dynamics admin or Power Platform consultant has a rebuild reference. Dynamics 365 equivalents are built in Power Automate (cloud flows), Dynamics workflows, or custom plug-ins — the effort depends on automation complexity. We do not scope this as data migration work; it is a separate services engagement.