CRM migration
Field-level mapping, validation, and rollback between Olqan and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Olqan
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
7 of 10
objects map 1:1 between Olqan and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
4-6 weeks
Overview
Olqan combines CRM, project management, HR, and finance into a single workspace, which means its exports bundle records from multiple modules into one download file. We parse those mixed exports into isolated object streams — Contacts, Companies, Deals, Tickets, Projects, Employees, Time Logs, and Invoices — and normalize each against the Microsoft Dynamics 365 Sales data model before loading. Olqan's Contact and Company records carry a flat relationship; Microsoft Dynamics 365 Sales uses a separate Account object with Contacts linked as children. We decompose that relationship at migration time, creating Account records first and resolving AccountId lookups on every Contact. Pipeline stages from Olqan Deals map to Microsoft Dynamics 365 Sales Opportunity stages via a configurable stage-mapping table. Workflows, automations, and project-task hierarchies are not migrated as code; we deliver a written inventory of every Olqan automation and workflow for the customer's admin to rebuild in Microsoft Dynamics 365 Sales using Power Automate or model-driven apps. HR and finance data — employee profiles, time logs, invoices — has no native destination in Microsoft Dynamics 365 Sales and requires either a custom Dataverse table or manual re-entry planning.
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
Olqan platform overview
Scorecard, SWOT, gotchas, and pricing for Olqan.
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 Olqan 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.
Olqan
Contact
Microsoft Dynamics 365 Sales
Contact
1:1Olqan Contacts map to Microsoft Dynamics 365 Sales Contact records. We resolve the parent Account by matching Olqan's company association field against Olqan Companies, then map those to Account records created first in the migration sequence. Contact fields — name, email, phone, job title, lifecycle stage — map to their Dynamics equivalents (firstname, lastname, emailaddress1, telephone1, jobtitle, industrycode). Olqan's lifecycle stage property migrates to a custom field olqan_lifecycle_stage__c on Contact for reporting continuity.
Olqan
Company
Microsoft Dynamics 365 Sales
Account
1:1Olqan Company records map directly to Microsoft Dynamics 365 Sales Account. The company name becomes Account Name; address fields map to address1_line1, address1_city, address1_stateorprovince, address1_postalcode, address1_country. Industry and company size map to IndustryCode and NumberOfEmployees. Account is created before Contact migration so that the AccountId lookup is resolved at insert time, preventing orphaned Contact records.
Olqan
Deal
Microsoft Dynamics 365 Sales
Opportunity
1:1Olqan Deals map to Microsoft Dynamics 365 Sales Opportunity. Deal name becomes Opportunity Name; deal value maps to EstimatedValue; close date maps to EstimatedCloseDate. The Olqan pipeline stage name maps to a Microsoft Dynamics 365 Sales Process and StageName via a configurable mapping table created during schema design. Owner from Olqan Deal resolves to Microsoft Dynamics 365 Sales User by email match.
Olqan
Deal Stage
Microsoft Dynamics 365 Sales
Opportunity Stage
lossyEach Olqan pipeline with its stage labels and probabilities translates to a Microsoft Dynamics 365 Sales Process. We create the Sales Process in the destination org before migration, configuring StageName and StageProbability for each stage. Closed-Won and Closed-Lost outcomes from Olqan map to Microsoft Dynamics 365 Sales Won - Lost statuses with the probability override applied at migration time.
Olqan
Ticket
Microsoft Dynamics 365 Sales
Case
1:1Olqan Tickets migrate to Microsoft Dynamics 365 Sales Case. Ticket subject becomes Case Title; ticket status maps to Case Status; priority maps to Priority. Agent assignment resolves to Microsoft Dynamics 365 Sales User by email. Ticket conversations are stored as EmailMessage records linked to the Case, preserving the support thread timeline. If the Dynamics 365 org does not include Service Cloud licensing, Cases may not be available and Tickets migrate to custom fields on the Account or Contact instead.
Olqan
Project
Microsoft Dynamics 365 Sales
Opportunity or Custom Entity
lossyOlqan Projects store tasks, time logs, assignees, and milestones with no direct Microsoft Dynamics 365 Sales equivalent. If the project tracks billable client work, we map the project record to a custom Dataverse table (Project__c) and link it to the Account. Tasks nested within the project migrate as records in a ProjectTask__c custom table linked to Project__c. If the customer does not require project tracking in Dynamics 365, we deliver the project data as a structured CSV inventory for reference.
Olqan
Employee
Microsoft Dynamics 365 Sales
SystemUser or Custom HR Table
lossyOlqan Employee profiles (job title, department, start date, contact details, manager hierarchy) do not map to a standard Microsoft Dynamics 365 Sales object. If the destination org includes Dynamics 365 Human Resources, we migrate to the HR module. Otherwise we create a custom Dataverse table (Employee__c) with fields for each Olqan employee attribute. Reporting relationships from Olqan's manager field map to a self-referencing lookup on the custom table.
Olqan
Custom Fields
Microsoft Dynamics 365 Sales
Custom Fields
1:1Olqan custom fields on Contact, Company, Deal, Ticket, and Project migrate to Microsoft Dynamics 365 Sales custom attributes (CustomFields or custom __c fields on the equivalent Dataverse table). We detect field type during export parsing — text, number, date, picklist, checkbox — and map to the corresponding Dataverse attribute type. Any custom field that has no valid destination in Microsoft Dynamics 365 Sales schema is documented in a Custom Fields Inventory with data type, current values, and a recommendation for a custom field or notes field placement.
Olqan
User / Owner
Microsoft Dynamics 365 Sales
User
1:1Olqan user accounts across CRM, project, HR, and ticket modules map to Microsoft Dynamics 365 Sales User records. We match by email address as the unique identifier. Users without a matching Dynamics 365 User go to a reconciliation queue for the customer's admin to provision. Assignee and owner references on Deals, Tickets, and Projects resolve via this User lookup before record import proceeds.
Olqan
Attachment
Microsoft Dynamics 365 Sales
Annotation or SharePoint
1:1File attachments on Olqan Deals, Projects, Tickets, and Tasks migrate as Notes (Annotation records) in Microsoft Dynamics 365 Sales , linked via objectid and objecttypecode to the parent record. We preserve the original filename, upload date, and file body. Large attachments above 5 MB are handled as SharePoint file references if the Dynamics 365 org has SharePoint integration enabled, otherwise stored as Annotation with a size warning raised during scoping.
| Olqan | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Deal Stage | Opportunity Stagelossy | Fully supported | |
| Ticket | Case1:1 | Fully supported | |
| Project | Opportunity or Custom Entitylossy | Fully supported | |
| Employee | SystemUser or Custom HR Tablelossy | Fully supported | |
| Custom Fields | Custom Fields1:1 | Mapping required | |
| User / Owner | User1:1 | Fully supported | |
| Attachment | Annotation or SharePoint1: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.
Olqan gotchas
No mobile app for iOS or Android
Limited third-party integration ecosystem
Mixed-object exports require post-processing
Newer platform with evolving feature set
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
Multi-module export coordination
We work with the customer to extract data from every Olqan module used — CRM (Contacts, Companies, Deals), project management (Projects, Tasks), HR (Employees), finance (Invoices, Time Logs), and support (Tickets). Because Olqan has no public API, exports are coordinated manually. We validate record counts across modules, check for missing required fields, and parse any mixed-export files into isolated object streams before designing the migration mapping.
Schema design in Microsoft Dynamics 365 Sales Sandbox
We deploy the destination schema to a Microsoft Dynamics 365 Sales Sandbox (Full Copy or Partial Copy) before production migration. This includes Account, Contact, Opportunity, Case, and any custom Dataverse tables required for Olqan Projects, Employees, or custom fields. We configure Sales Processes, Record Types, and stage-probability mapping tables during this phase. The customer reviews and approves the schema design before we proceed to data migration.
User and owner reconciliation
We extract every distinct Olqan user referenced as an owner or assignee on Deals, Tickets, Projects, and Tasks, and match by email against the destination Microsoft Dynamics 365 Sales User table. Unmatched users are held in a reconciliation queue. The customer's admin provisions any missing Users before we begin record import, because OwnerId references are required on Opportunity and Case records.
Production migration in dependency order
We migrate records in strict dependency order: Accounts (from Olqan Companies) first, then Contacts with AccountId resolved, then Opportunities linked to Account and Owner, then Cases, then custom entity records. Each phase emits a row-count reconciliation report showing records inserted, updated, and rejected before the next phase begins. Attachments and Notes migrate after their parent records are confirmed in the destination.
Cutover and automation inventory delivery
We freeze Olqan write access during cutover, extract a final delta of any records modified during the migration window, and apply it to Microsoft Dynamics 365 Sales . We then enable Microsoft Dynamics 365 Sales as the system of record. We deliver a written inventory of every Olqan automation, workflow, and project-task hierarchy with a Power Automate or model-driven app rebuild recommendation. We do not rebuild workflows inside the migration scope.
Platform deep dives
Olqan
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 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 Olqan and Microsoft Dynamics 365 Sales .
Object compatibility
2 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
Olqan: Not publicly documented.
Data volume sensitivity
Olqan 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 Olqan to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Olqan 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 Olqan
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.