Moving into a CRM without losing the history

A CRM migration fails rarely at the import and often in the weeks afterwards. The pattern is consistent. Two records exist, both are partly right, and the team drifts back to whichever one they trust. Every failed rollout has that same middle chapter. Nothing below it is technically difficult, and all of it is a decision somebody has to make out loud.

Name the day the old system stops

A migration with no cut-off runs both systems indefinitely, and the double entry makes everybody resent the new one. A date, announced in advance, is the single most useful decision in the whole project. The date also forces the other decisions. A team that knows the spreadsheet closes on the fourteenth asks its questions in the week before, rather than in month three.

Decide what genuinely needs migrating

Contacts and their open work always make the move. Ten years of closed jobs usually do not, and moving them delays everything else. The old system can stay readable for the history while the new one carries only the live work. That split halves the work and removes most of the risk. A business insisting on moving everything usually spends its energy on records nobody will open again.

Map the columns before importing anything

An import that guesses at columns produces addresses in the notes field and phone numbers that never dial. Diract CRM shows each column and asks which field it is, which turns a risky import into a reviewable one. Twenty records first is the other half of that discipline. A sample reveals every mapping mistake the full file would make, and it takes a minute to read. Four hundred records imported badly is four hundred corrections rather than twenty.

Match on email or phone, not on name

Importing four hundred contacts into a list holding three hundred produces duplicates nobody can unpick afterwards. A name match fails on Bob and Robert, on a married surname, and on a company recorded two ways. Our guide to duplicate contacts covers matching before the import rather than cleaning up afterwards. Diract CRM matches on email or phone during the import, which is where the problem is cheapest to solve.

One person owns the migration

A move that belongs to everybody stalls at the first disagreement about a field name. One named owner, with the authority to decide, gets it finished inside a fortnight. The team still needs telling, and telling early. Staff who discover a new system on the morning it arrives treat it as something done to them. A fortnight's notice, with a named contact, makes them participants instead.

Start with one team, not the whole business

A pilot with the people who will benefit most produces the answers the rest of the rollout needs. It also produces internal advocates, which matters more than any amount of training material. Their own shortcuts deserve asking about first. A staff member with a filtered view or a saved search has built something that makes their week work. Rebuilding those converts the people most likely to resist.

Run one report the day you finish

The quickest way to expose a bad import is a question whose answer the business already knows. A customer count, a total, or last month's jobs shows a mismatch immediately. Finding it that day is cheap. Finding it in March means three months of decisions made on a number nobody checked.

Expect to change the fields in month two

No business designs its fields correctly before using them, and an honest plan allows for that. Diract CRM lets a business add and adjust fields later, which makes a rushed first guess survivable. The old identifiers deserve a field of their own too. A business that referred to customers by a number will still have invoices and emails citing those numbers. Bringing the old reference into a field keeps that search working years later.

Retire the old system properly

A system left running becomes the one somebody keeps updating, and then both are wrong again. A stated date, read only access, and one person answering questions close the project honestly. Diract CRM imports a spreadsheet by showing each column and asking which field it is, so a mapping mistake surfaces before the file runs. The fields stay adjustable afterwards, which lets a business commit to the date without designing everything first.

What to change first

• A cut off date gets named and announced in advance
• Only contacts and open work come across, not every closed record
• Each column maps to a field before the import runs
• Matching happens on email or phone rather than on name
• Twenty records import first, as a sample
• One named person owns the migration and its decisions
• The old system goes read only on the stated date