In infrastructure upgrades, the goals often shape the process. For example, if you’re repainting a building and your goal is to get it done as quickly as possible within budget, the process reflects that. You don’t spend a lot of time comparison shopping, or investigating different types of paint — you find a painting crew that can deliver a quick completion within budget, move or cover everything and get out of the way for a few days ASAP.
As the goal becomes more complicated, so does the process. If your goal is to paint the building without disrupting normal operations, you’ll need to do some tricky scheduling to avoid disrupting work hours, or else create a plan to move people to another location, which will require more complex planning. Bring in more tactical considerations — minimizing long-term costs of repainting, choosing colors that positively influence morale — and it becomes more complicated still.
One of the challenges of planning a HANA migration is that the goal is always complex, multifaceted, and often hard to define. Is your goal to get on HANA itself, or to prepare for a future S/4HANA migration?
Do you want to transition as-is to save time and money on the first step of your journey, or tune up your system to save money on hosting and simplify future upgrades? Is the goal to get your development environment on HANA to limit perceived risks and short-term disruption, or get everything migrated to maximize performance benefits? Moreover, is there a compelling case to stop at HANA at all, or would you be better off transitioning straight to SAP S/4HANA?
These aren’t just strategic questions — they affect the process, benefits, and results of your SAP HANA migration. Here are some of the steps you’ll need to take and how to make the right choices to ensure a successful transition.
Before you even start your SAP HANA migration, it’s a good idea to map out your broader technological strategy, and the role your HANA migration plays in it. If you’re stopping at HANA, why? Are you doing it as a way to test the waters and prepare your organization for bigger changes down the line? Maximizing the benefits of cloud migration? Delaying your S/4HANA migration, pending a significant upcoming change in your organization?
Even if you’re planning a straightforward migration to HANA, it’s a good idea to price out your entire transformation to S/4HANA, both as a separate project performed at a later date and as a transformation directly to S/4HANA. Not only will doing this enable you to consider all your options, but it will also help you better set and meet goals for the project.
For example, if your primary SAP HANA migration goals are to improve performance and save money as quickly as possible, you might be tempted to migrate your whole system as is. After all, less work transforming your landscape means a quicker, less costly migration, right?
Not quite.
In reality, any cost benefits of this minimal approach will be more than offset by additional costs. Without streamlining your system, you’ll need more compute for the same level of performance, which means higher spend on hosting. Additionally, you may be putting a band-aid fix over performance, stability, and other problems with your landscape, which you’ll need to fix in the future.
When you consider steady-state operations AND future transformation along with the immediate cost of HANA migration, it’s easier to see the benefits of applying changes such as sanitizing your data and eliminating custom code before your migration goes live.
Protera’s free Migration Assessment Report makes it easier to plan your project around the goals that are most important to your company. This self-service report audits your system and provides a customized migration plan, so you’ll know what it takes to get your company on HANA or S/4HANA. Whether you end up working with us or handling your migration internally, you’ll benefit tremendously from starting the process with a full blueprint.
At present, SAP HANA has support for only two operating systems: SUSE Linux Enterprise Server (SLES) and Red Hat Enterprise Linux (RHEL). If you’re not running either of these systems, you’ll need to choose an OS to run HANA.
While you can make a successful SAP HANA migration with either option, there are significant differences that can affect migration speed, scalability, cost, and future upgrade scheduling. A few factors to consider are:
Licensing: SLES and RHEL have different licensing models. SLES licenses a single package, with everything you need to support your SAP apps. RHEL has a more complicated model — the OS is licensed separately from other components you’ll need, such as networking, high-availability, and storage.
Internal competencies and preferences: If you’re currently using SLES or RHEL, you’ll need to weigh any potential benefits of switching against the convenience and cost benefits of staying with a trusted system.
Features: SLES has several essential differentiators. As Protera founder and board member Patrick Osterhaus points out in our LB Foster Case Study, SLES is tightly integrated with SAP, and backed by a tight relationship between the two companies, making it the preferred platform for SAP HANA and S/4HANA.
Additionally, “the SUSE Linux Enterprise Live Patching capability is a clear differentiator,” said Osterhaus. While other OS’s typically require downtime to apply a patch or upgrade to the kernel, SLES Live Patching lets users patch their Linux kernel while the system is running.
Even a short downtime is costly since it requires your business to come to a standstill during the process. That means the benefits of Live Patching will last beyond your SAP HANA and subsequent S/4HANA upgrade, reducing the cost and disruptions every time you update your kernel through the life of your landscape.
One aspect of SAP HANA migration that’s often overlooked is licensing. Your company will need to appropriately size your landscape and obtain a license from SAP, at minimum. You may also be negotiating licenses with third-party software vendors, cloud vendors, managed services partners, hardware providers, and other vendors.
Additionally, you may be constrained by current licenses and investments, potentially delaying your migration or affecting your strategy. For example, if you’ve leased servers and contracted with service providers to maintain an on-premise landscape, you may have to weigh the cost of delaying SAP HANA migration against the cost of wasting your investment.
To make the right licensing decisions in your SAP HANA migration, it helps to take a medium to long-term look at your migration to HANA. While there may be short-term benefits to putting off your SAP HANA migration, there can be significant costs such as slower tech adoption, higher hosting costs from staying on-premise, and delayed modernization of your IT management approach. In most cases, the benefits of migration will far outweigh the costs over the next 3-5 years.
We love SAP HANA, but it’s just one step on your journey to SAP S/4HANA. Whether you’re planning a cautious, incremental trip into HANA, or an aggressive transformation to S/4HANA, we can help you plan and execute the best possible journey for your company.
Contact us today to ensure success on HANA and beyond.