Migrate from Centerbase to Microsoft Dynamics 365 Sales

Centerbase Clients map directly to Dynamics 365 Accounts. Client name becomes Account Name; billing address maps to the Account's primary address fields. Multi-matter clients appear as a single Account with multiple Opportunities linked. The primary Contact on the Client becomes the primary Contact on the Account; other Contacts become secondary Contacts. Any custom Client fields are translated to custom columns on the Account entity in Dataverse.

Direct 1:1 mapping. Contact name, email, phone, address, and role fields translate directly. Primary Contact on a Client becomes the primary Contact on the corresponding Account. Secondary contacts from multi-party matters surface as additional Contact records. All Contact custom fields are migrated as custom columns on the Contact entity. If duplicate email addresses exist across Clients, the migration flags them for review to prevent duplicate Account linking.

Centerbase Matters map to Dynamics 365 Opportunities. Matter title becomes Opportunity Name; status maps to Opportunity State (Open/Won/Lost). Practice area and matter type feed into custom columns. Billable amount translates to Estimated Revenue. The Opportunity's Account lookup links to the mapped Client.

Centerbase matter lifecycle stages ( Intake, Open, Pending, Closed) map to Dynamics 365 Opportunity stage values. We create a value-mapping table per practice area because firms often use different stage names per matter type. Probability and forecast category re-applied from Dynamics 365 stage defaults.

Billable hours and fee amounts from Centerbase do not have a native Dynamics 365 equivalent. We migrate time-entry totals and billing amounts as custom numeric columns on the Opportunity (e.g., Total_Billable_Hours__c, Billed_Fees__c). Full invoicing requires Dynamics 365 Business Central. Legal-specific billing codes such as LEDES and IOLTA flags are also stored as read-only custom columns for compliance reference, even if Business Central is not licensed.

Centerbase document attachments re-upload to the SharePoint document library associated with the mapped Account or Opportunity. We preserve the original folder structure and file names. Large documents (>100MB) require SharePoint site storage capacity check before migration. If the SharePoint tenant lacks sufficient storage, files are migrated to Azure Blob with a link record in Dynamics 365. Document metadata such as created date and author is preserved.

Centerbase custom properties per Matter, Client, or Contact become Dataverse custom columns on the corresponding table. Field data type is translated: text fields become nvarchar, pick-lists become choice columns, date fields become datetime. Sales Enterprise or Premium license is required for more than 15 custom columns.

Centerbase staff records resolve to Dynamics 365 users by email address match. Unmatched staff are flagged as inactive users in a custom table so billing attribution can be reviewed post-migration. Admin vs. standard user role mapping requires manual confirmation. During mapping, each Centerbase staff role is mapped to a Dynamics 365 security role; missing roles are created by admin. License assignment (Sales Enterprise or Professional) is aligned to staff function.

Centerbase workflow rules — including matter-stage triggers, task-generation rules, and email notifications — do not migrate. We export workflow definitions as JSON and PDF for the client's Dynamics administrator to rebuild as Power Automate cloud flows. This is the most time-intensive rebuild step post-migration.

Legal-specific billing fields like origination codes, fee arrangements, and IOLTA trust settings have no Dynamics 365 equivalent. We migrate these as read-only custom columns so the data is preserved for reference even if the billing module (Business Central) is not licensed.