Skip to content

Data

Switching CRM without losing listings: from 2 live listings to 29.

By Felix Grant4 min read

A CRM switch rarely loses data outright. It loses the connections: the feeds that publish listings to your website and portals, the fields those feeds depend on, and the automations nobody remembered existed. For one client, a switch had left 2 listings live. After we worked through it, 29 were live. The plan below is the one we use so it doesn't happen in the first place.

Why

Why listings stall after a CRM switch

In property, recruitment, motor trade and similar businesses, the CRM is not just a contact list. It is the source for everything published: listings on your own website, on portals, in email alerts and on social channels. Each reads from the CRM through a feed or integration.

When the CRM changes, the records usually arrive safely. What breaks is everything downstream. Feeds expect fields that no longer exist, or now have different names or formats, and a listing missing a required field is quietly rejected. Status values change, so the old Available becomes the new Active and the feed only publishes one of them. Portal connections, website plugins and email tools set up years ago are never moved. Images link to the old system's storage, which is switched off.

And rejections go nowhere. Portals and websites often reject a listing without telling anyone. The first sign is a phone call asking why a property isn't online. None of this shows inside the new CRM, where everything looks fine.

Map

Mapping data and feeds

Before switching, build two lists. The first is a field map: every field in the old system, its equivalent in the new one, its format, and which feeds use it. Status needs its values mapped one to one. Price needs to be a number without a currency symbol if that is what the feeds expect. The main image needs a public link in the new storage. Mark which fields each downstream feed requires, because those are the ones that will silently drop a listing if they are wrong.

The second is an integration list: everything that reads from or writes to the CRM, including websites, portals, email marketing, phone systems, accounting, document signing and reporting. For each one, note who owns it, how it connects and how you will test it.

Ask the team, not just the IT supplier. The people who use the system every day know which reports and automations they rely on.

Test

Testing before you cut over

Never switch on the strength of a successful import. Run both systems side by side for a short period if the new CRM allows a test environment. Publish a small set of real records from the new system to every destination: website, each portal and email alerts.

Check each destination by eye. Is the listing there, is the price right, are the images showing, is the status right? Check the rejection logs on every portal and feed, not just the success messages. Only then switch everything, and keep the old system readable for a while in case something needs checking.

A clean import is not a clean switch.
The lesson behind 2 listings becoming 29

What we did

What we did

When we were brought in, the switch had already happened and 2 listings were live. We worked through it in the same order, after the fact.

We counted what should be live from the new CRM and compared it with what was actually published on each destination. We pulled the rejection logs from each feed to see why listings were being dropped. We built the field map that should have existed before the switch and corrected the fields and values the feeds required. We re-tested with a handful of listings, checked each destination by eye, then republished the rest. And we added an alert so a drop in live listings is spotted quickly next time. At the end, 29 listings were live.

Checklist

A cut-over checklist

Four weeks before: list every integration and feed, build the field map with required fields marked, agree how status values map across, confirm where images and documents will be stored with links that won't expire, and choose a cut-over date away from your busiest week.

Two weeks before: import a test set of records, publish it to every destination and check each one by eye, check every rejection log, and train the team on the new statuses and required fields.

On the day: freeze changes in the old system, run the final import, count live listings on each destination before and after and write both numbers down, and switch integrations one at a time, checking each.

For the first two weeks after: compare live listing counts with the CRM daily, check rejection logs daily, keep the old system readable, and set up an alert for any drop in live listings. That daily comparison is a small automation that pays for itself the first time it fires. If you are planning a CRM change, talk to us before you move the data, not after. A Discover audit lists the integrations, builds the field map and tests the cut-over plan with you.

Key takeaways

  • CRM switches break the connections, not usually the data
  • Map every field and mark which ones each feed requires
  • Publish real test records to every destination and check by eye
  • Read rejection logs, not just success messages
  • Count live listings before and after, then daily for two weeks
Felix Grant

Written by

Felix Grant

Founder of Kitebox, a business technology and AI consultancy that builds what it recommends. Based in Mallorca, working with UK businesses.

About Felix →

Want this set up for your team?

Book a call and we'll show you how the queue, veto window and logs would work for your content.