An Oracle Siebel to Salesforce migration is the rare displacement where the destination is more expensive on every metric except user experience. A fully amortised Siebel estate carries only its annual support cost — most clients pay 22 percent of an original net licence purchased fifteen to twenty years ago. Salesforce charges 100 percent of subscription value every year. The Siebel-to-Salesforce business case has to be honest about that fact or it fails on first read. This article lays out the buyer-side licensing and data migration arithmetic we use to defend our clients through Siebel displacement: the Concurrent User reconciliation that protects against the Oracle audit, the data migration cost honestly priced, the dual-run window, and the renewal redlines that a credible Oracle Siebel to Salesforce migration plan unlocks at the next Siebel support renewal. Every figure is benchmarked against real engagements — 600+ Oracle programmes, $1.8B in advised spend, and the failure modes we have seen eat 20 to 35 percent of every Salesforce displacement that started from a vendor-built business case.
The honest financial picture of an Oracle Siebel to Salesforce migration is this: the destination is structurally more expensive than the source. Salesforce's per-user subscription on Sales Cloud Enterprise list price is $165 per user per month. Siebel's annual support on a fully amortised estate where the perpetual licence was bought in 2008 runs at roughly $42 per Concurrent User per month — and a Concurrent User typically supports 2.5 to 3.5 named users due to login concurrency patterns. The Salesforce cost per named user is therefore 9 to 12 times the Siebel support cost per equivalent named user. The migration has to justify that gap on capabilities Siebel cannot deliver — mobile-first usability, ecosystem integration, AI-assisted sales, AppExchange depth, configurable workflow without per-customisation Siebel CRP cost.
The buyer-side framework starts by acknowledging the gap. Most vendor-built Salesforce business cases hide it. They quote the Siebel cost as full-list-price re-purchase of the legacy Siebel licences rather than the actual annual support paid on the amortised entitlement. The customer's CFO sees a fictional comparison that makes the migration look financially obvious. When the real Siebel cost is loaded honestly, the migration only makes sense for an estate where Siebel is genuinely failing the business — mobile usability, integration, partner channel, or regulatory reporting that Siebel cannot deliver. Where Siebel still serves the business adequately, the right outcome is often a renegotiated support contract that holds the cost flat for another five to seven years.
The forensic baseline is the first deliverable on every Siebel-to-Salesforce engagement we run. It pulls every Siebel CSI, every Order Form, every supplement, reconciles the Concurrent User entitlement against actual S_OPER table usage, and produces the true Siebel cost per named user that the Salesforce business case has to beat. See the Oracle database licensing guide for the broader entitlement framework that surrounds Siebel.
The Siebel Concurrent User metric is measured by simultaneous active sessions, not by named users. A Siebel customer who has licensed 800 Concurrent Users can have 2,400 named users defined in the S_USER table provided the simultaneous session count stays at or below 800 during peak operating hours. The metric is mathematically friendly to the customer when usage patterns are bursty (sales reps logging in to update opportunities a few times a day) and mathematically unfriendly when usage is sustained (call centre agents logged in for an eight-hour shift).
The audit exposure on Siebel concentrates on the Concurrent User count. Oracle LMS audits the Siebel estate by examining the S_SESSION_MON and S_USER_HIST tables to find the peak concurrent session count during a representative period. If the peak exceeds the licensed Concurrent User entitlement, LMS publishes a back-licence claim at full list price for the difference. We have defended this exact claim multiple times. The buyer-side defence framework reconciles the LMS-published peak against (1) actual session validity windows, (2) load-test sessions and synthetic monitoring sessions that LMS counts but were never licensed, (3) session timeout configuration that creates phantom concurrency, and (4) failover and HA session duplication. Each defence point typically reduces the claim by 40 to 70 percent.
| Siebel metric | What it covers | Common audit exposure |
|---|---|---|
| Concurrent User (Power User) | Simultaneous active sessions, full transactional access | Peak concurrency above licensed entitlement |
| Concurrent User (Mobile) | Mobile / disconnected client sessions | Sync sessions counted toward concurrent peak |
| Concurrent User (Self-Service) | Partner portal, customer portal sessions | Anonymous / unauthenticated sessions incorrectly counted |
| Application Read Only (Siebel) | Downstream reporting consumers | BI tools, ETL processes pulling Siebel data without AppRO entitlement |
| Siebel CRP per-customisation | Configured business components or applets | Customisations created outside the licensed CRP count |
| EAI / EIM | Integration interfaces | Service-account integration users counted against the EAI metric |
The Concurrent User reconciliation has to be completed before the Salesforce migration RFP is issued. Once Oracle LMS sees the RFP, the audit opens, and the reconciliation has to be defensive rather than proactive. We have closed Siebel audits where the LMS-published claim opened at $2.4M and closed at $360K after the forensic concurrent-user reconciliation. The Audit Defence service framework covers the full forensic defence sequence.
Trap to avoid: Synthetic monitoring sessions, load-test sessions, and HA failover sessions all show up in the S_SESSION_MON table during an LMS audit. Build the defence narrative for each one before the RFP is issued; once LMS opens the audit the burden of proof shifts to the customer.
Independent, evidence-based Oracle Siebel to Salesforce licensing and data migration economics. Forensic Concurrent User reconciliation, audit reserve sizing, edition mix optimisation.
Salesforce's per-user cost depends on the edition assigned to each role. The buyer-side discipline is to assign every named user to the cheapest edition that supports the actual workflow rather than the edition the Salesforce sales team would prefer. Most Siebel-to-Salesforce migrations we have audited at the eighteen-month mark show 15 to 30 percent of users on a higher edition than their workflow requires, paying a $50 to $130 per-user-per-month premium for capability they do not use.
The per-user steady-state cost on a typical mid-market Salesforce estate, properly edition-mixed, lands at roughly 4 to 6 times the equivalent Siebel support cost per named user. On poorly edition-mixed estates it lands at 8 to 12 times. The buyer-side approach negotiates the edition mix in the Master Subscription Agreement and locks downgrade rights for users who are over-licensed at any renewal anniversary. The Contract Negotiation service framework transfers directly to Salesforce contract negotiation; the same redline disciplines apply to both vendors.
Data migration is the longest critical-path activity in an Oracle Siebel to Salesforce migration. Siebel estates accumulate ten to twenty-five years of customer interaction history in tables whose schemas the original integrator no longer remembers, with foreign key relationships that were modified by every change request along the way. The Salesforce SI's data migration line will quote half what the work actually costs because the SI scopes against the tables Salesforce expects to see, not the actual Siebel schema. The buyer-side model has to load the full data migration cost honestly.
| Data migration phase | Effort | Typical cost (2,400-user estate) |
|---|---|---|
| Schema lineage and mapping | Forensic schema audit, business rule extraction | $320K–$680K |
| Data quality remediation | Duplicate cleanse, address standardisation, deceased flag | $240K–$520K |
| Archive-versus-migrate decision | Per-entity retention policy, regulatory mapping | $80K–$180K |
| Migration tooling | MuleSoft / Boomi / Informatica / Salesforce Migration Tool | $120K–$360K subscription + dev |
| Test migration cycles | 3 to 5 dress rehearsals before go-live | $280K–$640K |
| Cutover weekend execution | Frozen Siebel, delta capture, Salesforce load, reconciliation | $180K–$420K |
| Post-cutover reconciliation | 30 to 90 days of two-system reconciliation labour | $120K–$320K |
| Siebel read-only archive | Frozen Siebel instance for regulatory lookup | $60K–$140K per year ongoing |
On a 2,400-user estate the full data migration line runs $1.4M to $3.3M and consumes 25 to 35 percent of the total Salesforce migration budget. The Siebel read-only archive line is the one most often forgotten. Regulatory data retention frequently requires the Siebel data to remain queryable for seven to ten years after retirement. The cheapest archive strategy is a frozen Siebel instance on a small VM with Oracle Database Standard Edition 2 — but this only works if the residual Siebel entitlement is licensed correctly for the reduced run-state. We sequence the Siebel licence right-sizing into the migration plan explicitly, which the Support Reduction service covers in detail.
We audit the actual Siebel schema, score the lineage, and produce a defensible data migration budget. Buyer-side numbers only.
The case is anonymised from a 2025 engagement. A European financial services firm with 2,400 named users running on a Siebel Financial Services estate licensed at 950 Concurrent Users, originally purchased in 2007, fully amortised, $1.4M annual support spend. They were facing pressure from sales leadership to move to Salesforce Financial Services Cloud, and engaged us to build the Oracle Siebel to Salesforce licensing and data migration economics as either a credible exit or a credible negotiation lever.
| Cost line (5-year, USD) | Stay on Siebel | Migrate to Salesforce FSC |
|---|---|---|
| Siebel application support (5-year, 6% uplift) | $7,900,000 | $3,400,000 (terminated month 24) |
| Oracle DB support (Siebel database) | $1,400,000 | $580,000 (terminated month 26) |
| Siebel-side audit reserve | $0 modelled | $680,000 (LMS audit during RFP) |
| Salesforce Financial Services Cloud subscription | $0 | $22,400,000 (2,400 users × 60 months) |
| SI implementation + change management | $0 | $8,200,000 |
| Data migration + archive | $0 | $2,400,000 |
| Integration redevelopment | $0 | $1,800,000 |
| Dual-run cost | $0 | $1,200,000 |
| Siebel right-sized residual (archive-only) | $0 | $280,000 |
| 5-year total | $9,300,000 | $40,960,000 |
The migration is structurally more expensive than staying on a fully amortised Siebel estate. The board decision was driven by the capability gap: Siebel could not deliver the mobile experience the field sales team needed, and the Open UI roadmap was not credible against the timeline. The migration was approved. We negotiated the Siebel side hard ahead of the Salesforce contract: a 38 percent reduction on Siebel support for the dual-run window, audit suspension, and a stepped reduction tied to user retirement milestones. The Salesforce-side negotiation followed the same disciplines we apply to Oracle: edition mix, downgrade rights, ramp clauses, and renewal cap. The migration ran. The total budget was $2.1M under the original Salesforce SI quote due to the buyer-side disciplines on both sides of the trade. See the Global Pharma restructure case for a related CRM displacement engagement.
The point of the model: The Salesforce migration only makes sense when the capability gap is real. The buyer-side framework forces the honesty. When the gap is not real, the renegotiated Siebel support contract is the cheaper outcome.
When the Oracle Siebel to Salesforce migration plan is on the renewal table, Oracle's deal desk authorises clauses the local account team does not have authority to discuss. The list below covers what we have signed in the last three years on Siebel displacement programmes where the Salesforce threat package was credible.
The redlines protect the customer regardless of migration outcome. They reduce the Siebel cost during dual-run if the migration runs, and they cap the Siebel cost for the next five years if the migration is deferred. The Oracle CX Cloud to Salesforce comparison covers the parallel framework for the cloud-CRM displacement decision the same customer often faces alongside the Siebel exit.
Facing a Siebel renewal alongside a Salesforce decision? Independent, buyer-side migration plan + redline package + audit-defence reserve in ten business days.
Siebel is most commonly licensed under the Concurrent User metric, with separate counts for Power User, Mobile User, Self-Service User, and Application Read Only. The Concurrent User metric is measured by simultaneous active sessions, not by named users, which is why the legacy entitlement counts are often a fraction of the named user counts seen in any modern CRM. When Salesforce replaces Siebel, every named user has to be reconciled to a Salesforce edition (Sales Cloud, Service Cloud, Industries Cloud, etc.) at a list rate substantially higher than the Siebel Concurrent User cost per user.
On a fully amortised Siebel estate where the perpetual licences were bought 10 to 20 years ago, the only ongoing Oracle cost is annual support — typically 22 percent of original net licence. Salesforce charges 100 percent of subscription value every year. The per-user steady-state cost on Salesforce often runs 4 to 8 times the per-user Siebel support cost. The Siebel-to-Salesforce business case stands up only when the user-experience uplift, mobile-first capability, and ecosystem integration deliver business value the legacy Siebel estate cannot.
For a mid-market estate with Sales, Service, and Marketing modules running on a 15-year-old Siebel implementation with heavy customisation, the migration runs 18 to 30 months from board approval to final cutover. Data migration is the longest critical path: 6 to 12 months of cleansing and lineage work before Salesforce can be loaded reliably. Telecom and financial services estates with regulatory data retention requirements run longer. The buyer-side Oracle Siebel to Salesforce migration model has to assume the longer of the two estimates.
Data migration and history retention is the biggest hidden cost. Siebel estates accumulate 10 to 25 years of customer interaction history in tables with schemas the original integrator no longer remembers. Lineage mapping, deduplication, data quality remediation, and archive-versus-migrate decisions consume 22 to 35 percent of the total migration budget. The Salesforce SI's data migration line will quote half this figure. Reserve the full amount in the buyer-side model.
Yes, frequently. The audit risk on Siebel is concentrated on the Concurrent User count — Oracle LMS will check whether the customer has been operating above the licensed concurrent threshold during peak periods. We have defended Siebel audits where the published LMS claim opened at $2.4M and closed at $360K after the forensic concurrent-user reconciliation. The audit reserve in the Oracle Siebel to Salesforce migration model has to assume a $300K to $1.6M back-licence claim on mid-market estates.
Twice a month. Oracle pricing moves, audit-defence tactics, migration economics, ULA exit playbooks. Written by former Oracle insiders, never marketing.
No spam. Unsubscribe any time. Independent — not affiliated with Oracle Corporation.