CRM migration
Field-level mapping, validation, and rollback between LawPracticeZA and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
LawPracticeZA
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
12 of 12
objects map 1:1 between LawPracticeZA and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
48–72 hours
Overview
LawPracticeZA is a legal-practice management and billing system built for South African law firms, with core objects for client matters, fee earners, time tracking, and trust accounting. It stores firm data in a matter-centric model where each matter links to one or more fee earners and maintains its own billing ledger. Dynamics 365 Sales, built on Microsoft Dataverse, uses a standard CRM model with Accounts, Contacts, Leads, and Opportunities — plus custom tables for extensibility. The migration challenge is translating LawPracticeZA's matter-centric structure into Dynamics 365's entity-relational model, resolving fee earners to Dataverse User records, and deciding how trust-accounting data (which has no native Dynamics 365 equivalent) gets preserved or rebuilt. We use LawPracticeZA's REST API for data extraction and the Dynamics 365 Web API for ingestion, with Power Automate used post-migration for any automated workflow reconstruction. All migration steps run with scoped read access on LawPracticeZA — your team keeps billing throughout.
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
LawPracticeZA platform overview
Scorecard, SWOT, gotchas, and pricing for LawPracticeZA.
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 LawPracticeZA 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.
LawPracticeZA
Matter (Client)
Microsoft Dynamics 365 Sales
Account / Contact
1:1LawPracticeZA matters are client files tied to a primary client. Each matter maps to one Account (if the client is an organization) or one Contact (if an individual). Matter type, matter description, and open/closed status migrate as custom fields on the Account or Contact record.
LawPracticeZA
Matter
Microsoft Dynamics 365 Sales
Custom Table: Matter__c
1:1Because Dynamics 365 has no native matter concept, we create a Matter__c custom table to preserve the full matter record — including matter reference number, responsible attorney, practice area, and billing structure. The Account or Contact links via a lookup field.
LawPracticeZA
Client
Microsoft Dynamics 365 Sales
Account
1:1Organizational clients in LawPracticeZA map directly to Dynamics 365 Accounts. Client name, registration number, VAT number, and physical address fields translate field-by-field. Individual clients map to Contacts. Physical address maps to Address1_Line1, postal address to Address2_Line1, and any industry or client-type metadata is preserved as custom fields on the Account record.
LawPracticeZA
Client
Microsoft Dynamics 365 Sales
Contact
1:1Individual clients without a company entity map to Dynamics 365 Contacts. The client name, email address, phone number, and postal address migrate directly. A custom field tracks whether this contact originated as a LawPracticeZA client. If the client has multiple postal addresses, each can be mapped to separate address fields (Address1, Address2) or stored as custom address records linked to the Contact.
LawPracticeZA
Fee Earner
Microsoft Dynamics 365 Sales
System User
1:1LawPracticeZA fee earners (attorneys, paralegals, assistants) map to Dataverse System Users. Email matching resolves existing D365 users; unmatched fee earners are flagged before migration so your admin can provision accounts or assign records to a fallback owner. The matching process also preserves the user’s full name, employee ID, and billable rate, which are stored as custom fields on the System User record for future reference.
LawPracticeZA
Invoice
Microsoft Dynamics 365 Sales
Invoice
1:1LawPracticeZA invoices migrate to Dynamics 365 Invoice records. Invoice number, date, total amount, and line items map directly. However, the legal-specific billing breakdown (WIP, disbursements, VAT, trust components) requires custom fields or a separate billing reconstruction plan. We recommend creating custom decimal fields for WIP and trust amounts, and an option set for VAT treatment, so that the invoice entity retains the full financial picture required for legal billing audits.
LawPracticeZA
Time Entry / WIP
Microsoft Dynamics 365 Sales
Custom Table: TimeEntry__c
1:1Work-in-progress time entries in LawPracticeZA have no direct Dynamics 365 equivalent. We migrate them to a TimeEntry__c custom table linked to the Matter__c record, preserving the fee earner, date, hours, rate, and description. These feed into the invoice mapping. Each TimeEntry__c record also stores the billable flag and any non-billable adjustment, ensuring that the full earning breakdown is available for reporting in Power BI.
LawPracticeZA
Trust Accounting Ledger
Microsoft Dynamics 365 Sales
No Equivalent
1:1Trust accounting — a legal regulatory requirement in South Africa — has no native Dynamics 365 Sales module. We export the trust ledger as a structured reference dataset and document it as a separate rebuild requirement outside the CRM scope.
LawPracticeZA
Disbursement
Microsoft Dynamics 365 Sales
Custom Table: Disbursement__c
1:1Matter-level disbursements (court fees, search fees, courier charges) migrate to a Disbursement__c custom table linked to Matter__c. Each record preserves the disbursement type, amount, date, and whether it was billed to the client or paid from trust. We also retain the vendor name and reference number for each disbursement, which helps in reconciling external payments and provides an audit trail for billing disputes.
LawPracticeZA
Document / Attachment
Microsoft Dynamics 365 Sales
SharePoint / Notes
1:1LawPracticeZA document attachments migrate to SharePoint document libraries connected to the corresponding Matter__c record. Inline documents attached to specific matter records are re-hosted in the Dynamics 365 SharePoint integration. The migration preserves original file names, creation timestamps, and author metadata, and configures SharePoint permissions to match the Matter__c access controls.
LawPracticeZA
Department
Microsoft Dynamics 365 Sales
Business Unit
1:1LawPracticeZA departments map to Dynamics 365 Business Units. Department-level permissions and reporting structures translate to Business Unit hierarchies in Dataverse security roles. Each Business Unit inherits the parent‑child relationships defined in LawPracticeZA, and we configure corresponding security roles to ensure that users see only the departments they are authorized to access.
LawPracticeZA
Activity Log (calls, emails)
Microsoft Dynamics 365 Sales
Activity (Task, Email)
1:1LawPracticeZA activity records — logged calls, emails, and notes — map to Dynamics 365 Activities. Each activity preserves the originating fee earner (as Owner), the linked matter, the timestamp, and the activity description. We also retain the original activity type code and any custom classification flags, so reporting can filter on call outcome or email sentiment if those fields were used in LawPracticeZA.
| LawPracticeZA | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Matter (Client) | Account / Contact1:1 | Fully supported | |
| Matter | Custom Table: Matter__c1:1 | Fully supported | |
| Client | Account1:1 | Fully supported | |
| Client | Contact1:1 | Fully supported | |
| Fee Earner | System User1:1 | Fully supported | |
| Invoice | Invoice1:1 | Fully supported | |
| Time Entry / WIP | Custom Table: TimeEntry__c1:1 | Fully supported | |
| Trust Accounting Ledger | No Equivalent1:1 | Fully supported | |
| Disbursement | Custom Table: Disbursement__c1:1 | Fully supported | |
| Document / Attachment | SharePoint / Notes1:1 | Fully supported | |
| Department | Business Unit1:1 | Fully supported | |
| Activity Log (calls, emails) | Activity (Task, Email)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.
LawPracticeZA gotchas
South African trust accounting compliance requirements
Zone-based permission model does not map directly to other systems
API authentication uses firm code prefix and requires bookkeeper access
Incomplete API reference requires support coordination
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
Pre-migration schema audit and custom table creation
FlitStack AI reviews your LawPracticeZA object inventory — matters, fee earners, departments, invoice series, and any custom fields — and maps them to Dynamics 365 entities and custom tables. We deliver a schema setup plan specifying the Matter__c table structure, custom fields for practice areas and billing metadata, Business Unit hierarchy, and any required trust-export tables. Your D365 admin creates the schema before the migration run begins.
Fee earner resolution and User provisioning
We extract the fee earner list from LawPracticeZA and run an email-matching pass against existing Dataverse System Users. Each match is confirmed; each non-match generates a resolution task — provision a User account or assign to a fallback owner. No matter migrates without a resolved OwnerId. This step gates the migration run: all records need a D365 owner before insert.
Data extraction via LawPracticeZA API with staged load into Dynamics 365
FlitStack AI extracts from LawPracticeZA using its REST API — starting with Accounts and Contacts, then Fee Earners, then Matters, then invoices and time entries. Each entity batch is validated against the field mapping, deduplicated by source record ID, and loaded into Dynamics 365 via the Web API. Trust ledger entries are exported to a reference dataset, not loaded into a functional accounting module. A field-level diff report is generated for each batch.
Sample migration with field-level diff
A representative slice — typically 200–500 records spanning matters, invoices, and time entries across multiple fee earners — migrates first. We produce a field-level diff comparing source LawPracticeZA values against destination Dynamics 365 values so you can verify matter reference mapping, invoice totals, and owner resolution before the full run commits. Your team signs off on the diff before cutover proceeds.
Delta pickup and cutover with audit log
The full migration runs against Dynamics 365. A delta-pickup window (24–48 hours) captures any LawPracticeZA records created or modified during cutover — time entries, invoice payments, or new matters opened by fee earners still working in LawPracticeZA. Every migration operation is logged. One-click rollback is available if reconciliation reveals record count discrepancies exceeding your defined tolerance threshold. This ensures data consistency and minimal disruption during the transition.
Platform deep dives
LawPracticeZA
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across LawPracticeZA and Microsoft Dynamics 365 Sales .
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
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
LawPracticeZA: Not publicly documented.
Data volume sensitivity
LawPracticeZA 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 LawPracticeZA to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your LawPracticeZA 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 LawPracticeZA
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.