Replacing a homegrown or Siebel CRM nobody wants to touch with Salesforce or Dynamics 365
A homegrown CRM is due for replacement once changes wait on the one or two developers who know it, sellers keep the real pipeline in spreadsheets, or leadership wants AI assistants it can't support. Cohash pulls the business rules out of the code, maps data to Salesforce or Dynamics 365 standard objects and moves business units one at a time.
- 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.
- openEvery new report means a developer writing SQL against the homegrown database.
- recurringLeadership keeps asking for AI assistants for sellers and agents. The CRM can't support them.
The estate, before and after
Before the move, Siebel kept the rules in eScript and fed other systems point to point
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.
After the move, the pipeline lives in the CRM and the ERP gets account data over 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.
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
Records sit on standard objects and still link to the right accounts
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
One catalog of the business rules we dug out of the code, each signed off by an owner as keep or drop
yours to keep - document02
A side-by-side of Salesforce and Dynamics 365 run against your own processes and the licences you already pay for
yours to keep - inventory03
Data model mapping to standard objects
yours to keep - code04
Migration scripts, and a reconciliation report of counts and key fields after every 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
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Entitlement
- One permission in one system, like being able to post journal entries in the finance app. Someone who's been at a company a few years usually has dozens.in context →
- 02Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 03ERP
- Enterprise resource planning. It's the system finance and operations staff live in: the ledger, purchasing, sales orders, stock and often production, all in one database.in context →
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
01Should we keep our homegrown CRM, rebuild it, or replace it?
Keep it if it does something no packaged CRM handles well and you still have developers who know the code. A rebuild on newer tech usually ends up with the same problem, because the knowledge still sits with a few people. If most of the work is accounts, contacts, opportunities and cases, move to Salesforce or Dynamics 365 and rebuild only the parts that really are different.
02Salesforce 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.
03How 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.
04What 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 studyMoving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.
read the case study5c506dbe - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
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