[DRAFT — contains assumed details. Before publishing, replace: client industry, legacy system, number of users, records migrated, project duration, team size, number of rehearsals and cutover window. Then delete this notice.]
Enterprise CRM migrations are notoriously risky. In this case study we walk through the complete migration of a business with 50 million dollars in revenue from a legacy CRM to Salesforce Sales Cloud and Service Cloud — with zero downtime.
The starting point
The client is a B2B distribution business whose sales and support teams, around 300 people, ran on an on-premise CRM that had been customised for more than ten years. It worked, but it had become the bottleneck: reporting took days, every change needed a specialist, and it could not connect cleanly to the tools the rest of the business had adopted. The brief was to move to Salesforce without the sales and support teams losing a working day.
Why “no downtime” was the hard requirement
Support could not stop answering customers and sales could not stop quoting. That ruled out the simplest approach, which is to switch the old system off, migrate, and switch the new one on. Everything in the plan followed from that constraint.
Phase 1: Data mapping and cleansing
Half the effort in any migration is the data. We mapped every legacy field, deduplicated records, and archived what did not need to move. Clean data in is the single biggest predictor of a smooth cutover.
In total, roughly 1.2 million records were migrated. Before any of them moved, we agreed with each department which records were still needed, who owned each field and what a duplicate meant for accounts and contacts. Fields nobody could explain were archived, not migrated.
Phase 2: Custom Apex and integrations
Off-the-shelf Salesforce rarely fits an enterprise as-is. We built custom Apex, Lightning Web Components, and 12 integrations to connect billing, support, and marketing systems.
We kept one rule throughout: configure first, write code only where configuration could not do the job. Every customisation in the old system was reviewed and either rebuilt, replaced by a standard Salesforce feature or retired.
Phase 3: Rehearsals
We ran three full rehearsal migrations into a sandbox before the real one. Each rehearsal was timed, the results were checked against the source and the problems found were fixed before the next. By the last rehearsal the team knew how long every step took and what could go wrong at each one.
Phase 4: The cutover weekend
We ran a parallel sync, validated record counts, and kept a tested rollback plan ready at every step. Users logged in Monday to a fully populated system.
The cutover ran from Friday evening to Sunday afternoon. The legacy system stayed available in read-only mode throughout, so nobody was locked out of customer information. Each stage had a go or no-go check with a named decision-maker, and the rollback plan had been rehearsed, not just written.
The first weeks after go-live
For the first two weeks the project team stayed on call alongside the client’s administrators, with a daily review of issues raised by users. Most were questions about where things now lived, not defects, which is what a well-rehearsed migration looks like.
What made it work
- Data decisions were made by the business, not guessed by the technical team.
- The migration was rehearsed until it was routine.
- Old and new systems ran in parallel, so there was always a way back.
- A small, senior team. six people over five months, with the same people from mapping to go-live.
What we would do differently
Start user training earlier and freeze legacy customisations sooner. Adoption, not technology, is where most CRM projects stall.
Training that begins a fortnight before go-live is too late for people to form habits. And every change made to the old system during the project is a change that has to be migrated twice.
If you are planning a CRM migration
- Decide what data you actually need before you decide how to move it.
- Budget as much time for data and training as for building.
- Rehearse the full migration more than once.
- Keep the old system readable until the new one has proved itself.
- Name one person who can say go or stop at each stage.
Explore our Salesforce development services, see ready-built software solutions and accelerators, or read more enterprise case studies.
