CRM migration
Field-level mapping, validation, and rollback between Soffront and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Soffront
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
9 of 11
objects map 1:1 between Soffront and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Soffront to Microsoft Microsoft Dynamics 365 Sales is a schema-first migration. Soffront uses a Main Object-centric architecture where workflows anchor to a specific object type and generate dependent Tasks; Microsoft Microsoft Dynamics 365 Sales uses the Dataverse data model with separate Account, Contact, and Lead entities and relies on Power Automate for cross-object process automation. We resolve the API rowcount limitation of 500 records per call by implementing offset pagination during extraction, rebuild Soffront's Knowledge Base category hierarchy in Dynamics 365 before importing articles, and deliver a written inventory of Soffront workflows and their Power Automate equivalents for your admin team to rebuild post-migration. Soffront's on-premise editions use Power Export while cloud editions use the Import/Export interface; we determine the edition during scoping and route extraction through the correct path. We do not migrate Soffront workflows, automation rules, or forms as code; these are documented for your admin to rebuild in Power Automate or the Dynamics 365 workflow designer.
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
Soffront platform overview
Scorecard, SWOT, gotchas, and pricing for Soffront.
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 Soffront 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.
Soffront
Contact
Microsoft Dynamics 365 Sales
Contact
1:1Soffront Contacts map directly to Microsoft Dynamics 365 Sales Contact. Standard fields (full name, email, phone, address) use standard Dataverse attribute names (fullname, emailaddress1, telephone1, address1_*). Group assignments from Soffront map to Team membership or security roles in Dynamics 365. Soffront lifecycle stage values are preserved in a custom field soffront_lifecycle_stage__c on Contact for reporting continuity.
Soffront
Account
Microsoft Dynamics 365 Sales
Account
1:1Soffront Account records map to Microsoft Dynamics 365 Sales Account. The Account-Contact relationship is preserved by creating Accounts first and resolving the parent Account lookup before Contact import. Industry, size, and custom properties map to standard or custom fields on Account. Account names serve as the dedupe key during import to prevent duplicate Accounts.
Soffront
Deal
Microsoft Dynamics 365 Sales
Opportunity
1:1Soffront Deals map to Microsoft Dynamics 365 Sales Opportunity. The deal stage names from Soffront map to Dynamics 365 Opportunity StageName values; we perform a value-mapping exercise during discovery because stage names vary between Soffront instances. Deal amount maps to Amount, owner maps to OwnerId via email match against the Dynamics 365 User table. If the deal has a parent Account in Soffront, we set AccountId on the Opportunity during import.
Soffront
Activity (Call, Email, Meeting, Task)
Microsoft Dynamics 365 Sales
Task, Event, EmailMessage
1:1Soffront Activities with type labels (call, email, meeting, task) map to Dynamics 365 Dataverse Task, Event, or EmailMessage records. Calls map to Task with TaskSubtype=Call and call duration in a custom field. Emails map to EmailMessage records (body content) linked to an Activity Task for timeline display. Meetings map to Event with StartTime and EndTime preserved. Activity type labels and custom activity fields require field-level mapping during discovery. Soffront API pagination at 500 records per call means we chunk activity extraction by date range or owner to ensure complete coverage.
Soffront
Project
Microsoft Dynamics 365 Sales
Dynamics 365 Project Operations or custom entity
1:1Soffront Projects include status, milestones, managers, resources, and due dates. If the destination Microsoft Dynamics 365 Sales org has Project Operations licensed, we map to the Project entity. If not, we map to a custom project entity created in the destination. Project tasks migrate as related records with parent-project lookups resolved at import time. Milestone dates map to custom date fields or the Project timeline fields depending on destination schema.
Soffront
Ticket
Microsoft Dynamics 365 Sales
Case
1:1Soffront support Tickets map to Microsoft Dynamics 365 Sales Case if Service Cloud is included in the destination. Ticket status, priority, assignee, and conversation history migrate. Conversation threads migrate as EmailMessage records linked to the Case. If the destination does not include Service Cloud, we map Tickets to a custom Case entity on the Sales entity set. Ticket type labels map to Case Origin or a custom field depending on the destination's case configuration.
Soffront
Knowledge Base
Microsoft Dynamics 365 Sales
Knowledge Article
1:1Soffront Knowledge Base articles export with their category assignments. We recreate the category hierarchy in Dynamics 365 Knowledge Management before importing articles so that article-category relationships are preserved. If Dynamics 365 uses a flat KB structure, we create categories that mirror Soffront's taxonomy and map articles accordingly. Article content migrates as knowledgearticle records with the kbmemArticleContent field containing body text. Status (published, draft) migrates to the article's statecode.
Soffront
Custom Object
Microsoft Dynamics 365 Sales
Custom Entity (Dataverse)
1:1Soffront custom objects migrate to Dataverse custom entities with __c suffix API names. We pre-create the destination schema during discovery including all custom attributes, lookup relationships to standard entities (Account, Contact, Opportunity), and any validation rules. Custom field types from Soffront (text, number, picklist, date, checkbox) map to equivalent Dataverse attribute types. The schema is deployed to a Sandbox first for validation before production migration.
Soffront
Custom Fields on Standard Objects
Microsoft Dynamics 365 Sales
Custom Attributes on Standard Entities
lossySoffront custom fields on Contacts, Accounts, Deals, and Activities vary between instances because of Soffront's customization-first design. We perform a field inventory during discovery that captures every custom field's name, data type, and picklist values. The inventory generates a mapping document pairing each Soffront custom field to a new or existing Dynamics 365 custom attribute before any data moves. Picklist values are migrated as Option Set values in Dataverse.
Soffront
Attachment
Microsoft Dynamics 365 Sales
Annotation (Note) or SharePoint/Blob
1:1Soffront file attachments linked to Contacts, Deals, Tickets, and Projects export and re-upload to Dynamics 365. Annotations with file attachments become Note (annotation) records with documentbody populated. If the Dynamics 365 org uses SharePoint or Azure Blob for document storage, we configure the document location during migration. File size limits and storage location vary by Soffront edition and are documented during discovery.
Soffront
Group
Microsoft Dynamics 365 Sales
Team
lossySoffront Groups organize records for access control and segmentation. We map group memberships to Dynamics 365 Teams (or Azure Active Directory groups synced to Teams) and replicate the sharing model using Team membership. If Soffront groups have hierarchical nesting, we flatten the structure into Teams with appropriate parent-team assignments in Dynamics 365. Group-based record assignments migrate as OwnerId on the record.
| Soffront | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Account | Account1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Activity (Call, Email, Meeting, Task) | Task, Event, EmailMessage1:1 | Fully supported | |
| Project | Dynamics 365 Project Operations or custom entity1:1 | Fully supported | |
| Ticket | Case1:1 | Fully supported | |
| Knowledge Base | Knowledge Article1:1 | Fully supported | |
| Custom Object | Custom Entity (Dataverse)1:1 | Fully supported | |
| Custom Fields on Standard Objects | Custom Attributes on Standard Entitieslossy | Fully supported | |
| Attachment | Annotation (Note) or SharePoint/Blob1:1 | Fully supported | |
| Group | Teamlossy | 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.
Soffront gotchas
API rowcount defaults to 500 records per call
Workflow definitions tied to Main Objects require recreation
Knowledge Base articles must be mapped to destination KB categories
Custom field names vary between Soffront instances
On-premise and cloud editions have different import/export paths
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
Discovery and Soffront edition identification
We audit the source Soffront instance across edition (cloud vs on-premise), standard and custom object schemas, pipeline and stage definitions, active workflows, Knowledge Base category tree, group structure, and record counts per object. We identify whether the instance uses Power Export (on-premise) or the Import/Export interface (cloud) and configure the correct extraction path. The discovery output is a written migration scope with object inventory, field mapping draft, and a Microsoft Dynamics 365 Sales edition recommendation based on the customer's object count and automation needs.
Schema design and Dynamics 365 sandbox provisioning
We provision a Microsoft Dynamics 365 Sales Sandbox (Full Copy or Developer) and design the destination schema: custom entities for Soffront custom objects, custom attributes on standard entities for Soffront custom fields, Option Set values for custom picklists, and the Knowledge Base category hierarchy before article import. Soffront stage names are mapped to Dynamics 365 Opportunity StageName values through a value-mapping document produced in discovery. Schema is deployed via the Dynamics 365 solution package into Sandbox first for validation.
Sandbox migration and reconciliation
We run a full migration into the Dynamics 365 Sandbox using production-like record volumes. The customer's operations lead reconciles record counts per object, spot-checks 20-40 random records against the Soffront source for field accuracy, and validates the Knowledge Base category-article linkage. Any mapping corrections to field names, picklist values, or stage names happen in Sandbox before production migration begins. Knowledge Base category creation is validated here to confirm article-category assignment post-import.
Owner and User reconciliation
We extract every distinct Soffront Owner referenced on Contacts, Accounts, Deals, Activities, and Tickets and match by email against the destination Dynamics 365 org's User table. Owners without a matching User are held in a reconciliation queue for the customer's admin to provision before record import resumes. If the destination uses Azure Active Directory-synced users, we coordinate with the customer's IT team to ensure the directory provisioning is complete before proceeding.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Soffront Accounts), Contacts (with AccountId resolved), Opportunities (with AccountId, OwnerId, and stage resolved), Knowledge Base categories (created before articles), Knowledge Articles (with category linkage preserved), Activities (via Dataverse Bulk API with chunked extraction for Soffront API pagination), Projects (or custom project entity), Tickets (to Case or custom entity), Custom Objects (with schema created in step 2), and Attachments. Each phase emits a row-count reconciliation report before the next phase begins. Knowledge Base import happens in its own phase to ensure category pre-existence.
Cutover, validation, and workflow handoff
We freeze Soffront writes during cutover, run a final delta migration of any records modified during the migration window, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver the Soffront workflow inventory document to the customer's admin team for Power Automate rebuild. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's team. We do not rebuild Soffront workflows as Power Automate flows inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Soffront
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 4 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 Soffront and Microsoft Dynamics 365 Sales .
Object compatibility
4 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
Soffront: Not publicly documented; rowcount parameter caps results at 500 records per call by default.
Data volume sensitivity
Soffront exposes a bulk API — large-volume migrations stream efficiently.
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 Soffront to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Soffront 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 Soffront
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.