Upgrading to HANA from Other Databases
Many SAP customers have historically run their applications on third-party databases such as Oracle, IBM DB2, or Microsoft SQL Server. With SAP’s push toward HANA (especially since SAP S/4HANA requires HANA), organizations migrating from these legacy databases to SAP HANA must consider the licensing transition.
This involves understanding how current database licenses (often a significant cost) will change after moving to HANA. There may be opportunities to eliminate old license costs, but new investments are also needed for HANA licenses.
This section discusses what to expect when upgrading your SAP system’s database to HANA from another DB, including conversion programs, cost impacts, and handling of legacy licenses.
License Conversion Programs
SAP has established conversion policies to help existing customers transition to HANA without paying for everything twice.
If you are migrating an SAP ERP system from Oracle to HANA as part of a move to S/4HANA, you will typically engage in a contract conversion. Under SAP’s conversion program, you can trade in your old SAP licenses (including any database runtime licenses for Oracle/DB2) for credit toward the new S/4HANA licenses that include HANA.
For example, SAP might credit a significant portion of your existing SAP license value toward the S/4HANA license so that you don’t pay twice for the same functionality. The exact credit depends on your situation, but SAP’s goal is to ensure customers aren’t double-paying when transitioning to HANA-based solutions.
Even outside of a full S/4HANA move, SAP has sometimes offered incentives like discounted HANA runtime fees or promotional pricing to encourage migrations of SAP Business Suite from Oracle/DB2 to HANA. Always check with SAP for current offers – they may be willing to reduce costs or provide credits to get you onto HANA sooner.
Read Licensing HANA for Non-SAP Applications.
Cost Impact: From Third-Party DB to HANA
Moving to SAP HANA can significantly change your cost structure. With third-party databases, you likely pay an annual support fee to that database vendor (Oracle, IBM, etc.), often ~20-22% of each year’s database license price. If you licensed the database through SAP (as a runtime license for SAP applications), you were paying SAP an uplift (a percentage of your SAP software value) for database use.
After migrating to HANA, those payments will be replaced by SAP HANA license and support costs. Because the base license cost for HANA is generally higher, even 15% support on that larger base can exceed what you paid Oracle annually. In one analysis, Oracle’s support was 22% on a lower license cost, whereas HANA’s support is 15% on a higher license cost, resulting in a net increase.
Conversely, moving to HANA can sometimes reduce costs. For example, SAP historically charged a 25% fee on SAP software to use Oracle, versus 15% for HANA – so switching to HANA would cut that particular surcharge. Also, retiring your old database means you stop paying that vendor altogether, which can offset the HANA expense.
Each situation is unique – it’s crucial to model your before-and-after costs. Be sure to include new HANA license fees and support, savings from ending payments to the old database vendor, and any conversion credits from SAP.
Read Managing HANA License Costs.
Handling Legacy Database Licenses
Handling Legacy Database Licenses: Once you switch to HANA, you can terminate the licenses for your old database. If the database was licensed through SAP (as a runtime license), it will be removed from your SAP contract, ending that cost.
If you owned the database license directly from the vendor, you should cancel its maintenance to stop ongoing fees (unless you plan to use that license elsewhere in your organization).
Recommendations
- Analyze Total Cost of Ownership: Before committing to the migration, compare your current database costs against projected HANA costs. Include license fees, annual maintenance, hardware or cloud infrastructure costs, etc. Ensure the business case justifies any added cost or identifies long-term savings (e.g., eliminating Oracle fees or avoiding a hardware refresh).
- Negotiate with SAP: Leverage SAP’s motivation to move you to HANA. Ask about conversion credits, discounts, or bundling HANA as part of a bigger deal. If you’re also moving to S/4HANA, negotiate it as a package (application + HANA) for the best terms. Get clarity (in writing) on how your existing licenses are valued in the conversion.
- Time the Switch Carefully: Plan the project timeline to avoid paying double database support for a long time. Try to align the migration with the renewal cycle of your Oracle/DB2 contract so you can cancel it right after going live on HANA. If that’s impossible, see if your DB vendor offers monthly support extensions. Also, coordinate with SAP so your HANA license starts when you truly need it (avoid paying for HANA while still running on Oracle).
- Retire and Document Old Licenses: Once on HANA, promptly terminate any old database license agreements or remove them from your SAP contracts. Document the termination or conversion to avoid later confusion (or audits) about your rights. The freed-up budget from the end of maintenance can be reallocated to HANA.
