How do you prepare data for migration from Excel or an old CRM?

Start by creating an unchanged copy of the source data and listing every place where the company keeps it. Then decide what should be moved, how customers and contacts will be identified, which fields correspond to each other and how missing or duplicate records will be handled. Plan the final switch only after a trial import has been checked.

Exporting a CSV file does not prove that the data is complete or ready to use. A customer list may omit links to contacts, notes, attachments, history, tasks or access information. Migration is therefore more than moving rows from one table to another.

A CSV file is only one source

CSV is a common exchange format for spreadsheets and business systems. Even its basic structure requires consistent handling of headers, separators, line endings and values containing commas or quotation marks. Different applications may also generate the file in different ways.

The business meaning is more important than the file syntax. A field called `Customer` may identify a company in one source and a person in another. `Status` may mean a sales stage, payment state or whether a contact is active. Similar labels do not guarantee equivalent data.

Also check for information stored outside the main table, including:

• contacts assigned to companies;
• notes and conversation history;
• tasks, deadlines and reminders;
• documents and attachments;
• orders, cases or sales opportunities;
• consents, contact sources and record owners;
• values held only in additional sheets or files.

If the new system is expected to use this information, each group needs its own migration plan. Do not assume it will appear in an export merely because it was visible in the old CRM.

1. Secure the data before cleaning it

Keep the original export or backup in a place where nobody will edit it. Record the export date, source system, scope and responsible person. Preserve every source separately when the data comes from several applications or spreadsheets.

Never clean the only copy. Work on a duplicate and keep a log of the changes. This makes it possible to return to the source, compare values and explain why a particular decision was made.

Confirm whether staff will continue editing the old system. If preparation takes days or weeks, the first export will become outdated. The plan may need a final export or a way to move the changes made after the trial copy.

The backup method depends on the system and available permissions. An export from the administration panel does not always include the database, files and full history, so its scope must be confirmed for the specific solution.

2. List every source and decide which value is authoritative

Many companies keep some data in a CRM, some in spreadsheets and the latest arrangements in email or personal notes. Name these places, identify who uses them and decide who resolves conflicts.

When the same field has different values in two sources, the import script should not silently choose one. The company needs an agreed rule, such as using the order system for the last order date while the CRM remains authoritative for the assigned account manager.

3. Decide what to migrate and what to archive

Moving every historical record may increase cost and still make the new system harder to use. Divide the data into:

• active records needed in current work;
• historical records that should remain available for reference;
• records requiring a decision because their owner, status or purpose is unclear;
• duplicates, test records and obsolete technical entries that should not be copied automatically.

Archiving does not mean deleting data without a decision. It means agreeing where the information will remain, who can access it and how it can be found. Retention periods and legal obligations should be confirmed by the organisation responsible for the data.

4. Prepare a field map

A field map describes how every important source value will be represented in the target system.

The map should cover meaning, format, required values, allowed values and the handling of gaps. It should also say who approves the rule. A developer can implement a transformation, but should not decide the business meaning of conflicting statuses.

5. Preserve identifiers and relationships

Record counts alone do not prove a successful migration. A company can be present in the new CRM while its contacts, notes or open cases are linked to the wrong account.

Check which identifiers are stable in each source. Names, email addresses and telephone numbers can change or be shared. Internal identifiers may be safer, but only if they are unique and consistently exported.

Plan how to preserve relationships such as:

• company to contacts;
• customer to orders or cases;
• case to notes and attachments;
• record to assigned employee;
• parent record to subsidiaries or branches.

When the target system generates new identifiers, retain a migration mapping from old IDs to new IDs. It helps investigate discrepancies and repeat a trial import.

6. Set explicit rules for duplicates and missing values

Duplicate detection should use more than one field. The same company may appear under a short and a registered name, while different people may share a general office address. A matching email or telephone number can be useful evidence, but is not always sufficient for an automatic merge.

Create separate rules for:

• definite duplicates that may be merged automatically;
• likely duplicates that require human review;
• records that look similar but must remain separate;
• missing values that may remain empty;
• missing values that block the import;
• conflicting values that need an owner decision.

Never invent missing information during migration. If the company cannot confirm a value, leave it empty or mark it for review according to an approved rule.

7. Run a trial import on representative data

Do not test only the cleanest records. The sample should include common cases as well as difficult ones: missing fields, national characters, long notes, duplicates, several contacts linked to one company, attachments and unusual statuses.

The trial should be repeatable. Record the source version, import settings, transformation rules and result. If it fails, correct the rule or data and run it again in a controlled environment rather than editing the target records by hand.

