Salesforce vs Oracle Siebel: The Legacy Migration Decision

Why Siebel Still Exists in 2026

Every year for the past fifteen years, industry analysts have predicted the imminent death of Oracle Siebel CRM. Every year, the prediction has been wrong. Siebel is still running mission-critical CRM for some of the largest enterprises in the world — global banks, telecommunications companies, pharmaceutical manufacturers, government agencies. The question worth asking is not "why haven't they migrated yet?" but "what has made migration either impossible or inadvisable for these organisations?"

The answer is not primarily organisational inertia, though inertia is always present. The answer is a combination of genuine technical complexity, real migration cost, and in some cases genuine capability gaps in the replacement platform. Understanding these factors is essential before commissioning a migration business case — because a business case that underestimates migration cost or overestimates the replacement platform's native capability will produce a programme that fails to deliver its promised value.

Siebel was, at its peak in the early 2000s, the most sophisticated enterprise CRM platform in the world. It was designed for the largest and most complex organisations — thousands of users, millions of records, deeply customised business processes encoded in Siebel's scripting and workflow engine. That sophistication came at a price: Siebel implementations became complex, expensive to maintain, and staffed by specialists who understood the platform's idiosyncratic development model. Those specialists are now rare and expensive. But the processes they built, and the data they accumulated, are not easily replaced.

The organisations that remain on Siebel in 2026 can generally be placed in three categories. The first are organisations with heavily customised Siebel implementations that encode complex, proprietary business processes — financial institutions with bespoke wealth management workflows, telecoms with complex order orchestration, manufacturers with custom pricing engines. The migration cost for these organisations is measured in hundreds of millions and the risk is programme failure, not just delivery delay. The second are organisations that have deferred the decision because each budget cycle has produced other priorities, and the Siebel system continues to function adequately. The third — and smallest — are organisations that have genuinely assessed the migration and concluded that Siebel still serves their needs better than the available alternatives for their specific use case.

What Siebel Does That Salesforce Makes Harder

Defenders of a Siebel migration often make the mistake of arguing that Salesforce can replicate everything Siebel does. It can replicate almost everything, but in several areas it makes the equivalent capability harder to build and more expensive to maintain. Understanding these gaps is essential for planning a migration that delivers on its business case.

On-Premise Data Residency and Air-Gapped Deployment

Siebel runs on-premise, which means it can be deployed in fully air-gapped environments — isolated networks with no external connectivity. This is a requirement for defence, intelligence, certain government agencies, and highly regulated financial services in some jurisdictions. Salesforce is a SaaS platform that requires internet connectivity to its cloud infrastructure. Government Cloud, Government Cloud Plus, and Hyperforce with in-country data residency address many data sovereignty requirements, but they do not address true air-gap requirements.

For the organisations that genuinely require air-gapped CRM — and this is a small but real group — Salesforce is not a viable replacement. The correct answer is Siebel (continuing), Microsoft Dynamics 365 on-premise, or a purpose-built solution, not Salesforce.

The Siebel Scripting and Business Component Model

Siebel's development model — Siebel Tools, Business Components, Business Objects, eScript — is deeply proprietary but also deeply powerful. Complex business rules encoded in Siebel eScript or in the Siebel workflow engine can be extraordinarily intricate, and they have often been built by developers who understood Siebel's object model at a very deep level. The functional logic in a mature Siebel implementation is not a feature set — it is a process asset that has been developed and refined over years.

Migrating this logic to Salesforce (Apex, Flow, Lightning components) is not straightforward. The mapping is not one-to-one. Siebel's Business Component model has no direct Salesforce equivalent. Process logic that runs in a few hundred lines of eScript may require multiple Apex classes, flows, and triggers to replicate in Salesforce — and the replication requires business analysis as well as technical translation because the original intent of the logic is often not documented.

Siebel Call Centre and CTI Depth

Siebel's contact centre capabilities — particularly its computer-telephony integration (CTI), screen pop functionality, and multi-channel interaction history — were purpose-built for large contact centre operations and have been refined over two decades. Salesforce Service Cloud's omnichannel capabilities are broadly comparable, but the depth of Siebel's CTI integration with legacy telephony platforms (Avaya, Genesys, Aspect) is often greater — because the integrations were built and maintained for specific enterprise deployments over many years.

For large contact centres with complex routing logic, screen pop configuration, and legacy telephony that is not being replaced alongside the CRM, the Salesforce migration carries significant integration re-work. This cost is routinely underestimated in migration business cases.

The Real Costs of Migration

The most common failure in Siebel to Salesforce migration business cases is cost underestimation. Not because the business case authors are dishonest, but because the full cost of migration is genuinely difficult to see at the business case stage, before the requirements analysis has been done.

The Process Archaeology Cost

Before you can migrate from Siebel to Salesforce, you need to understand what your Siebel implementation does. For a Siebel system that has been in production for 10-15 years, with multiple customisation waves, multiple integration additions, and staff turnover in the Siebel team, the documentation of the current state is often incomplete or inaccurate. Process archaeology — the systematic discovery and documentation of what the system actually does, as opposed to what the documentation says it does — is a material cost item that most business cases do not plan for.

