From Legacy to Agentic CRM: The Boring Work Nobody Talks About

Everyone is talking about AI agents in CRM. Fewer people talk about what has to be true before an agent can make a single useful decision.

We started this programme before COVID, and years before anyone was pitching agents. Nobody in the room used the word "agentic". But the target we wrote down at the beginning was already the same one everybody is chasing now: a CRM that can act on the current state of the business, automatically, without a human first assembling the truth from five systems.

The client is a European insurance group, and I will keep it at that. The shape of the problem is what matters, and it will look familiar to anyone in insurance, banking or manufacturing: a long-lived core CRM holding roughly a decade of customer history, a modern CRM platform waiting to be used properly, and an integration layer built for nightly batches in an industry that had started to expect answers in seconds.

The scale, in round numbers: millions of accounts, tens of millions of policies, tens of millions of claims, and millions of open activity records.

Here is how the programme actually ran.

A note on sequence

The phases below are a rollout sequence, not a project plan. Migration and streaming were designed and built in parallel from the start, by the same architecture group, on purpose. The event backbone was never a follow-up project bolted on afterwards, it was the destination we were migrating towards.

What was sequential was the go-live: you cannot stream trustworthy events out of a system whose records have not landed yet. So migration went first through the rollout waves, with the streaming layer already standing behind it.

That distinction is worth dwelling on, because most modernization programmes get it backwards. They migrate first, declare success, and only then ask what the data is for.

Phase 1: Migration, the unglamorous foundation

This is where most of the effort went, and where these programmes usually stall.

We built the migration and integration layer on Apache Camel. Open source, no incremental license cost, and full control over routing and transformation. Three decisions mattered more than the technology choice:

Wave-based rollout, not big bang. Business units went live in waves. Each wave had its own export, conversion, load and verification cycle. A problem in one wave never put the others at risk, and the playbook got sharper with every wave.

Rollback designed before go-live. Every migrated object type had a defined reversal path: restore the source record state, remove what the conversion created, return access to where it was. We rehearsed rollback as seriously as we rehearsed the migration.

Conversion logic treated as a business decision. Open activities in the source system had to become opportunities in the target. That is not a data mapping question, that is a process question. We modelled several variants, walked the business through what each one would mean for daily work, and let them choose. Automated conversion won, and it won because the people who would live with it picked it.

Migration is not a data problem. It is a change management problem wearing a data problem as a costume.

Phase 2: From batch to stream

Once records were landing correctly, the constraint that had always been there became visible: freshness.

Kafka became the event backbone. Instead of downstream systems asking "what changed since last night", they subscribed to what was happening as it happened. Camel handled the translation, enrichment and mapping between the backbone and endpoints that were never designed to be event driven, which in an insurance landscape is most of them.

The first benefit had nothing to do with AI. A change made in a core system appeared in the CRM in seconds. Claim status was visible without a phone call. Advisors stopped working from yesterday's picture of the customer.

Phase 3: Widening the integration surface, and instrumenting it

A CRM is only as useful as the systems around it. After the core migration we connected the surrounding landscape: calendar and mail so interactions were captured instead of manually logged, documents and notes with their retention and access rules intact, policy and claims systems so the customer view reflected the contractual reality and not only the sales conversation.

Every integration adds surface area, so every integration also has to add observability. The part of this phase I am most attached to is the least glamorous: incident routing.

Every failure raised by the platform was classified automatically and opened in the right place. A data quality issue that a business team had to resolve became a ServiceNow ticket in that team's queue. A technical fault in a route, a mapping or an endpoint became a Jira issue for the integration team. Same detection, two different audiences, no triage meeting in between.

The reason this matters more than it sounds: in a landscape this size, the bottleneck is never detection. It is the twenty minutes somebody spends deciding whose problem it is. Removing that step is what let a small team operate a platform that large.

Phase 4: Making the data agent-ready

This is the phase most organizations skip, and it is why so many AI pilots stall at the demo.

An agent does not fail because the model is weak. It fails because it cannot answer basic questions with confidence. Is this the current version of the record? Which of these addresses is authoritative? Does this claim belong to this policy? Was consent given for this purpose?

The work here is specific and unglamorous:

• Stable external identifiers across systems, so an upsert is deterministic rather than hopeful
• Consistent status semantics, so "open" means the same thing in every system
• Lineage, so any record can be traced back to what produced it
• Access and consent boundaries encoded in the data model, not in a document somebody will forget to read

Near real-time delivery plus trustworthy semantics is what turns a data platform into a decision platform. One without the other gets you a fast way to be wrong.

Phase 5: Agents that actually do something

Only here does the interesting part become possible. Because events arrive in near real-time and the semantics hold, an agent can reason about the current state of the business rather than a snapshot.

That changes what you can attempt. Not "summarize this account" but something closer to: this renewal is forty days out, the customer opened a claim last week, that claim is not going well, so suppress the upsell campaign and route this to a human advisor with the context attached.

That single decision requires four systems to agree on the truth within seconds. It is an integration achievement before it is an AI achievement.

What I would tell anyone starting this journey

Check your license inventory before you buy anything. A lot of enterprises already own integration and CRM capability they have not switched on. Activating what you have is usually cheaper and faster than adding a new vendor.

Open source is not the risky choice. Camel and Kafka carried a landscape of hundreds of millions of records through a multi-year programme. The risk in enterprise integration is rarely the technology. It is the lock-in you accept to avoid having to think about the technology.

Build in parallel, roll out in sequence. Design the destination early, even if it goes live last. If you only start thinking about streaming and data semantics after the migration is signed off, you will rebuild half the migration.

Route incidents by audience, not by severity. Business data issues and technical faults are different problems with different owners. Deciding that automatically, at detection time, buys back more capacity than any dashboard.

Agentic CRM is a data engineering discipline. The model is the easy part now. The hard part is, and always was, making a large organization agree with itself about what is true.

We set out on this before the hype, and the sequence has not changed: get the records right, get the events flowing, get the meaning stable. The agents are the last mile, not the first.