- Define the destination before importing
- Test with a controlled sample
- Plan the transition
Define the destination before importing
Agree on pipeline stages, ownership rules and required fields in Dappr's own CRM. An export from the old system is a source file, not a finished data model. Decide how old statuses map to the new process.
Inventory contacts, opportunities, activity history and attachments separately. Determine what can actually be exported and what requires a different handling method. Keep a record of permissions and restrictions on using the information.
Test with a controlled sample
Use a limited sample to check field mappings, dates, duplicates and relationships. Compare records in the destination with the original source. A successful file upload does not prove that the imported information means the same thing.
Identify records that require human decisions, such as conflicting owners or uncertain contact permissions. Do not silently manufacture missing information. Document exclusions and preserve a recoverable source copy under the business's access rules.
Plan the transition
Specify a cutover point, treatment of changes made during migration and reconciliation checks. Train staff on the destination workflow before relying on it for live follow-up. Keep a route for correcting discovered errors.
Dappr's migration scope is into Dappr's own CRM. It is not an offer to configure or operate a third-party CRM. Bring the source inventory and desired destination process so feasibility, access and responsibilities can be assessed before a schedule is promised.
Inventory what the business actually needs to retain
A migration is not simply a transfer of every available field. A fictional landscape-maintenance company may have active estimates, former customers, old notes, and records with uncertain status in its source system. Decide what remains useful and what must be reviewed before it becomes part of the destination workflow.
This is an illustrative example. Dappr's migration service is into Dappr's own CRM, subject to assessment of the source export and destination requirements. It does not include general administration of the old platform or a promise that every attachment, activity type, and custom object can be transferred unchanged.
Separate destination configuration from source records
The destination needs agreed stages, owners, field meanings, and access rules before imported data can be evaluated properly. Microsoft distinguishes configuration data from migration data in its Dynamics 365 guidance. That is external implementation context, not an offer by Dappr to deploy or manage Microsoft's CRM.
For the landscape company, an old status called active might mean an open estimate, an ongoing customer, or merely a contact that has not been archived. Map those meanings to the new process explicitly. Copying the same label into Dappr's CRM would not resolve the ambiguity and could create misleading follow-up or reporting.
Make uncertain records visible for review
Identify missing required values, conflicting ownership, duplicate contacts, and ambiguous communication permissions. The migration should not silently invent answers to make an import succeed. Assign a business reviewer to decide which records can be corrected, excluded, or retained with a documented limitation.
For the fictional company, two contacts with similar names may be different people, while one customer may appear under several email addresses. A merge rule needs more than a superficial match. Preserve the reasoning for consequential cleanup decisions so the owner can investigate a later discrepancy without guessing what happened during preparation.
Test relationships as well as field values
A representative sample should include contacts linked to opportunities, records with history, and difficult dates or missing information. Compare the destination with the approved source interpretation. A successful upload and matching record count do not establish that the right opportunity belongs to the right customer.
Microsoft's migration guidance includes mapping, testing, validation, and cutover planning. Apply those broad planning questions to the assessed Dappr migration rather than importing vendor-specific steps uncritically. The exact transfer method depends on the available export, destination capabilities, and permissions confirmed for the project.
Plan for changes while the migration is underway
The landscape company may continue receiving inquiries during preparation. Define the point at which the destination becomes authoritative and how changes made before that point are captured. Employees need one understood process for live follow-up so the transition does not create a second, conflicting queue.
If a final import fails or reveals a material issue, define the response before the business relies on it. Preserve an appropriate recoverable source copy under the owner's access rules and document what has been changed. The project should not assume that deleting the old account immediately is a necessary part of a successful migration.
Accept the working process in the destination
Have staff find an active estimate, identify its owner, review the relevant history, and take the next permitted action in Dappr's CRM. Check reports against sample records and review excluded or unresolved data. This connects technical reconciliation with the work the business needs to perform after cutover.
Bring Dappr the source inventory, export options, desired stages, and team responsibilities. The scope should state what can be moved, what needs separate handling, and what cannot yet be confirmed. No fixed transfer duration, zero-loss guarantee, or universal source-platform compatibility is promised without examining the actual data and constraints.
Questions before you begin
Can every field and attachment move into Dappr CRM?
That cannot be assumed. Feasibility depends on the source export, data types, destination requirements, permissions, and available transfer methods. Inventory the information first and test representative records. The scope should identify exclusions or separate handling instead of promising a perfect copy of every source feature.
Why is a sample migration useful?
It reveals mapping, relationship, date, duplicate, and interpretation problems before a broader transfer. Compare the sample with the approved source meaning and the destination workflow. A file uploading successfully is only one part of validation.
Should old contacts automatically enter new follow-up sequences?
No. Review the reason for retaining each group and the applicable communication permissions and restrictions. Preserve exclusions and opt-outs. A data migration is not by itself authorization to send new messages or assume every old record represents an active opportunity.
When should the old system be retired?
Use an agreed transition and reconciliation plan. Confirm that staff can perform the required work in the destination and that necessary records are preserved appropriately. Account closure or deletion is a separate consequential decision, not an automatic step triggered by the first successful import.