CRM migration
Field-level mapping, validation, and rollback between Case Status and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Case Status
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
11 of 12
objects map 1:1 between Case Status and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
48–72 hours
Overview
Case Status is a client-engagement CRM built specifically for law firms, centering on case-matter management, automated client communication, and client portal access. Its data model stores contacts, cases, matters, and case-event histories in a structure optimized for legal workflows. Dynamics 365 Sales runs on Dataverse and models the same core objects — Accounts, Contacts, Leads, Opportunities — plus a native Case entity for service management, with unlimited custom tables available under the Enterprise license. We map Case Status client records to Dynamics Accounts and Contacts, Case Status case records to the msdyn_incident (Case) entity or a custom Cases table depending on your license tier, and communication histories to Dataverse custom activity tables. Automations and client-portal configurations do not transfer — those require rebuilding via Power Automate and Power Pages after migration. The migration pipeline uses Case Status API endpoints to extract records in bulk, transforms field names and pick-list values to match Dataverse schema requirements, then upserts into your Dynamics 365 environment via the Dataverse Web API. Owner resolution happens by email match against your Dynamics 365 user list before records commit.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Source platform
Case Status platform overview
Scorecard, SWOT, gotchas, and pricing for Case Status.
Destination platform
Microsoft Dynamics 365 Sales platform overview
Scorecard, SWOT, gotchas, and pricing for Microsoft Dynamics 365 Sales .
Data migration guide
The complete Microsoft Dynamics 365 Sales migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Microsoft Dynamics 365 Sales migration checklist
Pre- and post-cutover tasks for moving onto Microsoft Dynamics 365 Sales .
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Case Status object lands in Microsoft Dynamics 365 Sales , including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Case Status
Contact
Microsoft Dynamics 365 Sales
Contact
1:1Case Status contacts map directly to Dynamics 365 Contacts. The primary firm association is stored as a lookup to the Account entity, ensuring that each contact is linked to its parent organization. Unassigned contacts — those without a linked firm — are attached to a default 'Individual' account record in Dynamics, preserving a consistent owner hierarchy and enabling accurate reporting across the CRM.
Case Status
Contact
Microsoft Dynamics 365 Sales
Account
many:1Case Status stores the law firm or company as a contact property named 'company'. This value merges into Dynamics Account — the Account record must be created first so that contacts can link via the primarycontactid or parentaccountid lookup. The mapping preserves the original company name, and multiple contacts can reference the same Account, allowing consolidated firm-level reporting and streamlined case assignments.
Case Status
Case
Microsoft Dynamics 365 Sales
msdyn_incident (Case)
1:1Case Status cases map to the msdyn_incident Case entity in Dynamics 365 when your license includes the Customer Service hub. The Case Status case ID is stored as a custom string field (cs_case_id) for traceability and delta-run de-duplication. The original case identifier is preserved so you can audit the source record without relying on platform IDs. This also supports sync if you add or modify cases after the initial load.
Case Status
Case (when no Customer Service license)
Microsoft Dynamics 365 Sales
Custom Cases Table
1:1If your Dynamics 365 Sales Professional license does not include Customer Service, Cases require a custom Dataverse table. We create a 'Cases' table with fields mirroring Case Status case properties — title, status, priority, assigned attorney, open date — and register it in your solution.
Case Status
Matter
Microsoft Dynamics 365 Sales
Custom Matters Table
1:1Case Status Matters represent legal matters within a case — a subdivision some firms use for billing or document grouping. Dynamics has no native Matter equivalent. We create a custom 'Matter' Dataverse table with a lookup to the Case record.
Case Status
Case Status
Microsoft Dynamics 365 Sales
statuscode (on msdyn_incident or custom Cases table)
1:1Case Status case status values (e.g., Intake, Active, Pending, Closed) map to Dynamics statuscode integer values. Each pick-list value requires a value-by-value mapping because Case Status stores string labels while Dynamics stores integer status reasons. During schema setup, we enumerate Case Status status labels, create matching statuscode rows in Dynamics, and verify the mappings before migration. After data lands, you can filter cases by status in Dynamics dashboards and reports.
Case Status
Communication / Client Message
Microsoft Dynamics 365 Sales
Custom Activity Table (Email, Note, or custom Message entity)
1:1Case Status client portal messages and communication threads have no direct Dynamics equivalent. We create a custom 'ClientMessage' Dataverse activity table with fields for direction (inbound/outbound), message body, timestamp, attorney owner, and a lookup to the Contact record. The custom activity appears in the Contact timeline, letting attorneys view client interaction history. It also lets Power Automate trigger on new messages, enabling automated follow‑up tasks or alerts.
Case Status
Document / File Attachment
Microsoft Dynamics 365 Sales
SharePoint (linked to Dataverse)
1:1Case Status file attachments are downloaded and re-uploaded to SharePoint via the Dynamics 365 document management integration. The SharePoint URL is stored as a custom field on the related Case or Matter record. We replicate the folder hierarchy in SharePoint, creating libraries that reflect your Case Status layout. The stored URL links to the document from the Case or Matter form, and SharePoint permissions are managed via Microsoft 365 groups.
Case Status
Automation / Workflow
Microsoft Dynamics 365 Sales
Power Automate (must be rebuilt)
1:1Case Status automations (milestone triggers, client-update notifications, email sequences) have no equivalent in Dynamics 365 Sales. We export your automation definitions as a reference JSON and provide a Power Automate rebuild guide targeting the same triggers. The JSON lists name, trigger, and actions. The guide maps these to Power Automate triggers such as 'When a row is modified', with instructions to rebuild email alerts, updates, and milestone notifications.
Case Status
Client Portal Configuration
Microsoft Dynamics 365 Sales
Power Pages (must be rebuilt)
1:1Case Status client portal settings, branding, and portal access rules do not transfer. Power Pages requires a separate build. We can scope this as a post-migration project or recommend a Microsoft partner specializing in legal portal deployments. Power Pages is built on Dataverse, so you can create pages that read contact and case tables migrated from Case Status. We will deliver a blueprint and assist with branding.
Case Status
Custom Field (any entity)
Microsoft Dynamics 365 Sales
Custom Dataverse Field
1:1Case Status custom fields created by your firm (e.g., practice area, referral source, client tier) are enumerated during discovery and created as custom Dataverse columns on the appropriate entity. Field type mapping follows Dataverse data type conventions. We map text fields to strings, pick‑lists to option sets, dates to datetime, and numbers to decimal or integer types, then add each column to the solution file for persistence across environments.
Case Status
User / Attorney Owner
Microsoft Dynamics 365 Sales
SystemUser (Owner)
1:1Case Status attorney owners are matched to Dynamics 365 users by email address. Unmatched owners are flagged before migration so you can either invite them to Dynamics or reassign their records to a fallback owner before the full run. The match uses the email attribute on the SystemUser table. We generate a report listing attorneys, allowing you to create accounts or map them to a fallback user before migration commits.
| Case Status | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Contact | Accountmany:1 | Fully supported | |
| Case | msdyn_incident (Case)1:1 | Fully supported | |
| Case (when no Customer Service license) | Custom Cases Table1:1 | Fully supported | |
| Matter | Custom Matters Table1:1 | Fully supported | |
| Case Status | statuscode (on msdyn_incident or custom Cases table)1:1 | Fully supported | |
| Communication / Client Message | Custom Activity Table (Email, Note, or custom Message entity)1:1 | Fully supported | |
| Document / File Attachment | SharePoint (linked to Dataverse)1:1 | Fully supported | |
| Automation / Workflow | Power Automate (must be rebuilt)1:1 | Fully supported | |
| Client Portal Configuration | Power Pages (must be rebuilt)1:1 | Fully supported | |
| Custom Field (any entity) | Custom Dataverse Field1:1 | Fully supported | |
| User / Attorney Owner | SystemUser (Owner)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Case Status gotchas
No publicly documented public API for self-service exports
Portal data is partially decoupled from source case management
Add-on pricing model obscures true cost for migration assistance
Custom properties are stored as JSON key-value pairs with limited schema visibility
Client app notifications and push token state does not transfer
Microsoft Dynamics 365 Sales gotchas
Professional tier 15-table custom table limit blocks migrations
October 2024 pricing increase applies at renewal for all customers
Custom fields must be created in the UI before API writes
Power Platform request limits apply to bulk migrations
Activity records orphaned to inactive owners fail silently
Pair-specific challenges
Migration approach
Discover Case Status schema and Dynamics 365 environment
We connect to Case Status via API using scoped read credentials and enumerate all active objects: contacts, cases, matters, custom fields, and pick-list values. In parallel, we assess your Dynamics 365 environment — license tier, existing tables, statuscode/statecode configuration, and user list. We produce a schema-diff document showing what exists in both systems and what requires new Dataverse custom fields or tables before migration data lands.
Create Dataverse custom schema and status value maps
Based on the schema-diff, we create any missing custom fields on standard entities (Contact, Account, msdyn_incident) and any custom tables (Cases, Matter, ClientMessage) in your Dataverse solution. We configure statuscode value maps matching your Case Status status labels to Dynamics integer codes. If your environment lacks the Customer Service hub, we build the custom Cases table with the same field set. This schema work is validated in a sandbox or dev environment before touching production data.
Resolve attorney owners by email and build delta-run checkpoint
We match Case Status attorney owner email addresses against your Dynamics 365 user list. Unmatched owners are flagged in a pre-flight report — you either invite them to Dynamics before migration or assign their records to a fallback owner. We also establish a delta-run checkpoint timestamp so any records modified in Case Status after the initial extraction are captured in a follow-on delta migration window (typically 24–48 hours) during cutover.
Run sample migration with field-level diff
A representative slice of records — usually 200–500 covering a mix of contacts, cases, and a few matters — migrates first. We generate a field-level diff comparing the Case Status source values against the Dynamics destination values for every mapped field. You review the diff to confirm status value mappings, owner resolution, and Matter-to-Case linkage before the full run commits. Adjustments to field mapping or value maps are applied before the production migration.
Execute full migration with delta pickup and audit log
The full record set migrates in batches via the Dataverse Web API. An audit log captures every upsert operation — source record ID, destination record ID, operation type, and timestamp. A delta-pickup window (24–48 hours) follows the initial run to capture any records modified in Case Status during cutover. If reconciliation reveals mismatches, one-click rollback reverts the target environment to its pre-migration state. Final validation confirms record counts, status distribution, and owner assignment across all entities.
Platform deep dives
Case Status
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between Case Status and Microsoft Dynamics 365 Sales .
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Case Status and Microsoft Dynamics 365 Sales .
Object compatibility
All 8 core objects map 1:1 between Case Status and Microsoft Dynamics 365 Sales .
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Case Status: Not publicly documented.
Data volume sensitivity
Case Status doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Case Status to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Case Status to Microsoft Dynamics 365 Sales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Case Status
Other ways to arrive at Microsoft Dynamics 365 Sales
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.