Siebel or homegrown CRM to Salesforce or Dynamics 365
Cohash moves companies off Siebel and homegrown CRMs to Salesforce or Dynamics 365. The business rules buried in eScript, workflows and stored procedures come out first. Then we help choose the platform against your processes and existing Microsoft or Salesforce footprint, map data to standard objects, clean and load it with external IDs and rebuild integrations on APIs or middleware. Business units go live one at a time, and the old CRM stays read-only until it's archived.
- 01Logic and data discovery
- 02Platform decision
- 03Data model mapping
- 04Data migration
- 05Integrations
- 06Rollout and archive
The story
Told without the client's name or anything that could identify them.
A distributor's sales and service organization ran on Siebel, with pricing and territory rules buried in eScript and a shrinking pool of specialist developers to change them. Sellers kept their real pipeline in spreadsheets, and leadership wanted AI assistants the old CRM couldn't support. We read the business components, eScript, workflows and EAI interfaces, and gave each rule an owner and a keep or drop decision before comparing Salesforce and Dynamics 365 against their processes and licences. Data was deduplicated and loaded with external IDs, integrations moved to platform APIs and middleware, and business units went live one at a time while Siebel stayed read-only.
why it was urgentSiebel isn't being retired. Oracle says it supports Siebel CRM through at least 2037. The pressure comes from the targets. Salesforce Winter '27 turns Agentforce on by default, and Copilot in Dynamics 365 Sales works from the records a seller can see. Neither can reach data still locked in an older CRM.
- openSiebel releases need specialist developers who are hard to hire and retain.
- recurringThe homegrown CRM's original developers have left, and changes take months.
- blockedSales and service teams keep their real pipeline in spreadsheets.
- openLeadership keeps asking for AI assistants for sellers and agents. The CRM can't support them.
The estate, before and after
Before: Siebel with rules in eScript and point-to-point links
Sellers worked partly in Siebel and partly in spreadsheets. Business rules lived in eScript and stored procedures, and downstream systems connected through EAI interfaces and direct database links.
Read the diagram as text
- Sellers → Spreadsheets: pipeline
- Sellers → Siebel CRM: opportunities
- Service agents → Siebel CRM: service requests
- eScript and stored procedures → Siebel CRM: business rules
- Siebel CRM → ERP: database link
- Siebel CRM → Billing: EAI interface
- Siebel CRM → Telephony: point-to-point
After: Salesforce or Dynamics 365 with integrations on APIs
Sales and service now share one CRM on standard objects. Back-office systems talk to it through platform APIs or MuleSoft. Older history didn't come across, and it's in an archive people can search.
Read the diagram as text
- Sellers → Salesforce or Dynamics 365: opportunities
- Service agents → Salesforce or Dynamics 365: cases
- Sellers → Searchable archive: history lookup
- Salesforce or Dynamics 365 → MuleSoft or platform APIs: platform APIs
- MuleSoft or platform APIs → ERP: account sync
- MuleSoft or platform APIs → Billing: billing data
- MuleSoft or platform APIs → Telephony: call events
How we run it, phase by phase.
6 phases take you from Siebel CRM or a homegrown CRM to Salesforce or Dynamics 365. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Logic and data discovery
Read Siebel business components, eScript, workflows and EAI interfaces, or the homegrown schema and stored procedures. Write down each rule with an owner who can say whether it's still needed.
- phase 02
Platform decision
Put Salesforce and Dynamics 365 next to your sales and service processes. Then weigh the Microsoft or Salesforce licences you already hold, what has to integrate and the skills you have in-house.
- phase 03
Data model mapping
Map accounts, contacts, opportunities, service requests and assets to standard objects first. Add custom objects only where the standard model clearly doesn't fit.
- phase 04
Data migration
Deduplicate records and standardize addresses and owners. Load with external IDs so relationships survive, and reconcile counts and key fields after every load.
- phase 05
Integrations
We rebuild ERP, billing, telephony and marketing interfaces on platform APIs or middleware such as MuleSoft. Point-to-point database links get retired.
- phase 06
Rollout and archive
Go live by business unit or region, set the old CRM to read-only, and archive history that won't migrate in a store users can search.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Business rules are written down with owners
We pulled pricing, territory and entitlement rules out of eScript and workflows into one catalog. Every rule has an owner and a keep or drop decision.
- result 02
Data sits on standard objects with relationships intact
We mapped accounts, contacts, opportunities, service requests and assets to standard objects before anything custom. External IDs held the relationships together load after load.
- result 03
Integrations run through APIs, not database links
We rebuilt the ERP, billing, telephony and marketing interfaces on platform APIs or MuleSoft. The point-to-point database links are gone.
- result 04
Old history is searchable without the old CRM
Whatever didn't migrate went to a searchable archive, which is what finally let Siebel go from read-only to off.
Risks we plan for
-
Rules buried in code
Pricing, territory and entitlement logic often lives in eScript or stored procedures. Rules nobody documented come back as defects after go-live.
-
Copying the old screens
Rebuilding Siebel views one for one makes the new CRM as hard to use as the old one. Users should see redesigned processes in early demos.
-
Data quality
Years of duplicates and free-text fields carry across unless cleanup is planned and owned by the business.
-
Integration timing
Downstream systems that read the old CRM database break at cut-over unless they're found and moved first.
Where AI helps, and where it needs guardrails
Agentforce and Copilot in Dynamics 365 Sales are only as good as the records they read, so data cleanup is the AI work here. We use LLMs to summarize old eScript and stored procedures into rule descriptions that developers check. Agents and MCP servers that touch the new CRM get their own integration user with field-level limits, and their actions are logged.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Business rule catalog with owners and keep or drop decisions
yours to keep - document02
Platform comparison against your processes and licences
yours to keep - inventory03
Data model mapping to standard objects
yours to keep - code04
Migration scripts and reconciliation reports per load
yours to keep - runbook05
Integration designs and cut-over sequence
yours to keep - plan06
Archive plan for history that stays behind
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Salesforce or Dynamics 365?
It depends on your processes, what you already license, and who will run it. Strong Microsoft 365 and Azure use often favors Dynamics 365. Large sales teams with many integrations and an existing Salesforce footprint often favor Salesforce. We work on both and compare them honestly against your use cases.
02How much Siebel history should we bring?
Usually the open records plus a few years of closed activity. Older history goes to an archive people can search. Legal retention and service warranty rules set the cut-off.
03What drives the cost?
The amount of custom logic, data volume and quality, the number of integrations and how many business units go live separately.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case studyd7f54621 - 01Oracle blog: Siebel CRM support extended through at least 2037blogs.oracle.com ↗
- 02Salesforce Ben: Agentforce auto-enabled in Winter '27salesforceben.com ↗
- 03Microsoft Learn: Copilot in Dynamics 365 Sales overviewlearn.microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it