The road to SAP HANA


This follow-up article by Tony Perez, Cloud Solutions Architect at Skytap, examines two options available to IT teams after moving non-HANA workloads to the cloud; leaving them as-is or modernizing them with cloud-native services to help save their SAP ecosystem now running in the cloud.

Verdant rainforests, sky blue ocean waters, cascading waterfalls, you have arrived at your ultimate destination…

In my last article Navigating the Road to SAP HANA, I explained how an organization’s ultimate journey to SAP HANA could include moving non-HANA SAP components to the cloud using an IaaS to run Power LPARs, as well as traditional (non-Power) x86 workloads in the same environment. One such option is Skytap on Azure, where IBM i (AS/400), AIX, Linux Power-based operating systems, and traditional x86 workloads can all coexist without rewriting, rearchitecting, or re-platforming.

Leveraging the cloud for non-HANA workloads is part of an IT strategy that delivers the following benefits:

  • IBM Power support
  • Regulatory conformity
  • Reduction of on-site infrastructure
  • Business continuity (disaster recovery)

Now let’s say you’ve completed this part of your journey with the aforementioned benefits and now have non-HANA workloads running in the cloud.


You accomplished this feat by doing a traditional “lift-and-shift”. This ensures that the original architecture has not been materially disturbed. The lift-and-shift model has reduced project risk, and you can leverage your historical IT skills cultivated over decades on site.

The fork in the road

Now you have started a new journey. And immediately you come to a fork and are faced with two very different paths:

Turn left at the fork: This path means you leave everything “as is” after the lift-and-shift and maintain it without further modernization. This is the end of the cloud journey for you.

Now you save money because you don’t have to buy your own equipment (which can require significant upfront costs and long-term maintenance expenses). Plus, you get a secure platform managed by a third party, so you don’t have to secure and maintain your own network components.

Your workloads now scale more easily and cost-effectively. Production infrastructure and development environments can be provisioned and ready to use in hours instead of days or weeks if you had to purchase and configure in-house IT infrastructure while operating onsite.

In addition, your infrastructure is now accessible from anywhere, depending on the security you have in place. The recent global pandemic has created a remote workforce that is much more common in IT. Therefore, the flexibility to access and manage your infrastructure, wherever you are, is now more essential than ever.

However, there is no doubt that when you migrated non-HANA workloads to the cloud, you also carried over many “satellite services”. These were not necessarily SAP components, but custom or third-party solutions aimed at making SAP more usable across the enterprise. For instance:

  • Reports
  • Data ingest
  • Data storage
  • Data transformation
  • Data governance
  • machine learning

Turn right at the fork: To address these “satellite services”, let’s examine how Microsoft Azure native cloud services could replace or complement legacy on-premises services over time. This is often called incremental modernization.

Learn more: Cloud-Native Recovery in an Economic Downturn

Benefits of cloud-native services

Once your workloads are migrated to Azure, you can connect them to native cloud services to unlock additional value. For example, Microsoft Azure offers cloud-native services to support things like advanced analytics, data visualization and reporting, as well as artificial intelligence and machine learning so you can take full advantage of leverage the benefits of data modernization for legacy data.

Here are some of these cloud-native services and their benefits:

  • Power BI: Create powerful reports and data visualizations with Microsoft Power BI to better inform business decision making.
  • Azure Synapse: Ingest data from physical and logical files or a DB2 database stored in your IBM i (AS/400) libraries to an Azure data lake using Azure Synapse.
  • Azure Data Factory and Azure Data Lake: Warehouse your data and create transformations without code, as well as merge data from other sources to gain insights.
  • Azure scope: Create a holistic, up-to-date map of your data landscape with automated data discovery and automated classification of sensitive data with this end-to-end data governance platform.

When you move SAP NetWeaver workloads to Skytap on Azure, you enable SAP HANA workloads to interact with other business applications running on Azure. These cloud-native Azure services could replace and simplify the overall architecture. If part of your long-term strategy is to leverage Azure for greenfield applications, this strategy makes sense. Why duplicate services? Your plan should be to consolidate them over time.

Learn along the way

Whichever branch you took, you got a tangible benefit: you gained experience migrating apps to the cloud. If you’ve taken the left fork and plan to leave the application “as is,” this is a solid IT strategy for legacy applications migrating to the cloud. Now you have some good information on the costs of migrating large applications, and you’ve probably also learned how to deal with security and networking issues. So while the app may not have been upgraded, you have upgraded your skills. This is a significant advantage for your IT organization.

If you’re taking the right path and considering replacing or integrating Azure native services into your existing application architecture, you’ve created a repeatable “path to the cloud” not only for this SAP application, but for others. apps. it could follow. The model is based on (1) “raising and moving as is”, (2) stabilizing the application and running it to your existing production standards, and (3) starting to look at how individual Azure services might be used to replace or enhance the carried forward legacy architecture. You have “won” whatever path you have taken.

In summary, once you successfully moved your non-HANA SAP NetWeaver workloads to the cloud, you inevitably acquired a basket of additional IT services and solutions that the on-premises SAP implementation depended on to operate successfully. . So you can turn left at the road fork and leave it running as it is, or you can turn right at the street fork and start researching how to modernize and save your SAP ecosystem now running run on the cloud and enable to ease the transition to SAP HANA in the future.

Where are you in your transition to SAP HANA? Do you turn left or right at the fork in the road? Share with us on Facebook, Twitterand LinkedIn.


Image source: Shutterstock


About Author

Comments are closed.