CRM migration
Field-level mapping, validation, and rollback between UPilot and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
UPilot
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
7 of 8
objects map 1:1 between UPilot and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from UPilot to Microsoft Microsoft Dynamics 365 Sales is a structural migration that reflects the scale difference between an SMB-focused unified CRM and an enterprise sales automation platform. UPilot consolidates Sales, Marketing, and Support into a single workspace with a per-feature pricing model starting at $29 per feature per month. Microsoft Dynamics 365 Sales uses a per-user model ($65 per user per month for Professional, $105 for Enterprise) and organizes data around Accounts, Contacts, and Opportunities with explicit relationship models. We extract from UPilot using built-in CSV exports supplemented by direct export tooling where available, then land records into Dataverse via the Microsoft Dataverse API with proper Account-to-Contact parent resolution and pipeline stage reconstruction. UPilot's two-way email sync state is disabled before migration to prevent orphaned threads. We do not migrate Workflows, Sequences, or automations; these are documented for the customer's admin to rebuild in Dynamics 365's workflow designer post-migration.
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
UPilot platform overview
Scorecard, SWOT, gotchas, and pricing for UPilot.
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 UPilot 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.
UPilot
Contact
Microsoft Dynamics 365 Sales
Contact
1:1UPilot Contact records map to Dynamics 365 Contact. Standard fields (FullName, Email, Phone, JobTitle) transfer directly. UPilot's Company association maps to the Contact's parentcustomerid lookup pointing to the corresponding Account. We resolve parent Account references before Contact insert so that the parentcustomerid lookup is satisfied. The original UPilot contact ID is preserved in a custom field upilot_contact_id__c for audit and reconciliation.
UPilot
Company
Microsoft Dynamics 365 Sales
Account
1:1UPilot Company records map to Dynamics 365 Account. Company name maps to Account Name; website domain maps to Website; industry and address fields map to the corresponding Account fields. Account is created before Contact import so that parentcustomerid references resolve on insert. For companies with multiple UPilot contacts, we create a single Account and link all related Contacts.
UPilot
Deal
Microsoft Dynamics 365 Sales
Opportunity
1:1UPilot Deals map to Dynamics 365 Opportunities. Deal name maps to Subject; Deal value maps to EstimatedRevenue; expected close date maps to EstimatedCloseDate. UPilot pipeline stage maps to the Dynamics 365 StageName using a pre-configured Sales Process. Deal currency and any custom deal fields transfer to equivalent custom Opportunity fields. The owner of the Deal in UPilot resolves to the OwnerId in Dynamics 365 via email matching against the User table.
UPilot
Pipeline
Microsoft Dynamics 365 Sales
Sales Process + Stage
lossyUPilot's colored pipeline views with customizable stages map to Microsoft Dynamics 365 Sales Processes and stage values. Each UPilot pipeline becomes a Microsoft Dynamics 365 Sales Process, and each UPilot stage becomes a StageName entry within that process. Stage probability percentages transfer to the StageProbability field. We configure the Sales Process in the target environment before Opportunity import begins so that stage validation does not reject incoming records.
UPilot
Task
Microsoft Dynamics 365 Sales
Task
1:1UPilot Tasks migrate to Dynamics 365 Task records linked via Regarding (object) to the related Contact, Account, or Opportunity. Task subject, description, due date, status, and priority transfer directly. UPilot's inline task editing context (where tasks appear in the 360-degree contact view) is preserved as standard Task records rather than embedded in the Contact form, and the customer's admin adjusts the Contact form layout post-migration to display related tasks via subgrid.
UPilot
Support Ticket
Microsoft Dynamics 365 Sales
Case
1:1UPilot Support Tickets migrate to Dynamics 365 Case if the destination environment includes Service Cloud or if the customer requests Case creation. Ticket subject and description map to Case Subject and Description; ticket status maps to Case Status; ticket priority maps to Case Priority. Conversation threads from UPilot email and live chat channels migrate as EmailMessage records linked to the Case. If Service Cloud is not licensed, we flag this for the customer's admin to confirm scope before migration.
UPilot
Custom Field
Microsoft Dynamics 365 Sales
Custom Field
1:1UPilot custom fields on standard objects (Contact, Company, Deal) map to custom fields on the corresponding Dynamics 365 entity. We perform type mapping during discovery: UPilot text fields map to Text; numeric fields map to Decimal or Integer depending on precision; date fields map to DateTime; picklist fields map to OptionSet. Custom field API names in UPilot are preserved as custom field schema names in Dynamics 365 with a upilot_ prefix to avoid naming conflicts with existing custom fields.
UPilot
Owner
Microsoft Dynamics 365 Sales
User
1:1UPilot Owners map to Dynamics 365 User records resolved by email match. Any Owner in UPilot without a matching User in the destination environment is held in a reconciliation queue. The customer's Dynamics 365 admin provisions missing Users (active or inactive depending on whether the original UPilot user is still employed) before record import proceeds. OwnerId references on Opportunity, Contact, and Task are required to satisfy Dynamics 365 validation rules.
| UPilot | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Pipeline | Sales Process + Stagelossy | Fully supported | |
| Task | Task1:1 | Fully supported | |
| Support Ticket | Case1:1 | Fully supported | |
| Custom Field | Custom Field1:1 | Fully supported | |
| Owner | User1: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.
UPilot gotchas
Per-feature pricing model complicates scope estimation
No publicly documented bulk export API
Two-way email sync state during migration
Task context attached to 360-degree contact view
Hidden onboarding and migration fees
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 extraction planning
We audit the source UPilot environment across active modules (Sales, Marketing, Support), record counts per object, custom field inventory, pipeline count, and owner distribution. We confirm which UPilot features are in active paid use versus enabled but unused, since per-feature pricing affects scope. We map the extraction approach (built-in CSV exports per object) and define the record ordering for re-import into Dynamics 365 so that parent records (Accounts) load before dependent records (Contacts, Opportunities). The discovery output is a written migration scope document and an extraction schedule.
Schema design and Dynamics 365 environment preparation
We design the destination schema in the Dynamics 365 environment. This includes provisioning any required custom fields (with upilot_ prefix and correct field types mapped from UPilot), configuring Sales Processes for each UPilot pipeline, setting up option set values for UPilot picklist fields, and preparing the Contact and Account forms for related-task subgrid display. Schema is validated in a Dynamics 365 sandbox or development environment before any production migration begins. We coordinate with the customer's Dynamics 365 admin to grant the migration service account the necessary Dataverse table permissions.
CSV extraction, transformation, and sandbox migration
We extract data from UPilot in CSV format per object, in parent-before-child record order: Companies (to Accounts), then Contacts (with parent Account lookup resolved), then Deals (with parent Account and Owner lookup resolved), then Tasks (with Regarding lookup resolved). Custom fields are extracted as additional columns in each CSV. We run a full sandbox migration into the Dynamics 365 test environment, reconciling record counts against the UPilot source and spot-checking field values on 25-50 records per object. Mapping corrections happen in the sandbox phase, not in production.
Owner reconciliation and User provisioning
We extract every distinct UPilot Owner referenced on Deals, Contacts, and Tasks and match by email against the Dynamics 365 User table in the production environment. Owners without a matching User go to a reconciliation queue for the customer's Dynamics 365 admin to provision. OwnerId references are required on Opportunity and Contact in Dynamics 365, so this step must complete before production migration begins. We also confirm the migration service account has Dataverse API access and correct table-level permissions.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from UPilot Companies), Contacts (with parentcustomerid resolved to Account), Opportunities (with AccountId, OwnerId, and Sales Process resolved), Tasks (with Regarding resolved to the correct Contact or Opportunity GUID). Custom fields import as additional columns in each batch. Each phase emits a row-count reconciliation report before the next phase begins. We disable UPilot email sync during the production migration window to prevent new threads from creating orphaned records.
Cutover, validation, and automation rebuild handoff
We freeze UPilot writes during cutover, run a final delta migration of any records modified during the migration window, then enable Dynamics 365 as the system of record. We deliver a written inventory of every UPilot Workflow and automation with its trigger conditions, actions, and a recommended Dynamics 365 Power Automate or workflow equivalent for the customer's admin to rebuild post-migration. We support a one-week hypercare window for reconciliation issues. We do not rebuild UPilot automations inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
UPilot
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 UPilot 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
UPilot: Not publicly documented.
Data volume sensitivity
UPilot 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 UPilot to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your UPilot 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 UPilot
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.
