CRM data migration: exporting, mapping fields, and running both systems for a while

As the last day of the contract approaches, the export keeps getting postponed; once access closes, only old screenshots are left. That is why the export is the first line of the switch plan. The file you take is kept as a copy and never worked on; every fix happens on a second copy. At the Bursa wholesaler, the sales manager could take this on: taking an export before the contract ends, putting the files in a dated folder, and running the selection of the new system on those files. The questions to ask while choosing are in questions for choosing a CRM.

Most CRMs give tables as separate files: companies in one, people in another, opportunities in a third. What ties the files together is the record IDs. If the ID column is missing from the export, which company a person belongs to can only be guessed from the name.

• Companies and people, with their record IDs
• Open and closed opportunities, with stage and value fields
• Notes and tasks, with the card each belongs to
• The list of custom fields and the values each can take
• Users, and which card belongs to whom

Attachments and email history are the pieces most often lost. Ask the old provider in writing whether they can be exported; if not, at least save the files that belong to open work by hand. Take the user list and who owns which card in the same export; a card whose owner is unknown opens without an owner in the new system.

The mapping table starts with columns for the old field, the new field, and a note. Stage names need their own work. If the old system has separate stages called 'met', 'quote sent', and 'on hold', and the new system names them differently, which new stage each old value lands in is decided in advance.

Custom fields nobody fills in are not moved. The wholesaler's old system had fields opened years ago for a campaign and then forgotten; they were marked 'not moving' in the mapping table. You can see the steps for preparing the file itself in the CRM migration checklist.

If both systems are updated at the same time, the question of which one is right comes up within days. The rule is simple: from the first day after the import, new customers, opportunities, and notes are written only to the new system. The old one stays open a little longer for anyone who needs to look back.

At the wholesaler, every salesperson opened the cards of a few of their own customers in the new system on the first morning and compared them with the old record. Missing fields went onto a single list, the mapping table was corrected, and the second import ran with that fix.

At the end of the parallel period the old system is made read-only or closed. Before closing it, one last export is taken, because records may have gone into the old system between the first file and closing day. The two files are compared; any difference is entered into the new system by hand, and only then is access to the old one removed.

Even if the new system accepts history, not everything has to move. The wholesaler might find last season's customer conversations worth moving; older records stay in the dated folder, and the sales manager looks there when needed. Conversations tied to open opportunities and recent customers come first. Old closed work can stay in the archive folder; who can access the archive should be written down too, because the export file holds personal data and falls under KVKK (Turkey's personal data protection law).

A salesperson learns the new system from their own customer's card, not from a general tour. If there is a trial environment, a copy of the imported file is loaded there and every salesperson opens a few cards they know. This is also when the change in stage names is explained; if someone keeps using the old word, the mapping table is shown.

Permissions are written down at this stage too. Who sees which card, who can delete, whose cards go to whom when someone leaves: these are decided by role, not by person, and set up in the new system before switch day. At the wholesaler, for example, the warehouse lead would not see opportunities, while the sales manager would see every card.

Moved records settle on the customer card. The card has tabs such as Overview, Contacts, Opportunities, Quotes, Contracts, Projects, Finance, Files, and Drive, and the quote and the contract sit in their own tabs on the same card. Modules are not separate products and share the same customer record, so a moved record is the same card in every module. You can see how the card is built on the Corex360 CRM module page.

Bring a sample of the export from your old system to the demo; which records will move is discussed using that file, and the mapping table you prepared is the basis of that conversation.