Contact
Privacy
Legal Notice - Impressum
Career
News
Telecom CRM is not a customer database. It runs active service orders, holds the contract terms that drive billing, and connects to the OSS systems that deliver service. Migrating it to Salesforce Communications Cloud (Agentforce Communications) only works when orders keep moving, subscriber history arrives complete, and the catalog is rebuilt for the new data model.
Most CRM migrations can tolerate a short freeze. Telecom cannot. While the project team plans cutover, customers are still ordering broadband, porting numbers, upgrading plans, and calling support. Every one of those interactions depends on the system being replaced.
That is why a telecom move to Salesforce Communications Cloud, which Salesforce has also marketed as Agentforce Communications, is a different kind of project from a standard Sales or Service Cloud migration. This article looks at what telecom CRM data actually carries, what changes in the Communications Cloud data model, and how to plan a Communications Cloud migration that keeps service running through cutover.
Telecom CRM is operational, not just relational. It holds work in progress that the business cannot pause, and its records drive downstream systems that physically deliver service.
At any moment, a telecom CRM holds orders that are mid-flight: a fiber installation waiting on a technician, a mobile plan change pending activation, a business circuit halfway through provisioning. These orders have state. Migrate them as static records and they stop moving, because the target has no idea which step comes next.
Service agreements hold contract start dates, minimum terms, promotional pricing, and renewal conditions. Billing reads from them. If terms arrive incomplete, the first invoice after go-live is wrong, and the support queue fills with disputes the migration created.
The CRM is the commercial front end of a larger stack. Orders flow from it into operations support systems that configure networks and activate services. A migration that breaks those connections, even briefly, leaves orders stranded between systems that no longer agree on their status.
The data model changes, and the catalog and order structures change most. Communications Cloud is built on an industry model that separates what a customer buys from what the network has to deliver.
In the Communications Cloud catalog, product specifications act as reusable templates, and offers are the sellable, priced instances built from them. The shared catalog models both commercial products that customers order and technical products used internally to provision service. Many legacy telecom catalogs are flatter, with pricing, bundling, and fulfillment logic mixed into the same product records. They have to be redesigned for the target model, not copied into it.
When an order is placed, decomposition converts the commercial products in it into technical products, and an orchestration plan runs the sequence of fulfillment tasks across the relevant systems. An order migrated from a legacy CRM has to arrive with enough structure to fit this flow, at the right step, or it cannot complete.
Accounts, service agreements, assets, cases, and interaction history all have to land in the right relationships. Agents in Communications Cloud work from the account view. If history is detached during the move, agents answer calls with an empty record in front of them.
They break down where the legacy system's live state does not survive the move. Three failure points account for most of the damage.
Order capture logic rarely maps cleanly into the target structure. If in-flight orders are loaded without their current state, or after the source has stopped tracking them, they sit between systems. Customers wait, technicians arrive for orders the CRM no longer recognizes, and service teams reconcile by hand.
Subscriber history is often the last thing scoped and the first thing cut when timelines slip. The result is a go-live where agents inherit incomplete account, case, or interaction history, and every call starts by asking the customer to explain what already happened.
When catalog hierarchies are moved without being redesigned, pricing rules, bundle structures, and partner offers fail to execute. Revenue teams lose control of what is being sold and at what price, and the rework lands after launch, when it is most expensive.
These are structural problems, similar to the ones that make certain Salesforce objects break data migration projects. Generic tools built for flat record transfer do not account for them.
Plan for continuity first and volume second. The question is not only how many records will move, but how the business keeps serving customers while they do.
Start with a readiness assessment of every source system. Count subscribers, but also count open orders by state, document BSS and OSS integration points, and measure how deep the catalog hierarchy goes. Timelines and cost depend on exactly these factors, so they belong in the plan before budget is committed.
Decide how legacy products map to specifications, offers, and technical products in the target, and document the decisions. Metadata matching across source and target shows which fields, status values, and process rules need transformation and which have no direct equivalent.
A single cutover weekend is the riskiest option for telecom. A staged migration keeps the source system live while data moves in validated waves, with data sync and replication keeping order state consistent between the two. Customers keep ordering, and nothing is frozen for longer than it has to be.
Every integration point with billing, provisioning, and partner systems needs a cutover plan of its own. Decide when each connection switches from the legacy CRM to Communications Cloud, which system owns an order while it is in flight, and how partner offers reconnect through their APIs. Treat these switches as part of the migration scope, not as follow-up integration work, because an order that cannot reach provisioning after go-live is a service outage, not a data issue.
Run full test loads, confirm that in-flight orders and their dependencies land at the correct step, and reconcile records against the source after every cycle. Real-time migration tracking keeps each cycle visible to project owners and service leaders without waiting for a status report.
conemis runs the move as a staged, validated migration rather than a single cutover event, so service continues while data moves.
The readiness assessment maps active order states before migration begins. Catalog hierarchies are documented and redesigned for the Communications Cloud native data model rather than migrated as-is. Iterative test loads confirm that in-flight orders and their dependencies transfer correctly ahead of go-live, and records are reconciled against the source system throughout, so open orders and their history carry into Communications Cloud without manual rework.
conemis transition cloud (ctc) handles subscriber accounts, service agreements, billing records, active and historical orders, product catalogs, pricing structures, CPQ configurations, contract terms, partner offers, custom objects, and attachments. Sources include Salesforce, Microsoft Dynamics 365, Oracle CX, ERP systems, and custom applications.
See how telecom teams move to Communications Cloud without losing service context on our Communications Cloud migration page, book a demo, or contact the conemis team to scope your migration.