Migrating 120 people onto one CRM: year one

A CRM migration looks like a software project. By month three, I had already learned it was a behaviour project with software in the middle.

When I joined LOOV as CTO, the operations side ran on three separate systems. Retail front-of-house used one tool, fulfilment another, and the clinic intake lived in a Google Sheets workflow with manual exports into the other two. Reports were stitched together on Friday afternoons by Polina, our analyst, and any decision taken on Monday morning was working from numbers that had aged a weekend.

The brief from the COO was simple: one system of record by year end. The first 90 days taught me that "simple" was the wrong word.

Why Bitrix24, not best-in-class

We evaluated three options seriously: keep the three tools and integrate them, move to amoCRM as the operational core, or move to Bitrix24. amoCRM is strong on sales pipeline and weaker on workflow; Bitrix24 has a broader workflow surface and weaker analytics. I argued against integration for two reasons.

First, integrations are an organisational bet, not a technical one. Every connector adds a place where a process can disagree with itself. An order acknowledged in tool A but not yet in tool B is not a bug, it is the gap between two definitions of "order". You can paper over that with sync jobs, but you spend the rest of your year defending the seam.

Second, the people running the operation already understood one mental model per silo. Two integrated tools mean two mental models plus an arbitration layer. One tool means one mental model plus the cost of teaching it everywhere. The first cost is unbounded.

We picked Bitrix24. It covered roughly 80% of the three flows out of the box. The remaining 20%, especially the medtech intake and prescription workflow, we built as custom modules on top.

Three waves, not a big bang

We migrated by domain, not by geography or department. The order was deliberate:

1. Customer of record: who they are, where they are, what they bought.
2. Order lifecycle: how a request becomes a fulfilled outcome.
3. Clinical and post-sale touchpoints: prescriptions, warranties, follow-ups.

Each wave moved one definition. By the time wave three started, the team already trusted the system because waves one and two had been running in production for six and three weeks respectively.

The wave structure also made every step reversible. On Friday of week four of wave one, the daily sales report from Bitrix did not match the legacy. The COO escalated by 9pm. We rolled back to legacy in 90 minutes, and Maria, our retail ops lead, ran Saturday's shifts on the old tool. By Monday morning we had found the bug: a join in the migration script that was excluding orders flagged "demo" in legacy but used in production. Fixed, re-deployed, rolled forward by Tuesday. If we had migrated all three flows at once, the same bug would have stopped the whole company for the weekend.

Where I burned six weeks

One mistake on record. The medtech intake module got rewritten twice in year one.

The first version was modelled on a clinical flow we had documented in week two. In production it turned out the regional clinics used four variants of that flow, and the variation was load-bearing for compliance. The first version forced a single flow, and the regional medical lead refused to sign off in week 16. We rewrote the module from scratch in weeks 18 to 24, on top of running wave three.

Six weeks of engineering time, real cost. The lesson is dull and important: when the domain has regulatory variance, field research is not optional. I had treated it as optional because the COO wanted year-end, and I owe the team an apology for that. I shipped the apology in writing at our December retro. It changed how we scoped wave three and how we sized year two.

What the system became

By month nine, Bitrix had stopped being where data lived and become where work happened. In practice:

• Tasks, follow-ups, clinical reminders. Not a separate task tool. CRM records owned by an account, visible to the assigned person, sliced into manager dashboards from the same view.
• Internal tools we built (loyalty admin, returns workflow, escalation triage) wrote into Bitrix, not into a side database. We refused to add a second source of truth.
• The order-to-fulfilment cycle dropped from a median of 36 hours (three-system stitched) to 11 hours (single workflow), measured on the same SKU mix in February against October.

Sixty-plus dashboards came out of this, and 60-plus is not a brag, it is a scar. We over-built dashboards in months six to nine because the team could finally see the data and got greedy. About 20 of those got retired in year two because nobody opened them.

What happened the Monday after

The Monday after wave three closed, I sat with Maria and Polina and we killed 14 dashboards in one session. Polina, who had been stitching reports on Friday afternoons for two years, moved to a senior analyst role inside the new structure. The COO got her Friday afternoons back. I got an analyst embedded into the engineering team starting in year two, which is the thing I should have done in week one.

That is the actual end of a CRM consolidation. Not the migration date, not the architecture diagram. The Monday when the people who used to fight the system stop having to.