In practice, process archaeology for a large Siebel implementation costs £500,000-£1,500,000 and takes 3-6 months. This is before any Salesforce design or build work begins. It is the most frequently underestimated cost line in a Siebel migration programme.

Data Migration at Scale

Siebel databases are large. A 10-year-old Siebel implementation at a large enterprise may contain 50-200 million account, contact, and interaction records, with complex relationship structures and legacy data quality issues accumulated over the system's lifetime. Migrating this data to Salesforce — transforming it to Salesforce's data model, cleansing it to a standard that Salesforce's field validation will accept, and loading it at the scale required — is a programme within a programme.

The data migration alone for a large Siebel estate typically costs £300,000-£800,000 in tooling, delivery, and testing. It requires multiple dry runs in a Salesforce sandbox before the production cutover. And it has a cutover risk — the window in which both systems need to be stable while data is moved — that requires careful programme management.

The Integration Re-wiring Cost

Siebel systems in large enterprises are typically connected to 15-40 other systems — ERP (Oracle, SAP), billing, order management, contact centre telephony, marketing automation, reporting and analytics. Every one of these integrations must be decommissioned from Siebel and re-built to Salesforce. At an average of £30,000-£80,000 per integration (depending on complexity), and 20 integrations, the integration re-wiring cost alone is £600,000-£1,600,000.

This cost is almost always understated in early business cases because the integration inventory is not fully catalogued at business case stage. The discovery of integrations that were not on the original list is one of the most common sources of programme cost overrun on Siebel migrations.

When Staying on Siebel Is Actually Right

There are specific circumstances where staying on Siebel — at least for the near term — is the correct strategic decision, and treating it as a failure of ambition is a mistake.

When the Migration Cost Exceeds the Value Case

A migration that costs £15 million to deliver, takes 3 years, and delivers £20 million in net present value benefits over 7 years has a thin margin. When you apply realistic cost contingency (40%) and realistic benefit realisation risk (30%), the business case may not hold. For some Siebel organisations, the honest TCO analysis shows that running Siebel under Oracle support until 2030, while investing in adjacent capabilities (analytics, customer-facing digital channels), is a better financial decision than migrating.

This is not a permanent answer. Oracle's support horizon for Siebel will eventually end, and the talent market for Siebel specialists is shrinking every year. But "not now, in three years" is a legitimate strategic decision if the cost analysis supports it and the programme capacity is currently committed to higher-value work.

When the Programme Risk Is Unacceptable

For organisations where the CRM system is genuinely mission-critical — financial institutions where Siebel manages client relationships for private banking or wealth management, insurance companies where Siebel underpins claims and policy servicing — the programme risk of a migration failure is not just IT disruption. It is regulatory, reputational, and commercial. If the risk assessment concludes that the programme failure probability is material and the consequence is unacceptable, deferral is the correct decision.

When the Capability Gap Is Manageable

Not every Siebel user needs a modern CRM platform. For a sales organisation that uses Siebel as a contact management and activity logging system — without complex workflows, without integration to digital channels, without a requirement for mobile access — Siebel continues to function. The capability gap between Siebel and Salesforce matters most for organisations with modern, digitally-led go-to-market models. For organisations with traditional enterprise sales processes that have not materially changed in a decade, the gap is smaller than it appears from the outside.

Planning the Migration When You Must

When the decision is made that migration is necessary — and for most organisations it eventually will be — the planning framework matters as much as the technology choice. Siebel migrations that fail typically do not fail for technical reasons; they fail for programme management, requirements, and change management reasons.

Start with the Process Inventory, Not the Technology

The first workstream on any Siebel to Salesforce migration is process discovery, not Salesforce design. Before any Salesforce architect produces a solution design, the programme needs a complete, verified inventory of what the current Siebel system does — every process, every workflow, every integration, every customisation, and every report that is in active use. This sounds obvious and is routinely skipped or compressed. The consequence is a Salesforce design that is built on an incomplete picture of requirements and requires expensive rework when the undiscovered requirements surface during UAT.

Use a Phased Migration with a Parallel Run

The highest-risk migration pattern for a large Siebel estate is a big-bang cutover — everything off Siebel, everything onto Salesforce, on a single weekend. The lower-risk pattern is a phased migration: migrate a defined subset of users or processes to Salesforce, run both systems in parallel for a period, validate Salesforce outputs against Siebel outputs, and expand the Salesforce footprint incrementally as confidence grows.

Parallel running is expensive — it requires maintaining both systems simultaneously — but it is far less expensive than a failed cutover. For mission-critical CRM systems, the additional cost of parallel running is justified by the risk reduction it provides.

The Change Management Investment You Cannot Skip

Siebel users are, by definition, users who have been working in the same system for years. Many of them are senior commercial professionals whose effectiveness depends on muscle memory built in Siebel. The change management investment for a Siebel to Salesforce migration must be proportionate to the depth of that embedded behaviour. This means not just training courses, but embedded change agents in each business unit, floor-walking support on go-live, a simplified Salesforce configuration that reduces the cognitive load on launch day, and executive sponsorship that signals the importance of adoption.

Change management on a large Siebel migration typically requires 8-12% of the total programme budget. Programmes that budget 3-4% — the more common figure — consistently experience adoption problems that reduce the value realised from the migration investment.