Migrate from Centrium CRM to Salesforce Sales Cloud

Standard Centrium contacts — records without the organization flag — map directly to Salesforce Contact. All standard contact fields (name, email, phone, address) transfer as typed fields. Custom fields on Centrium contacts migrate as Salesforce custom fields (__c) using type-matched field creation (text, number, date, picklist) during the schema design phase. The Contact's OwnerId is resolved via email match against the destination Salesforce User table.

Centrium stores organizations as Contact records with an organization flag rather than a distinct object. We identify these flagged records during preprocessing, create the corresponding Salesforce Account record, then re-link the original Contact record to the new Account via AccountId. This is a mandatory preprocessing step before any standard Contact import can begin. Accounts with large organization-flagged contact lists extend the preprocessing timeline and must be scoped during discovery.

Centrium Deals map to Salesforce Opportunity. The Centrium deal status (won/open/lost) maps to the nearest equivalent Salesforce StageName value, but intermediate stage progression cannot be reconstructed since Centrium stores no history beyond the current status. We map Centrium deal fields (name, amount, expected close date, contact association) to the equivalent Salesforce Opportunity fields. Deal owner resolution follows the User email match established during owner reconciliation.

Centrium's three-status model (won/open/lost) maps to a Salesforce Sales Process with three stage values. If the destination org requires multi-stage pipelines for business reasons, we configure the stage values during schema design and document the gap between the flat Centrium model and the richer Salesforce model. Stage probability percentages default to Salesforce's standard values for the mapped stages.

Centrium Tasks migrate to Salesforce Task with Subject, Status, Priority, and ActivityDate preserved. Task assignments migrate by resolving the Centrium team member reference to the Salesforce User via email lookup. Both open and completed tasks transfer, with completed tasks retaining their original completion timestamp as ActivityDate.

Centrium Projects are lightweight containers linking tasks and contacts. Salesforce has no native Project object in Sales Cloud. We create a Project__c custom object with fields for name, description, status, and start/end dates, and migrate the linked task memberships as related records. The project metadata beyond name and membership requires a custom field map established during scoping. If the destination org uses Salesforce Field Service or a PSA tool, the project-to-work-order mapping is covered separately.

Centrium Notes are flat text records attached to contacts, deals, or projects. We migrate the full note body and preserve the parent-object association in Salesforce using the ContentDocumentLink pattern. Notes are not threaded in Centrium — multi-message conversation threads map to individual Note records in Salesforce without a parent-child thread relationship.

Centrium custom fields store as property maps with simplified field definitions. We extract the field name, data type, and values per record during the extract phase and create corresponding Salesforce custom fields during schema design before any data import. Type mapping applies: Centrium text becomes Salesforce Text, number becomes Number, date becomes Date, picklist becomes Picklist. Dedupe keys and required-field constraints are set in Salesforce metadata before import rather than enforced during migration.

Centrium attachments on contacts, deals, and projects migrate to Salesforce ContentDocument records via the ContentVersion upload pattern. We audit the total attachment volume during discovery because Centrium's 1Gb-per-user storage allocation can accumulate files well beyond Salesforce's default 10GB org storage, particularly for accounts with document-heavy sales workflows. We flag the total file size before cutover and recommend purchasing additional Salesforce storage or archiving attachments externally if the total volume exceeds the destination allocation.

Centrium user records (name, email, team permission) map to Salesforce User records by email match. We extract every distinct user referenced on Contact, Deal, Task, and Project records and validate against the destination Salesforce User table before import begins. Any Centrium user without a matching Salesforce User enters a reconciliation queue; the customer's admin provisions the missing User before record import resumes.

Centrium's team-level permission model does not map to Salesforce RBAC because there are no granular role definitions to transfer. All migrated records default to the importing admin as Owner, and we flag the gap in the migration report so the customer can assign Salesforce Profiles and Role hierarchy manually after cutover. This is a manual post-migration step that must be planned for and is not part of the migration deliverable scope.

Centrium Reports are pre-built summary views generated on-demand and are not stored as exportable datasets. We do not migrate report definitions or historical report outputs. We deliver a written list of the Centrium report names and their underlying data sources so the customer's admin can rebuild equivalent reports in Salesforce Reports & Dashboards using the migrated data.