How Do You Clean CRM Data Before a Business Central Sales Implementation?
Prepare customer and contact data for Business Central sales processes, with practical rules for duplicates, ownership, mapping, migration and testing.
What is the quick answer?
Clarify the target system first: Business Central sales functions and Dynamics 365 Sales are different products. Inventory your customer and contact data, assign owners, define the future structure and resolve duplicates before mapping and trial migration. Preserve identifiers and relationships, reconcile the result and test complete sales transactions. If Dynamics 365 Sales is also involved, agree record ownership and synchronisation rules before connecting it to Business Central.
What does a Business Central sales implementation actually mean?
Business Central manages sales documents and related finance and inventory processes. Dynamics 365 Sales is a separate customer engagement application that can integrate with it. The distinction matters because a project may involve moving a customer spreadsheet into Business Central, replacing a CRM, connecting the two applications or doing several of these things together.
Microsoft’s Dynamics 365 Sales integration guidance explains the relationship between the applications. Write the intended architecture before cleaning data. Identify which records belong in Business Central, which remain in another system and which will be shared. Avoid referring to an undefined “Business Central Sales” product in a migration plan.
Our Business Central implementation services provide the wider context for that decision. Give the project a clear definition of success, such as creating an accurate sales order for an existing customer without rekeying or losing agreed terms. That is more useful than a target to import every CRM row.
↑ Back to contentsWhy should data cleaning begin before migration templates arrive?
Many important decisions do not depend on the final import format. You can establish who owns customer information, identify conflicting sources and investigate obvious duplication before a partner supplies a workbook. Starting early gives the business time to resolve questions that cannot be answered by a technical mapping exercise.
A large row count can create a false sense of progress. Importing records quickly does not establish that they represent the correct trading entities or contain terms that finance has approved. The difficult work is often deciding which version is authoritative and understanding how employees actually use the fields.
Our Business Central implementation preparation guide recommends assigning owners to data and acceptance. Give those owners protected time and a route to resolve disagreements. Do not leave every decision with an administrator who knows the existing CRM screens but lacks authority over commercial terms, finance controls or the business’s retention requirements. Early ownership makes later technical work less dependent on guesswork.
↑ Back to contentsWhich data sources should you inventory first?
List the systems, spreadsheets and local lists used to identify customers, contacts, delivery locations and active sales work. Include information held by finance and operations, not only the CRM. A sales team may maintain relationship details while finance controls invoicing names and credit terms, and dispatch holds the delivery instructions that staff trust.
For each source, record its owner, purpose, identifiers, approximate volume and last meaningful review. Identify which fields are maintained and which are merely copied from somewhere else. This distinguishes an authoritative source from a convenient export. Keep a copy of the original extraction with a date and a controlled record of subsequent changes.
For businesses moving beyond entry-level accounting, our Xero versus Business Central guide describes the wider operational context. Customer records often need to serve more processes after the move. Establish those needs before deciding that the finance customer list alone, or the CRM export alone, is a complete description of the trading relationship.
↑ Back to contentsWho should decide which customer record is correct?
Assign responsibility by type of information. Sales may understand the relationship and account hierarchy, while finance should approve credit and invoicing fields. Operations can confirm delivery locations and service instructions. A data steward can coordinate the work, but coordination should not obscure who has authority to approve a particular decision.
Create a small decision register for disputed records. State the conflict, the evidence available, the owner and the resolution. Repeated disputes may reveal a missing business rule rather than isolated poor typing. For example, staff may disagree because one team uses a customer name to describe a group and another uses it to describe a single legal entity.
Our Business Central finance implementation services are relevant where customer data affects financial processing. Ensure that finance can review the fields driving invoices, credit and reporting. Do not let a general cleaning rule replace an approved accounting decision. A tidy appearance is useful only when the resulting record still describes the correct commercial arrangement.
↑ Back to contentsHow should you define the future customer and contact structure?
Draw the relationships before mapping columns. Distinguish the party placing an order, the party being invoiced, the delivery destination and the individual contact. Then identify how groups, branches and trading names should be represented in the target design. These concepts are related but are not interchangeable customer duplicates.
Use a few representative accounts to test the structure. Include a simple account, a group with multiple locations and an account where ordering and invoicing responsibilities differ. Ask sales, finance and operations to explain how each should work. Resolve the design in workshops before asking a large cleaning team to apply it repeatedly.
In Business Central distribution and supply chain processes, delivery instructions can be operationally important. Do not flatten several genuine delivery locations into one address just because the parent customer name is the same. The objective is a useful target model with appropriate relationships, not the smallest possible number of records.
↑ Back to contentsHow do you find duplicates without merging the wrong organisations?
Use several signals to identify candidate duplicates, then review them against business evidence. Names, addresses, domains and historic identifiers can help, but none should automatically settle every case. Two organisations may share a building or a contact, while a single organisation may have changed its name or moved.
Define match rules and confidence levels in a staging dataset. Obvious formatting differences can be standardised safely; uncertain identity decisions should be routed to the owner. Keep the original identifiers and a record showing which source records were associated with the retained record. That cross-reference becomes important when reconciling orders, balances and integrations.
A Business Central retail business may hold the same customer across several channels. Investigate whether those records should be connected, retained separately for a valid reason or excluded from the ERP migration. Do not merge solely because an email address matches. Shared inboxes and intermediaries can represent several distinct commercial relationships, and an incorrect merge can be difficult to unwind after transactions begin.
↑ Back to contentsWhich fields need standardisation before you map them?
Create a field dictionary covering meaning, format, permitted values and ownership. Start with fields that drive processing: customer identifiers, names, addresses, currency, payment terms, tax information and classifications used by the target process. Document how blank, unknown and not-applicable values differ instead of replacing all three with the same convenient default.
Standardise obvious format variations in controlled copies, while preserving the original value for comparison. Check country and address conventions, leading zeros in identifiers and date interpretation. A spreadsheet can display an identifier attractively while changing its stored value. Test the exported file, not just what appears on screen.
For Business Central manufacturing sales processes, distinguish distributors, end customers and delivery destinations where that distinction matters. Avoid using free-text customer categories as a substitute for an agreed relationship model. Confirm which classifications will support real reporting or controls. Extra fields with no owner can become another source of inconsistency after go-live.
↑ Back to contentsWhat should you do with inactive records and old opportunities?
Decide what the future operating system needs, what should remain accessible in a controlled archive and what should be removed under the organisation’s approved requirements. Do not use the migration as a reason either to copy everything indefinitely or to delete inconvenient records without review.
Distinguish an inactive account from one with outstanding commercial or financial activity. A customer with no recent new orders may still have an open balance, a service obligation or an unresolved dispute. Give those cases an explicit treatment. Agree the historical lookup process so staff can answer legitimate questions without importing unnecessary records into daily operations.
Our NAV to Business Central migration guide is relevant when legacy identifiers and transaction history complicate the decision. Retain the cross-reference needed to trace migrated data back to its source. Have the appropriate business owners approve exclusions and archive access. A clear migration boundary is more useful than a vague promise that every piece of old information will remain available somewhere.
↑ Back to contentsHow should you handle email, consent and sensitive information?
Separate operational contact information from marketing permissions and other restricted information. Do not infer permission for a new use simply because an address exists in the old CRM. Identify the business owner responsible for the applicable privacy, retention and communication rules, and include that person in the migration decisions.
Review free-text notes and attachments because they often contain information that does not belong in a broadly accessible customer record. Decide which material is necessary for the future process, where it should be stored and which roles need access. Avoid giving a large cleaning team unrestricted copies merely to make the exercise easier.
Use controlled working locations, access permissions and a clear method for returning corrections. Protect extracts during transfer and remove unnecessary working copies when the approved process allows. The project should be able to explain where each copy is, who can access it and why it is needed. Data cleaning should reduce uncertainty about information, not create a second collection of uncontrolled customer files.
↑ Back to contentsHow do you map source fields to Business Central safely?
Map the agreed business meaning to the target field and its validation requirements. A similarly named column may represent something different in the old application. Record conversions, defaults and exceptions explicitly so another reviewer can understand the result without relying on the person who built the first spreadsheet.
Microsoft’s configuration package guidance describes an initial company setup approach and its limitations. Select the import method with the implementation team. Do not assume that an initial migration method is appropriate for bulk corrections in an established production company.
Test dependencies before a full trial. A customer record may require valid related values, and a contact may need an agreed relationship to the relevant organisation. Produce a rejected-record report that explains the business correction required. Avoid silently substituting defaults merely to make an import pass. A successful import should reflect approved decisions, not just the absence of a technical error.
↑ Back to contentsWhat changes if Dynamics 365 Sales will synchronise with Business Central?
Agree which application owns each shared field and how changes are expected to move between them. Decide how existing records will be matched and how new records will be created. Without this design, connecting the applications can distribute inconsistent data faster or create duplicate records in both places.
Test a few controlled changes in each direction permitted by the design. Include an update, a new record, a conflict and a record that should remain outside synchronisation. Review the logs and the resulting business records. Users need to know whether they should correct the source, wait for synchronisation or raise an integration incident.
Microsoft describes coupling between corresponding records in the two applications. Preserve the identifiers and mappings that make that relationship understandable. Do not assume a bulk import automatically establishes the correct coupling. Confirm related data dependencies and decide how unresolved matches are handled before broad synchronisation. Treat the initial connection as a controlled release with owners and acceptance evidence, rather than a checkbox to enable at the end of migration.
↑ Back to contentsHow do you test whether the cleaned data supports sales work?
Run complete business scenarios after a trial load. Create a quote, convert or progress it through the intended sales process, deliver where appropriate and produce the expected invoice. Ask the team to verify the customer, addresses, prices, terms and reporting classifications. A record count cannot establish that these relationships are correct.
Include exceptions: a customer with a different invoice party, an account on hold, a foreign-currency order and a contact who should not receive a particular document. Choose scenarios relevant to your business rather than treating this as a universal test script. Record the expected outcome before reviewing the result.
Our Business Central bank reconciliation guide provides useful context for the downstream finance consequences of customer transactions. Coordinate the sales-data test with finance reconciliation so an apparently correct order does not conceal an incorrect balance or application. Business owners should approve the end-to-end result, with the implementation partner supporting investigation of technical behaviour.
↑ Back to contentsWhich controls protect financial and tax information?
Have finance approve the treatment of opening customer balances, payment terms, credit information and posting-related fields. Reconcile totals to the agreed source and investigate differences at a useful level of detail. Keep the reconciliation separate from the question of whether customer names and addresses have been cleaned successfully.
Where a field affects tax or statutory reporting, involve the responsible specialist in the mapping and test decisions. Do not copy a legacy classification merely because it has always been used, and do not let a technical cleaner decide a new treatment without authority. Document the approved interpretation and the evidence supporting the result.
For UK VAT processes, our Business Central Making Tax Digital guide explains the wider setup and submission context. A cleaner customer dataset is one dependency among several, not proof that tax reporting is correct. The migration acceptance should identify which financial checks were completed, who approved them and what remains for the wider implementation test plan.
↑ Back to contentsWhen should you freeze changes and prepare the final load?
Agree a cutover plan that distinguishes the preparation extract, trial migrations and final data movement. Staff will continue changing customer information during the project, so define how those changes reach the final load. A cleaned extract from several weeks earlier is not automatically a current dataset.
Choose who can make changes during the freeze period and how urgent exceptions are recorded. Keep the instructions practical for sales teams still serving customers. The final load needs a known source, an approved set of transformation rules and a reconciliation method. Preserve enough evidence to explain the difference between the last trial and the live result.
Set a decision point before releasing users into the new process. Review import failures, unresolved duplicate decisions, important reconciliations and the results of representative transactions. If a problem remains, state the operational consequence and the owner. A go-live decision should be based on understood risk and acceptance, rather than the assumption that any remaining data problem can be cleaned later.
↑ Back to contentsHow do you stop the new customer data becoming unreliable again?
Define who creates records, which checks occur before creation and who can change sensitive fields. Give users a route to report a suspected duplicate without merging or deleting records informally. Maintain the field dictionary and make business rules understandable to the people entering information during a busy working day.
Review a small set of useful indicators, such as incomplete records blocking orders, duplicate candidates awaiting decisions and integration errors without owners. Explain changes in those measures. A rise in detected duplicates may mean that a new control is working, not that staff suddenly became less careful.
Use the first trading cycles to refine the process. Keep recurring questions and corrections visible, and decide whether the remedy is training, a validation rule, an ownership decision or an integration change. A successful migration is the beginning of a maintained data process. The objective is customer information that continues to support accurate sales and finance work after the project team has moved on.
↑ Back to contentsWhat else do businesses ask?
Is Dynamics 365 Sales the same as Business Central?
No. Dynamics 365 Sales is a separate customer engagement application. Business Central has sales and finance processes and can integrate with Dynamics 365 Sales when that architecture fits the requirement.
Should we delete every duplicate before migration?
Investigate candidate duplicates and approve the treatment. Some similar records represent genuine branches, delivery locations or separate legal entities. Preserve identifiers and relationships when records are consolidated.
Can we clean the data after go-live instead?
Some improvement can continue afterwards, but unresolved identity, financial and relationship problems can disrupt live processing. Agree essential readiness criteria and trial the data before release.
Who wrote this guide, and how was it checked?
Written by Caleb Adoh, Growth Marketing Manager at NetMonkeys. Product distinctions, integration and initial configuration references were checked against Microsoft Learn on 2 November 2026. The cleaning and acceptance methods are original editorial guidance. Confirm the target design, import method, access and applicable information requirements with the responsible business owners.
How can NetMonkeys help your business?
Talk to our team about your priorities and agree a practical next step.
Speak to NetMonkeys
