CRM migration
Field-level mapping, validation, and rollback between Onsite CRM and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Onsite CRM
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
6 of 8
objects map 1:1 between Onsite CRM and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
2-4 weeks
Overview
Onsite CRM has no documented REST API, SDK, or webhook system, which means every migration from this platform begins with in-app CSV exports rather than an API pull. We extract contact lists, company records, deal pipelines, and activity logs from the Weebly-hosted UI, cleanse and normalize the data against a scoping snapshot, then load it into Microsoft Microsoft Dynamics 365 Sales using the Dataverse REST API. The absence of an automated extraction path is the defining constraint of this migration pair; all downstream decisions follow from it. We do not migrate workflows, sequences, or automations, as Onsite CRM's automation layer is not exposed for data extraction, and Microsoft Dynamics 365 Sales has a different automation model (Power Automate and Dataverse workflows) that requires separate configuration. We deliver a written inventory of any automations discovered during scoping for the customer's admin to rebuild 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
Onsite CRM platform overview
Scorecard, SWOT, gotchas, and pricing for Onsite CRM.
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 Onsite CRM 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.
Onsite CRM
Contact
Microsoft Dynamics 365 Sales
Contact
1:1Onsite CRM Contact records (name, email, phone, company association) map 1:1 to Microsoft Dynamics 365 Sales Contact. We extract the contact list via in-app CSV export, normalize the field headers against a scoping snapshot, and load via Dataverse REST API with duplicate detection on email address. The Contact-Company association is preserved as the parentaccountid lookup, resolved against the Account records imported in the preceding phase.
Onsite CRM
Company
Microsoft Dynamics 365 Sales
Account
1:1Onsite CRM Company records serve as the parent entity for Contacts and map directly to Microsoft Dynamics 365 Sales Account. We extract the company list via CSV, set the Account Name and any Industry or Website fields, and load Accounts before Contacts so that the parentaccountid lookup is satisfied at insert time. The company-contact relationship is preserved by resolving the Onsite CRM company identifier to the Dynamics 365 Account GUID.
Onsite CRM
Deal
Microsoft Dynamics 365 Sales
Opportunity
1:1Onsite CRM Deal records (deal name, value, close date, associated contact and company) map to Microsoft Dynamics 365 Sales Opportunity. The pipeline stage name from Onsite CRM maps to the Microsoft Dynamics 365 Sales stage name via a pre-agreed mapping table created during scoping. Deal owner maps to the Dynamics 365 User by email match. We flag any Deals without a resolved Account or Contact as requiring manual review before insert.
Onsite CRM
Pipeline Stages
Microsoft Dynamics 365 Sales
Opportunity Stage (Sales Process)
lossyOnsite CRM's custom pipeline stages are defined per customer configuration and exported as part of the deal export or captured via customer-supplied screenshots during scoping. We map each Onsite CRM stage name to a corresponding Microsoft Dynamics 365 Sales stage value within a Sales Process, preserving stage order and assigning probability percentages. If the customer has multiple pipelines, we recommend one Record Type per pipeline in Microsoft Dynamics 365 Sales .
Onsite CRM
Activities (Call, SMS, Email)
Microsoft Dynamics 365 Sales
ActivityPointer / Task / Email
1:1Onsite CRM activity logs (call records, SMS threads, email logs) are extracted via CSV where the UI exposes them. We map each activity type to the corresponding Microsoft Dynamics 365 Sales activity entity: calls to Task with TaskSubtype=Call, SMS to Task with a custom customertype field, emails to EmailMessage. The regardingobjectid links each activity to the resolved Contact, Account, or Opportunity. If the Onsite CRM export does not include activity history, we flag this for manual re-entry and note it as a scope limitation in the migration report.
Onsite CRM
Task
Microsoft Dynamics 365 Sales
Task
1:1Onsite CRM Task records for follow-ups and reminders map directly to Microsoft Dynamics 365 Sales Task. Status, Priority, Due Date, and Subject transfer 1:1. Task assignee maps by email match to a Dynamics 365 User. Tasks without a resolvable owner are placed in a reconciliation queue for the customer's admin to resolve before final load.
Onsite CRM
Custom Fields
Microsoft Dynamics 365 Sales
Custom Fields
lossyOnsite CRM custom fields on Contacts, Companies, Deals, or Activities require manual mapping during scoping against the Microsoft Dynamics 365 Sales schema. We create matching custom fields in the destination Dataverse environment before migration, apply the appropriate field type (text, number, picklist, date), and map each custom field value during the transform phase. Any Onsite CRM custom field without a Dynamics 365 equivalent is flagged in the scope document for the admin to decide whether to create a new field or drop the data.
Onsite CRM
User / Owner
Microsoft Dynamics 365 Sales
User
1:1Onsite CRM User records map to Dynamics 365 User by email match. We extract the distinct owner references across all Contact, Company, Deal, and Activity records and match them against the destination org's User table. Any Onsite CRM owner without a matching Dynamics 365 User is held in a reconciliation queue. The customer's admin provisions missing Users in the Microsoft 365 admin center before the migration proceeds to the record load phase.
| Onsite CRM | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Contact | Contact1:1 | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Pipeline Stages | Opportunity Stage (Sales Process)lossy | Mapping required | |
| Activities (Call, SMS, Email) | ActivityPointer / Task / Email1:1 | Fully supported | |
| Task | Task1:1 | Fully supported | |
| Custom Fields | Custom Fieldslossy | Mapping required | |
| User / 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.
Onsite CRM gotchas
No public API documentation found
Weebly-hosted infrastructure limits data access
Limited historical activity export
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
Scoping and export feasibility assessment
We conduct a scoping call with the customer to identify the Onsite CRM objects in use (Contacts, Companies, Deals, Pipeline Stages, Activities, Tasks, Custom Fields), approximate record volumes, and any known custom field configurations. We request customer-supplied screenshots of the Onsite CRM data structure to confirm what the UI exposes for export. If activity history is required, we explicitly ask whether the UI export includes call logs, SMS, and email records or whether those must be handled as manual re-entry. The scoping output is a written migration scope document with a confirmed object list, record counts, and any export gaps flagged as scope limitations.
Customer-side CSV export and data delivery
We guide the customer through the in-app CSV export process for each object. Exports are requested in the following order: Companies (first, because they are parent to Contacts), Contacts, Deals, Pipeline Stages (captured as a separate mapping reference), Activities (where available), Tasks, and Custom Field values. We provide a data delivery checklist and a field header reference so the customer knows exactly what columns to include. Exports are delivered to us via a secure transfer mechanism. We validate row counts and spot-check field completeness against the scoping snapshot before proceeding.
Microsoft Dynamics 365 Sales environment preparation
We provision or validate the destination Microsoft Dynamics 365 Sales environment: confirming the Dataverse API is enabled, the migration user has the necessary Dataverse permissions (Create, Read, Update on the relevant entities), and any required custom fields and entities are pre-created. We coordinate with the customer's Dynamics 365 admin to temporarily disable or extend validation rules that could reject Onsite CRM-formatted data, and to grant field-level security relaxation for the migration user during the load window.
Data normalization and transform
We normalize the exported CSV data: standardizing date formats to UTC, cleaning phone number formatting, splitting combined name fields where present, resolving Onsite CRM company identifiers to Account GUIDs, and resolving owner emails to Dynamics 365 User GUIDs. Custom field values are mapped to the destination custom field schema. Any records with missing required fields are flagged in a reconciliation report for the customer to address before load. We do not suppress or auto-correct data without the customer's approval; the reconciliation report is the decision point.
Sandbox migration and reconciliation
We run the first full migration into a Microsoft Dynamics 365 Sales Sandbox environment using the Dataverse REST API with batch chunking. The customer reconciles record counts against the source CSV exports, spot-checks 20-30 records for field-level accuracy, and signs off before production migration begins. Any mapping corrections identified during sandbox reconciliation are applied before the production phase. Sandbox migration typically takes one to three days depending on record volume and any API rate-limit pauses required.
Production migration in dependency order
We run production migration in record dependency order: Accounts (from Companies), Contacts (with parentaccountid resolved), Opportunities (with regardingobjectid resolved and stage mapping applied), Tasks, Activities (via Dataverse API with batch processing and exponential backoff on rate-limit responses), and Custom Field values. Each phase emits a row-count reconciliation report. After all standard objects load, we run a final validation pass comparing source record counts to destination record counts and surface any discrepancies in a written report.
Cutover, delta capture, and handoff
We freeze Onsite CRM writes during the cutover window and run a final delta export of any records modified after the initial export date. The delta is merged into Microsoft Dynamics 365 Sales and validated. We enable Microsoft Dynamics 365 Sales as the system of record and deliver the migration completion report including record counts by object, any unmapped fields or dropped records, and a list of automations or custom fields requiring post-migration configuration. We support a three-day hypercare window for reconciliation issues. We do not rebuild Onsite CRM automations as Power Automate flows; we deliver a written inventory of any automations discovered during scoping for the customer's admin to rebuild.
Platform deep dives
Onsite CRM
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 3 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 Onsite CRM and Microsoft Dynamics 365 Sales .
Object compatibility
3 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
Onsite CRM: Not publicly documented.
Data volume sensitivity
Onsite CRM 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 Onsite CRM to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Onsite CRM 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 Onsite CRM
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.