Upgrading from Siebel Professional Edition to Enterprise Edition
This article focuses on strategic ways to optimize costs and manage licenses for Oracle Siebel CRM, whether using Siebel Professional Edition (SPE) or Siebel Enterprise Edition (SEE).
We explore tactics such as choosing the most cost-effective licensing metrics (e.g., Named User vs Processor), rightsizing user licenses, controlling module usage to prevent unnecessary spend, negotiating better terms (including support fee reductions and enterprise agreements), and maintaining compliance to avoid costly audits.
The goal is to help organizations minimize their Siebel licensing expenditure while meeting business needs through smart planning and proactive management.
Read Upgrading from Siebel Professional Edition to Enterprise Edition: Licensing Challenges and Best Practices.
Choosing the Right Licensing Model for Cost Efficiency
One of the biggest impacts on cost is the licensing metric you choose. Oracle offers different ways to license Siebel, and the optimal choice can change as your deployment grows:
- Named User (Application User) Licensing: Best when you have a defined, relatively stable user population. This is typically how SPE is licensed and is suitable for small to mid-sized deployments. You pay for each user. To optimize costs here, regularly review your user list – ensure you’re not licensing users who don’t use the system. For example, if you bought 100 user licenses but only 80 active employees use Siebel now, try to reallocate or drop support on the 20 unused licenses at renewal. Also, avoid license “creep” – don’t assign Siebel access to someone who doesn’t truly need it.
- Processor Licensing: This model can be cost-effective in high-volume scenarios (common in large SEE deployments). If you have thousands of users or an external-facing Siebel module (like a customer portal where user counts are virtually unlimited), licensing by processor (CPU cores) can save money. However, ensure your usage justifies it – processor licenses are expensive and usually only pay off when user counts per server exceed a certain threshold. Optimization tip: Calculate the breakeven point, e.g., if a processor license costs as much as 50 user licenses, and your server supports 200 users, processor licensing is worth it. If it supports only 10 users, stick with user licensing. You can mix metrics for different parts of Siebel (e.g., user licenses for internal users, processors for a public-facing component), but manage them carefully (and document them in contracts).
- Custom/Application Suite Licensing: Oracle sometimes offers a bundled licensing model (CAS – Custom Application Suite) where multiple Siebel modules are bundled under one license per user. This can be a good deal if users need many modules. To optimize, compare the suite price vs licensing modules à la carte. If your users use 3+ modules each, a suite license might be cheaper than three separate module licenses. Conversely, if many users only use 1 module, don’t buy the whole suite for everyone. Negotiate with Oracle – they might allow mixing (some users on suite, others on individual module licenses) to tailor costs.
- Enterprise License Agreements: An Unlimited License Agreement (ULA) or enterprise subscription might be offered for very large enterprises. This is where you pay a flat fee for unlimited use of Siebel for a period (typically 3 years). Optimizing a ULA means ensuring you need that freedom – it’s cost-effective if you expect usage to grow significantly and unpredictably. If you go this route, maximize the value: deploy as much as possible during the term so that your established usage (which you get to keep) is high at the end of the ULA. If you end up with less usage than anticipated, you may overpay. ULAs can eliminate incremental licensing costs for growth (great for budgeting), but they require careful entry and exit planning.
License Usage Auditing and Cleanup
Cost optimization isn’t just about how you buy licenses, but also how you manage them day-to-day. Two major areas are user account management and module usage control:
- Regular User Reconciliation: Perform a quarterly or bi-annual audit of Siebel user accounts. Remove or reassign licenses from users who have left the company or no longer need access. Many organizations lose track of this and keep renewing support on licenses tied to inactive accounts. For instance, if 50 users left over the last year, that’s potentially tens of thousands of dollars in licenses and support fees that could be saved if you re-harvest those licenses. Create a process with HR: flag their license for removal whenever an employee in a Siebel-using role leaves. This ensures you only pay for what’s used.
- Monitor Last Login or Activity: Siebel administrators can often pull user activity reports. Identify users who haven’t logged in for, say, 90 days. Determine if they still need access. If not, consider reassigning or removing their license. Shelfware (unused licenses) is a sunk cost—reducing that footprint will lower future support costs (since support is tied to license count).
- Enforce “Least License” Access: Configure Siebel roles so that users only get access to modules for which they are licensed. For example, if only your marketing team is licensed for the Marketing module, ensure that the module (or its views) is not visible to sales or service users. This prevents accidental usage of unlicensed functionality, which has two benefits: avoiding compliance issues (which could lead to back licensing costs) and ensuring you don’t inadvertently have to true-up licenses for something only a few people tinkered with. Essentially, don’t tempt users with modules they shouldn’t use.
- Internal Compliance Audits: Treat Oracle’s likely audit approach as a guide. At least once a year, have your ITAM (IT Asset Management) team run a simulated audit: use Oracle’s scripts if available or your queries to list all Siebel users, their last login, modules accessed, etc. Reconcile this with your entitlements. If you find 10% more usage than licenses, address it immediately – either by purchasing the needed licenses proactively (preferably negotiated rather than audit list price) or by reducing usage. This proactive stance can save huge costs versus waiting for Oracle to find it and charge penalties.
Negotiating Support and Renewal Terms
Annual support fees (22% of the purchase) accumulate over time. While Oracle doesn’t easily reduce that percentage, there are ways to optimize support costs:
- Remove Unused Licenses from Support: You can terminate support for licenses you no longer need at your support renewal. For instance, you bought 200 licenses, but you only use 150 after the cleanup. You can drop support on the 50 unused licenses. You won’t get a refund on the license, but at least you’ll stop paying 22% yearly on those 50. Be cautious: those licenses become “unsupported” if you ever want to use them again or get support on them, Oracle might charge for back support. Use this for licenses you are confident are truly shelfware going forward.
- Negotiate Caps on Support Increases: Oracle support tends to rise with list price increases (if Oracle raises list prices, your 22% might be on a higher base if not contractually fixed). Try to negotiate a cap that your support fees will not increase by more than a certain percentage year-over-year, or that they remain pegged to your discounted purchase price, not list price. Support is often calculated based on the net price you paid (which is good), but make sure that’s explicitly included in your order document. If you get a heavy discount on licenses, ensure Oracle isn’t quietly calculating support for a higher “matrix price” – it should be based on what you paid.
- Co-term and Consolidate: If you have multiple Siebel license purchases with different support renewal dates, negotiate to co-term them to a single date. Oracle will prorate fees to align contracts. This gives you a single negotiation point each year and more leverage because the support renewal will be a big lump sum. At renewal time, you can sometimes negotiate a bit – either by threatening to drop certain licenses from support or by bundling in a new purchase. Oracle sales reps often get involved at support renewal time if the dollar value is large, and that’s an opportunity to ask for concessions (maybe a small discount on that year’s support or some free training, etc., as an added value).
- Third-Party Support Consideration: For organizations looking to cut costs drastically, third-party support firms (like Rimini Street, Spinnaker, etc.) offer support for Oracle Siebel at perhaps 50% of Oracle’s fee. The catch: you won’t get software updates or new versions from Oracle while on third-party support. This strategy might make sense if you’re running a stable Siebel version and don’t plan to upgrade, or if Oracle’s support value is low for you. Some companies use it as a temporary cost-reduction strategy. Remember, switching to third-party support typically means you have a perpetual license but “de-support” from Oracle. If you later choose to return to Oracle support, Oracle will charge all back support fees, which can nullify savings. So, it’s a semi-permanent move unless planned carefully. As a cost optimization, it’s an option, but only for those willing to forgo Oracle’s direct help and updates.
Effective Contract Negotiation Tactics
When it comes time to sign new deals or renewals with Oracle, employing certain tactics can optimize your licensing costs:
- Bundle and Leverage Spend: Oracle licenses across their product stack can be negotiated together. If you also use Oracle Database or other Oracle software, consider negotiating Siebel licenses as part of a bigger deal to leverage more spend for a better discount. Oracle might give a greater discount if you’re committing budget to multiple products (or a bigger number for Siebel itself).
- End-of-Quarter/Year Deals: Oracle sales are famously driven by quarterly and annual targets. If you have flexibility, time your purchase or renewal discussions near Oracle’s end of quarter (especially Q4). They may be more inclined to offer discounts or favorable terms to close the deal before their deadline. Based on timing, this could mean tens of thousands in savings.
- Price Holds and Volume Discounts: Try to get Oracle to agree on price holds for future purchases – e.g., “We anticipate needing 50 more users next year, can we lock in today’s discounted price for those?” Also, ask if there’s a volume tier discount – “If we buy an additional 100 licenses, can we get a higher discount?” Knowing your growth plan, you might intentionally slightly over-buy now to get into a better discount band rather than buying small increments later at higher prices.
- Audit Clause and License Certainty: While Oracle usually won’t remove audit rights, you can optimize risk (which equals potential cost) by clarifying how audits will be conducted. Also, ensure your contract’s language on licensing is clear – any ambiguity could cost you if Oracle interprets it in their favor. For example, make sure the definitions of “user” are clear (avoid Oracle later saying you needed licenses for certain read-only accounts you thought were excluded). A well-defined contract prevents unexpected costs.
- Shelfware Exchange: If you have licenses you bought but never used (shelfware), Oracle sometimes allows a one-time exchange for other licenses of equal value. For example, you bought 100 Siebel Call Center licenses but ended up not deploying that module; Oracle might let you swap them for 100 licenses of Siebel Marketing instead, if that’s what you need, as part of a new deal. Always inventory what you have versus need; during negotiations is the time to clean that up.
Maintaining Compliance to Avoid Cost Surprises
Cost optimization isn’t only about paying less upfront – it’s also about avoiding unplanned costs like audit penalties or rushed purchases to cure compliance issues (which often come at list price with no discount).
- Compliance = Cost Control: Running afoul of licensing terms can be extremely expensive. Oracle audits can impose back-dated support and license fees at full price (sometimes a 1.5x penalty on top). A single compliance gap can wipe out years of savings. So, incorporate compliance checks into your cost management. It’s cheaper to buy the licenses you need proactively (with negotiation) than to be forced to buy them in an audit (with no negotiation and possibly penalties).
- Document License Allocations: Keep clear internal documentation of which licenses (by module and metric) are allocated to which part of the business. For instance, you might note that “Sales Dept – 100 users licensed for Sales module, Service module; Marketing Dept – 50 users licensed for Marketing module”, etc. This way, if a manager requests access for someone to a module they’re not licensed for, IT can flag it. This documentation also helps if staff turnover happens in your licensing or IT asset management team – the next person can pick up and know the limits.
- Training and Awareness: Often overlooked, but train your business users and IT about licensing basics. If a departmental IT person is tinkering and decides to enable a new Siebel feature, they should know to check licensing first. A culture of license awareness prevents expensive accidents. Many compliance issues come from someone innocently using a feature or creating extra user accounts, not realizing the cost impact.
- Optimize Test/Dev Licensing: Oracle usually requires non-production environments to be licensed (unless your contract says otherwise). A cost-saving measure is to use your existing licenses for dev/test under a policy called “non-production use” – Oracle often allows the same licenses to cover non-prod instances as long as it’s for the same users and you’re not exceeding usage. Check your contract; if it’s not explicit, ask Oracle to include a clause that non-production environments (QA, dev) can be used without additional license fees, as long as they support the production use. This can save you from buying licenses just for test servers. If Oracle doesn’t agree, ensure you only deploy modules in test that you have licensed in prod, and keep user counts minimal to stay within compliance (or use generic test licenses, but they are counted).
- Retire Unused Modules: If you enabled some Siebel modules and later phased them out, don’t leave them active “just in case.” Remove them from your configuration, and at the next renewal, consider dropping those licenses from support or even canceling them if you have no intent to use them (to cancel outright might mean giving up the license—do this only if you are sure). Streamlining to only the needed modules reduces complexity and cost.
Example: Cost Optimization in Action
Example: GlobalTech uses Siebel Enterprise Edition for 800 users across Sales, Service, and Marketing modules.
They were paying high support and wanted to reduce costs.
- First, GlobalTech conducted an internal audit. They found that 100 users had left the company or moved to roles where they no longer needed Siebel. They also discovered that 50 of the Marketing module licenses were assigned to users who never used the Marketing functionality. They reduced their active named users to 700 and reallocated Marketing licenses only to marketing team members (dropping 50 unnecessary assignments).
- At support renewal, they removed 100 licenses (the ones not in use) from support coverage. This saved them 100 × license_price × 22% in annual fees. For illustration, if each license (base+modules) was valued at $4k, that’s $4k × 100 = $400k license not supported, saving $88k/year.
- They also switched their Siebel Analytics component from Named User licensing (800 users, many of whom seldom ran reports) to 4 Processor licenses on the analytics server. This move, done at a contract renewal, saved money because 800 Named User licenses would have cost more in support and license than four processors. They negotiated a conversion where Oracle took back those 800 analytics user licenses and gave four processor licenses, charging a small net fee for the uplift.
- GlobalTech’s negotiation happened in Q4. They secured a 20% extra discount on a small expansion of 50 users (for a new branch) and got Oracle to include a clause that any additional users added in the next 12 months would be at the same per-user price.
- By cleaning up usage and shrewd negotiation, GlobalTech reduced its annual Siebel spend by 15% while still accommodating growth. They also set a quarterly internal audit schedule to catch any future inefficiencies.
This example combines several strategies: user cleanup, metrics change, and negotiation timing to achieve a significant cost optimization.
Recommendations
- Perform Regular License Audits: Make license audits a routine. For both SPE and SEE, verify that your user counts and module usage match your purchase. Doing this internally (e.g., every 6 months) will let you fix issues before Oracle audits you.
- Reclaim and Reuse Licenses: Have a process to reclaim Siebel licenses when someone leaves or a project ends. Reassign those to new users instead of buying more. Only purchase new licenses when you truly have no spares internally.
- Consider Metric Trade-offs: Don’t assume the licensing model you started with is always best. Reevaluate periodically—if your user count grows, revisit processor licensing; if your user count shrinks or shifts, maybe move back to named users. With negotiation, Oracle allows metric changes at renewals or new purchases, especially in SEE.
- Optimize Module Licensing: License modules only for the users who need them. If only 10% of your users use a certain Siebel module, see if you can license just those users for that module. Oracle’s contract should allow that as long as you have controls to restrict access. This targeted licensing avoids paying for blanket coverage that isn’t used.
- Keep Support Contracts Lean: Review your support renewal yearly and cut out any dead weight. If you have unused licenses, terminate support or try to get Oracle to credit them toward something useful. Don’t blindly renew everything without questioning it.
- Leverage Third-Party Support Wisely: If you are in a cost-saving mode and running stable operations, evaluate third-party support. It can drastically cut annual fees. But weigh the risk of not getting updates – perhaps use it as a short-term strategy to save costs for a few years if you don’t need new Siebel features, with a plan in mind for how you’d handle security patches or eventual upgrades.
- Negotiate Future Needs Upfront: When negotiating with Oracle (either initial purchase or expansion), include projected needs. It is easier to get favorable terms for future growth as part of the initial deal. For example, secure a fixed price for an additional batch of licenses that you can trigger later, so you avoid paying higher prices when the time comes.
- Educate Stakeholders: Ensure your IT admins, procurement team, and business power users understand that Siebel licensing has real costs. Often, cost overruns happen because someone on the business side requests access to a new feature, and IT enables it without understanding the licensing impact. A little awareness training can prevent those mistakes.
- Monitor Oracle Licensing Updates: Oracle occasionally changes licensing policies or offers promotions (like a limited-time ULA or a discount for migrating to the cloud). Stay informed through Oracle’s official channels or licensing advisors. If a new licensing program could reduce your cost, you want to be aware and ready to capitalize on it.
- Use Tools for License Management: Consider using IT asset management software or Oracle’s LMS tools to track usage. These can automate some of the monitoring and ensure you have accurate data on usage vs. entitlements. Good data is key to optimization—you can’t save what you don’t measure.
- Plan for the Long Term: Develop a 3-5 year roadmap for Siebel usage. If you anticipate changes (like moving some users off Siebel, major growth, or migrating to another CRM), factor that into your licensing decisions. For instance, don’t overbuy a 5-year license if you think in 2 years you might switch to a different system—maybe negotiate a shorter term or a flexible contract. Align your licensing strategy with your business strategy to avoid waste.
FAQ
Q1: How can I determine if processor licensing would be cheaper for my Siebel deployment?
A: Calculate how many users you license on a given server or module. Then, find out how many processor licenses would be needed for that same server (count the cores and apply Oracle’s core factor if applicable, usually 1 for most modern Intel CPUs). Compare cost: if one processor license = the cost of, say, 50 users, and your server has four processors (so four processor licenses cover unlimited users), that equals 200 users’ worth of cost. Processor licensing is likely cheaper if you have over 200 users on that server. It’s a bit of math and depends on Oracle’s price list for that module. Your Oracle rep can provide the processor license price; you then compare it to the equivalent number of user licenses cost. Processor licensing shines when user counts are very high or unpredictable.
Q2: We have a lot of occasional users. Can we share licenses among them to save money?
A: Oracle’s user licenses are typically named user, which means each user who uses the software needs their license – you can’t legally have two people “time-share” one license. However, if you have truly infrequent users, one strategy (not officially endorsed by Oracle but commonly done) is to create some “concurrent user” pools by scripting account management – e.g., have 50 accounts for 100 occasional users and only activate accounts as needed. This is risky and can breach terms if Oracle discovers it, since it violates the named user definition. A safer approach is to see if Oracle offers a concurrent user metric for Siebel (historically, Siebel had concurrent user licenses, but Oracle moved towards named). Without that, you might consider licensing just the power users and giving others read-only reports or exports (which might not require a license if they never log into Siebel – e.g., providing data through a data warehouse). Always double-check the contract: some Oracle agreements allow a limited use for certain users (like read-only use for free); if not, assume each person needs a license. So, direct sharing of licenses is not compliant – better to reduce the number of occasional users with alternative methods than to try to share one login among many (which is auditable and against the rules).
Q3: Does Oracle offer discounts for not using certain features or smaller deployments?
A: Oracle’s pricing is generally standardized regardless of usage within the product – you pay for the modules and users you license, no matter if you use 10% of the features or 100%. They don’t usually give discounts for “partial use.” However, for smaller deployments (like an SMB using SPE), Oracle’s approach was to have SPE as the discounted package compared to the full enterprise pricing. So in a way, SPE is the “small deployment discount.” Beyond that, any further discount would be the normal negotiation process (volume or strategic customer discounts). Once you’re in SEE, Oracle expects you to pay for the enterprise capabilities even if you don’t use all of them. The best you can do is only license what you need (don’t buy modules you won’t use). In negotiation, you can certainly argue, “We won’t be using X and Y advanced features, can you cut us a break?” However, Oracle typically prices by product/module rather than feature toggles.
Q4: How do I handle licensing for non-production environments to save cost?
A: This is a common area to optimize. Officially, Oracle requires licenses for installed software instances, including development, test, QA, DR, etc., unless they grant an exemption. Many Oracle contracts allow using your licensed users or processors for a separate environment as long as it’s solely for non-production and the users don’t exceed the licensed count. Check your license agreement; some have a clause like “You may use the programs in non-production environments in support of your authorized use, up to the number of licenses acquired.” If you have that, you can clone your production environment for testing using the same licenses (just don’t double-count users). If no such clause exists, you should talk to Oracle. Often, they will permit a reasonable number of non-production instances without extra charge if it’s clearly for testing and not live work. In the worst case, you might deliberately under-license a test system and hope for lenience (Oracle typically focuses audits on production use). However, explicitly negotiating the rights for non-production use is a safer path. It usually doesn’t cost extra if you bring it up – Oracle understands customers need dev/test systems and often includes that usage right if asked.
Q5: Will reducing the number of licenses under support upset Oracle or trigger an audit?
A: Not inherently. It’s within your right to renew support on fewer licenses if you don’t need them. Companies do it all the time as they adjust usage. Oracle’s account team might inquire why, and it could draw some attention if the drop is large (they might wonder if you switched to a competitor or something). Still, it’s not a violation or red flag for an audit. If you’re otherwise compliant and optimizing costs, you can defensibly say “we are rightsizing to actual usage.” Just be sure you are not using those licenses you dropped from support, because if you drop support and keep using them, that is a compliance issue. Oracle could audit and find those licenses that are in use without support, which is a problem. So use this strategy only when you have genuinely reduced usage.
Q6: How can I get insight into our Siebel usage without waiting for an audit?
A: Work with your Siebel system administrators – Siebel has administrative screens and logs that can provide usage data. For example, you can query how many user accounts exist, the last login date for each, and what responsibilities (which tie to modules) each user has. If you have Oracle’s LMS (License Management Services) scripts, you can run those (Oracle sometimes provides script templates as part of an engagement, or you might find community versions). There are also third-party tools specifically for monitoring Oracle application usage. In a pinch, even analyzing Siebel’s database tables (user table, responsibilities table) can give you a picture of usage. Make usage tracking a part of your system management. Some companies even implement an approval workflow such that any new Siebel user or module enablement has to go through a license check by the IT asset manager.
Q7: Can a lower support percentage (like less than 22%) be negotiated?
A: It’s very rare. Oracle’s 22% support is an industry standard, and they fiercely protect it. What you can sometimes do is negotiate the support base. For instance, negotiate a bigger discount on the license, indirectly lowering support since 22% of a smaller number is less. Or negotiate something like “we pay 22% but capped at a certain dollar amount” if you’re doing a large enterprise deal (this is uncommon, but some very large customers have gotten creative terms). Oracle typically doesn’t reduce the 22% itself for standard customers. They might for governments or very strategic accounts do 19% or 20%, but it’s an uphill battle. A more feasible approach is multi-year support prepayment for a small discount – e.g., Oracle sometimes gives 0-5% off if you pay 3 years of support upfront. But consider the time value of money; that might not be worth it unless you have a leftover budget.
Q8: What should I do with old Siebel licenses if we partially migrate off Siebel?
A: If your company, for example, moves a division off Siebel to another CRM, you might have excess Siebel licenses.
You have a few options:
- Keep them (and keep paying support) in case you need them later – not cost optimal.
- Drop support on them to save yearly fees (you still own the licenses if you ever needed to use them in the future, but they’d be unsupported).
- Try negotiating with Oracle to swap them for other licenses your company can use. Oracle has shown flexibility in some cases: maybe you can trade 100 Siebel licenses for some Oracle Cloud credits or licenses of a different Oracle product you need. This is very case-by-case and usually requires buying something new (Oracle will do it to facilitate a new sale).
- Sell them to a third party? Oracle licenses are technically non-transferable without Oracle’s approval, so a secondary market sale is generally not allowed.
In summary, the practical path is usually to trim support and shelve it or find a way to use it in another capacity (like non-production or for a smaller business unit).
Q9: How can I ensure I stay compliant without overspending on licenses?
A: It’s a balance. The key is visibility – know what you have and what you use. If you maintain that through the practices we discussed (regular audits, user monitoring, etc.), you can catch when usage is approaching your license limits. At that point, you have a choice: rein in the usage (maybe cut off a feature for some users) or acquire additional licenses. The optimal cost-wise approach is not buying licenses until you need them, but not exceeding usage. So timing is everything – forecast when you’ll need more and start negotiating before you exceed. It’s like capacity planning. Also, leverage any flexible options: for instance, if you have occasional needs above your licenses (like a short-term project with extra users), talk to Oracle – sometimes they can provide a temporary license or a short-term license to cover a spike, which might cost less than full perpetual licenses. It’s about communication and planning. Avoid panic buys (when an audit hits or a manager yells that 10 new people need access tomorrow). If you plan ahead, you can negotiate and budget for expansions in a controlled way.
Q10: Are there tools or services that can help manage Oracle licensing?
A: Yes, several. On the software side, IT asset management (ITAM) tools like Flexera, Snow License Manager, or ServiceNow SAM include Oracle license management features. They may require some configuration for Siebel specifically, but they can track entitlements and sometimes interface with usage data. Oracle also offers a service called Oracle LMS (License Management Services) – they won’t manage your licenses for you daily. Still, they can do a health check (somewhat like a soft audit, but you control it) to identify gaps. Also, many consulting firms specialize in Oracle license management – they can provide one-time assessments or ongoing managed services to keep you compliant and optimized. A large enterprise might be worth the investment because Oracle licensing is complex. These experts often have scripts and inside knowledge to parse your Siebel system and give optimization recommendations. Just ensure any third-party advice is independent (not trying to sell you more Oracle products, obviously).
Read more about our Oracle License Management Service.
Do you want to know more about our Oracle License Management Services?
.