8. Validate the result at several levels

After the trial import, check:

1. totals for each record type;
2. required and business-critical fields;
3. relationships between records;
4. dictionaries, statuses and assigned owners;
5. dates, telephone numbers, email addresses and character encoding;
6. notes, files and history included in the agreed scope;
7. representative cases selected by process owners;
8. whether users can complete their real work with the migrated data.

People who understand the data and the process should participate in acceptance. A salesperson may notice an incorrect account owner or case stage much faster than the person who wrote the importer.

9. Plan the switch and a way to stop it

After a successful trial, agree the final export time, the period when changes in the old system will be restricted and the people authorised to accept the result. The plan should answer:

• when editing in the old CRM stops;
• whether changes made after the trial require a final delta export;
• how much time is reserved for validation;
• who decides that work may start in the new system;
• what happens if the acceptance criteria are not met;
• how long and in what form the old source or archive remains accessible.

A migration cannot always be completed without interruption. The answer depends on both systems, the number of daily changes and the available exchange mechanisms. Do not promise a cutover time before the actual case has been inspected.

10. What should you prepare before speaking to a provider?

You do not need to send the full database at the beginning. Prepare:

1. a list of systems, spreadsheets and additional sources;
2. a description of what the data means in daily work;
3. important fields, statuses and relationships;
4. approximate numbers of records, files and attachments;
5. information about active and archival data;
6. known problems with gaps, formats and duplicates;
7. the expected timing and acceptable work restrictions;
8. a person authorised to make data decisions;
9. acceptance criteria for the trial and final migration;
10. an anonymous or synthetic sample showing the structure.

Do not submit passwords, keys, real customer data or a database copy through an initial contact form. Start with a description and a safe structural sample. A secure transfer method can be agreed later if the project requires real data.

If you are not yet sure whether the company needs an off-the-shelf CRM, an integration or a custom system, use the CRM solution planner. It helps organise the requirements, but it does not inspect uploaded data or estimate a migration.

What do previous Domin Software projects show?

In the historical HUB.ITM.PL project, we built a system that read data from different accounting applications and transformed it into the EDI++ format used by Subiekt GT and Subiekt nexo. It reduced manual entry of large numbers of invoices in an accounting office. The project is no longer in production because data formats and exchange conditions changed. It demonstrates experience in mapping multiple sources, but does not promise compatibility with current software versions.

In HUB-2-API, the system imported a large product list from a spreadsheet and used it to manage eBay.de listings, orders and an API for three customers in France. This was a product and order flow, not a migration of customers from an old CRM. It still shows why source structure and target rules must be understood before automation.

In both cases, the meaning of the data and the validation method mattered more than the file format itself.

Frequently asked questions

Is an Excel or CSV export enough for migration?

Usually not. It may contain the basic fields, but relationships, notes, history, attachments, dictionaries and identifiers must be checked separately. The scope depends on both systems.

Do all records from the old CRM have to be migrated?

Not always. Some information can remain in an agreed archive while current data moves to the new system. The data and process owner should approve the decision.

How should duplicate customers and contacts be detected?

First define which combination of attributes proves a duplicate and how history will be retained. A similar name, shared email or telephone number is not always enough for an automatic merge.

What should happen to missing or conflicting values?

Set a rule for every important field. A value may be marked for review, left empty or translated through an approved dictionary. The system should not invent information.

Can notes, history and attachments be preserved?

Sometimes, but it depends on the source export, API, file structure and import capabilities of the target system. Feasibility must be confirmed before the scope is agreed.

How can a trial import be checked?

Compare record totals, key fields, relationships and dictionaries, then review representative cases. Also confirm that users can complete their daily process with the migrated information.

Can migration be completed without stopping the business?

This cannot be guaranteed without inspecting both systems. A short freeze and final export may be enough, or a transition stage and additional integration may be required.

How can a sample be shared safely for an estimate?

Begin with a structural description and synthetic or anonymised sample. Do not send passwords, keys, a full database or real customer data through an ordinary form.

Choose the next step

If you are still choosing a solution, use the CRM solution planner. It helps determine whether an off-the-shelf CRM, integration, additional module or custom system is more suitable.

If the process is already defined and the company needs a tailored solution, explore custom CRM and ERP systems. Migration scope and pricing require an inspection of the sources, relationships, data volume and target capabilities.

If the old and new systems need to operate in parallel or exchange data regularly, use the system integration planner and review our system integration and API service. A one-off migration and an ongoing integration are different projects.

Sources

• RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files, RFC Editor, accessed 30 October 2026.