As I recall it, it was somewhere around November of 1994 when I began my journey in the SAP Basis arena, sitting in front of a newly deployed R/3 system running version 2.1E. I was there because of my experience supporting the Enterprise Finance and Treasury department within the organization where I worked, and also because I “knew Oracle”. After a couple weeks of fruitless searching for database diagrams and the SQL> prompt, I buckled down, started learning, adapted, and evolved.

As it turned out, my timing was good. Opportunities to learn and grow were plentiful, I met many astoundingly gifted people, and bore witness to the evolution of what I continue to believe is an extraordinary triumph of precision engineering: SAP Enterprise Resource Planning Software.

Sitting here in 2021 as Chief Delivery Officer at apiphani, I see the wheels of change are turning once again. SAP clients worldwide, along with the whole of the SAP partner ecosystem, are considering what it means to RISE with SAP.

Billed as “an offering that brings together everything you need to transform your business in the way that works best for you” (SAP SE, 2021), it encompasses business transformation, delivered on the Cloud in a SaaS model. This move on SAP’s part to “to take direct responsibility for customer success and offer a streamlined contracting process” (Greenbaum, 2021) is laudable in many ways.

There has been commentary in the press that this offering sounds a death knell for traditional managed basis services.  No one who knows me will be surprised to learn that I disagree.  We founded apiphani in 2018 to take a new approach to mission critical, and this approach is uniquely positioned to add value across the range of SAP offerings, from traditional legacy to hybrid cloud to public cloud to Rise with SAP.  Once again, it’s time to adapt, and evolve.

Focus on outcomes

Human beings naturally respond to complexity by breaking problems down into manageable parts a la Henry Ford and the assembly line, and there is nothing wrong with that.  However, you can miss the forest for the trees if you get lost parceling out tasks at the level of the lowest common denominator.  By focusing on the business outcome desired by the client, you are more inclined to consider interrelationships and teamwork.  In a technically complex environment, the actions of one party ripple and impact the actions of another, and these currents impact the outcome.

Own the Stack

For this reason, it’s necessary to own the stack. Does your client need to run a resource intensive forecasting operation multiple times during a closing cycle? First of all, don’t make the argument that they really don’t need to do that! Secondly, consider each of the factors at the infrastructure, operating system, database, and basis levels that contribute to the ability of your client to achieve that outcome, because you are ultimately responsible for engineering all of these factors into a successful solution. And if problems do arise, we stay engaged with our clients until the issue is resolved as a matter of course at apiphani, we don’t argue about functional vs technical, or network vs server. Because we own the stack.

Don’t Silo by Technology

You will never own the stack if you silo by technology.  Bouncing tickets back and forth between, for example, platform teams and system administration teams is the surest way to a Severity 1 outage. Every exchange is another 10 minutes closer to a file system filling up and hanging the application.  These are unforced errors that can and must be avoided, which is why at apiphani we silo by account not by technology.  This means team members need to have a certain degree of fluency across domains, but the results are well worth it, and if you have the right technology fronting that team, the effort is greatly reduced. It also means each engineer is familiar with, and responsible to, the client.

Cultivate and Expand Domain Expertise

Invest in training and certification, both at the organization and individual level.  There is no substitute for domain expertise, nor is there a substitute for good judgement in high-risk situations.  Human error accounts for at least 70% of unplanned outages, according to the Uptime Institute (Heslin, 2019).  Moving applications to the cloud, or even adopting an automation strategy, will not alleviate the impact of service disruptions caused by configuration errors or insufficient process discipline. Apiphani has invested in the development and maintenance of ITIL v4 processes and controls along with its Deep Automation and incident avoidance technologies precisely so that we can accomplish more with fewer, highly experienced engineers. These professionals are then free to engage our clients in higher value work, leaving the low complexity, high risk tasks to algorithms and automation.

Focus on Consistency

As the SAP partner ecosystem evolved through the early 2000s, many larger providers began to adopt a labor arbitrage model to keep pricing competitive.  Large teams with a high percentage of level 1 technicians became the norm.  Repetitive tasks were “shifted left” to these less experienced and less involved resources.  In this environment, churn and inexperience fought against consistency.  Inconsistency caused unforced errors, and inexperience greatly increased mean time to resolution (MTTR) across the industry.  In the past several years, we’ve seen automation and predictive technologies really come into their own, giving providers a way to better manage outcomes in a consistent way. Unfortunately, we have seen all too often that these promising technologies are poorly implemented, or simply placed on top of dated processes that were never meant to support these innovative solutions. The outcome of this approach is as predictable as it is disappointing.

Automate Everything

When we started apiphani, there were several challenges we were looking to address. One of these was an over representation of human error in the management of the technology stack. Another was high employee churn. As it turns out, at least in part, these are related problems. High quality application engineers possess a great amount of ownership and take the health of their client’s environment very seriously. When those individuals are not enabled with the right processes and tools, they become firefighters instead of engineers. They spend a large amount of their time chasing errors and trying to make sense of alert storms emanating from a poorly configured monitoring product, all in an attempt to keep ahead of the next outage. The stress can be overwhelming and, eventually, they simply have no choice but to head for the exit.

Apiphani uses our proprietary Deep Automation™ technology to greatly reduce human error, but also to free our engineers to focus on more meaningful work. No longer firefighters, they are able to leverage their extensive knowledge and grow professionally in a supportive environment. This in turn provides additional value to our clients by increasing the consultative hours spent developing solutions for their business. Solutions which would normally be overlooked in a typical managed services engagement.

Nothing is sacrificed by adopting this approach. Our automations interact with our ITSM systems to provide all of the governance and auditability of a more traditional model while handling such tasks as full stack patching, storage management, failed backup reprocessing, system restarts, autoscaling, process management and many other client specific self-healing functions.

Correlate and Predict

Monitoring and alerting used to mean installing agents on servers, and then setting dozens to hundreds of threshold-based alerts per server that would alarm if they were breached. These alarms were sent to a Network Operations Center (NOC) for triage, and from there to an on-call group of engineers for action.  System “noise” often covered up real and/or developing issues in these cases.

In our experience, making the investment in a product that first establishes a baseline for what is normal, and then correlates and informs an engineering team of departures from baseline, is game changing in terms of consistency.  These products are integrated with our self-healing automations at apiphani. Our workflows take it from there, making sure the right individuals are notified, tickets are opened, updated, and closed as needed, and that the proper change control process is followed.

There is simply no such thing as a good incident.  Avoidance is key. This is why we have developed incident avoidance models that ingest large amounts of data from our monitoring tools, configuration management database, and system/application logs, in order to predict problems and prevent incidents before they happen.

Deal with Murphy

Muphy’s law tells us that “Anything that can go wrong will go wrong”.

During a recent maintenance cycle for a client, an operating system support pack application failed, and the error message indicated corruption that would require rolling back the patch and restoring the operating system.  Separately, a HANA database redirected restore failed and the error message indicated corruption with the system database, which would have required a full restore and recovery.  Some maintenance windows just go that way. In both cases however, the error was remediated without data loss and without blowing the approved window.

In other circumstances and with other tools, either of these serious errors would have initiated a long and drawn-out incident management process, with escalations to management at both the client and the provider.  The remediation effort would easily have required a team of four to six engineers.  Using apiphani’s model, each issue was resolved by a single technician within the prescribed window.  The technicians had good data to rely on, and good judgement borne of experience.  They could then, after a short interaction with the vendor, diagnose the root cause of the error and remediate it without restoring an OS or recovering a database.  The symptoms, causes, and solutions for each case were tracked within the ITSM system and the solutions added to the knowledgebase for future reference.

Move Forward at Scale

In a recent article on RISE with SAP, one of the partners was quoted as below:

 “A discrete role has been carved out for partners to help enable the solution configuration and implementation, while at the same time SAP is taking full control of the system maintenance — traditionally the infrastructure and Basis support — that some partners have made a living on,” he said. “The partners who’ve built up a business driven primarily on managed Basis support will have some attrition from this, though many of them are no doubt adaptable” (O’Donnell, 2021).

I believe this statement is both accurate and incomplete.  Certainly, at apiphani we feel ourselves to be adaptable.  Managed basis support is evolving into something more encompassing and climbs further up the stack than has previously been the case.  However, I think it’s misguided to dismiss “infrastructure and basis support” as a commodity that no longer requires attention.  It’s not merely patching and informing clients of issues that occur.  You can’t “throw things over the wall” and expect a good result.  Despite its impressive evolution, SAP is not a serverless application. Traditional basis elements continue to impact the experience of the business users of the system and must be managed in this context. The good news here is that with the right support model enabled by the right technology and the appropriate level of expertise, it is possible to achieve a finely tuned and exceptionally resilient environment at scale and at a competitive price point.

Conclusion

At the end of the day, business applications with any amount of custom configuration or third party product integration will require human oversight to ensure that they run optimally, at least for the foreseeable future. Where these workloads are located makes little difference. What has always mattered is how the application is managed. With the right combination of talent and technology, the sky’s the limit, and we hope that this will be a hallmark feature of RISE with SAP. Take this critical aspect of application support for granted however, and it may well turn out to be an Icarian journey.

References

Greenbaum, J. (2021, February 22). SAP RISE: The Good, the Missing, and the GSIs. Retrieved from eaconsult.com

O’Donnell, J. (2021, March 8). SAP partners sound off on Rise with SAP program. Retrieved from techtarget.com

Heslin, K. (2019, September 23). How to avoid outages: Try harder! Retrieved from uptimeinstitute.com

SAP SE. (2021). RISE with SAP. Retrieved from sap.com

Since its implementation on a massive scale starting in the 1990’s, SAP’s ERP Central Component has certainly come of age.  It’s been effective at giving businesses a centralized view of their critical functions, and while it’s never been an easy task to manage all of that complexity, few would argue against the claim that the application suite continues to represent the top tier in mission critical ERP.

S/4 HANA, the latest iteration in the evolution of the core product, is a completely new code line, marketed as a way to “run simple”. As advertised by SAP, “This is a move that can bring real competitive advantages to your business. With its simplified architecture, real-time analysis, and performance improvements, SAP S/4HANA will enable you to achieve more – from time efficiency to faster ROI.”(Ezra, 2019) The main area of improvement is in financials. According to Christopher Carter, CEO of Approyo, “The revenue recognition alone is a game changer in financials, and the hyperability for analytics is fantastic. ” (Parizio, 2019)

To time box the move to S/4, SAP has issued an end of support date of 2025 for the ECC 6.0 version of the core ERP module, while also defining similarly near-term support terminations for running SAP on the Microsoft Windows operating system or any non-HANA database (SAP, 2019). To clients with 10-15 years of history with the legacy ECC 6.0 product, the prospect of performing what is essentially a re-implementation, without new breakthrough functionality, can be off-putting in the extreme. We have heard that very sentiment first hand and this reluctance is further supported in a recent (April 2019) ASUG study:

Enterprises don’t seem as ready to move to SAP S/4HANA as SAP expects, despite the SAP ECC sunset date of 2025 and the continuous announcement of new features. Recently available numbers from SAP indicate that, in Q4 2018, 10,500 customers purchased S/4HANA licenses. Yet compared to SAP’s approximately 425,000 customers, that doesn’t seem like a lot. And that number doesn’t account for customers who may have purchased licenses but are still grappling with implementation questions.

According to ASUG’s 2019 State of the Community Study, more than half of businesses plan to adopt SAP S/4HANA. However, the same study found that only 16% of customers are live. One of the top reasons why respondents are waiting on S/4HANA migration is that they are waiting for the product to mature so that it can fulfill the same needs that their existing systems already do. (Parizio, 2019)

Whether or not the stated deadline is as firm as SAP would suggest, we nonetheless believe that this reluctance to adopt will be slowly overcome. Expect to see this trend accelerate in the coming two to three years as ever increasing feature sets become available within S/4 and the looming SAP support cliffs mentioned above draw near.

Regardless of one’s perspective on the currently available product suites, our intention here is to provide a review of the various paths an organization may take when evaluating the move to S/4 and highlight some of the benefits and risks associated with each. As a company with a new approach to mission critical, our recommendations are tailored to allow our clients to make the required jump without sacrificing the scale, resilience, and efficiencies inherent within apiphani’s managed services offering: SAP domain experts, completely managed public/private/hybrid cloud platforming options, and proprietary Deep Automation and machine learning powered incident avoidance technologies.

Evolving to S/4 HANA

There are three primary options which may be considered when moving to S/4 HANA: A new implementation, a landscape transformation, and a system conversion. The choice depends upon the state of the organization’s existing ERP solution, the complexity of the business, budgetary constraints, and – most critically – the business requirements which have mandated the migration project.

New Implementation

It is of course possible to execute a new “greenfield” implementation of S/4. Although far less attractive to clients with a medium to long term history on ECC 6.0, it may be the right answer for both new implementations and older systems with outdated configuration that no longer models the current state of the business organization or its processes. Sometimes a fresh start allows for a better future, and as we discuss below, this is not so drastically set apart from other options as one would assume.

Landscape Transformation

Another option is to perform a Landscape Transformation (LT). Sometimes referred to as a Consolidation or Selective Data Transition, this approach is meant to support “Customers who want to consolidate their landscape or carve out selected entities or processes into an existing SAP S/4HANA system or Customer-specific migration project re-using standard migration content…” (Chauhan, 2017) Here we are performing a table by table migration where the focus is not on transitioning an entire system, but rather on selecting which entities we wish to extract and move to the SAP S/4HANA platform. This option will be attractive to larger enterprises that have grown through acquisition and have disparate SAP landscapes on various versions and OS/DB combinations that they wish to combine.

Conversion

A system conversion, also referred to as a “Brownfield” implementation, is the approach that is most often recommended for existing ECC 6.0 implementations. This process is well documented within the S/4 HANA conversion guide, and involves moving the back-end SAP application release to Netweaver 7.5, installing and populating the HANA database, implementing the Fiori UX, and finally migrating the data. The transition is fully supported by the SUM tool, a mature utility that has been used to perform SAP upgrades for many years. There are several conversion paths available.

Conversion Paths

• An ECC 6.0 system running on any supported database (ex: Oracle, MSSQL, DB2) can be converted to SAP S/4 HANA directly. This presupposes the system is already on Unicode and is deployed on the AS ABAP stack. Dual stacks are no longer supported on S/4.
• The database on an ECC 6.0 system can be migrated from any supported legacy database, e.g. Oracle, MSSQL, DB2, etc. to HANA. This configuration is often referred to as “Suite on HANA” or simply SoH. In addition to the performance gains associated with running on an in-memory database, adopters of this approach will be able to leverage the new functionality of S/4 HANA Finance (formerly Simple Finance) which can be configured as an add-on. Excluding Finance, this path essentially allows the business to make a more incremental move to S/4 HANA by splitting the database and application migrations into separate initiatives. This option makes sense if you are not yet ready to adopt to the new S/4HANA code-line and new S/4HANA data model, but you are facing a near term contract renewal date, support is coming to an end for a legacy database vendor within your SAP landscape, or you have  legacy hardware support contracts you would like to dispense with in the short term (Meleegy, 2018). In these situations, moving the database first might well be the most economically viable next step. A note of caution: SoH is not the same animal as S/4HANA. As you are technically running “ECC powered by HANA” in this scenario, you will ostensibly be subject to the 2025 End of Support deadline along with any other ECC implementation running on top of a legacy database (See SAP Note 1648480 – “Maintenance for SAP Business Suite 7 Software” for more details). The key take away here is that SoH is a step on the path to S/4, not a destination in and of itself.

apiphani would support either of these options, with stability throughout the process being of paramount importance.

Simplifying the Way Forward

There are already stories in the press about failed S/4 HANA transformations. In his presentation “5 Steps to Upgrade from Legacy SAP to S/4 HANA” Third Stage Consulting CEO Eric Kimberling underscores the importance of considering questions of business culture and process before embarking on this journey, that is:

1. Understand what went well with your company’s original ERP implementation. Ensure these factors are mapped into the S/4 solution.
2. Understand that S/4 HANA is a complete re-write of the software and so it does not yet have the maturity of the legacy product suite
3. When deciding between the On-premise and Cloud deployment options, understand your needs around flexibility. The Cloud version is less flexible than the on-premise version.
4. Understand how big of a change are you willing to make – S/4 does have breakthrough functions around Machine Learning and Artificial Intelligence. Is your organization ready to grow into these?
5. Understand the impact on people – S/4 is a bigger leap than many people recognize (Kimberling, 2019)

Simply put, look before you leap. Think about organizational readiness, think about quality assurance and testing.

There are some tactical steps that can smooth the transition as well. Business disruption can be minimized if, before embarking on the journey, the business performs (1) a clean-up/archival of any unneeded historical data, and (2) an evaluation and winnowing out of any deprecated custom code (“Z” programs or transactions). The latter will make the final step of adopting custom code to SAP HANA much simpler (see below). There are many products available that assist in the management of this aspect of the project. The evaluation of these is beyond the scope of this document, but apiphani does partner with providers who offer these services.

Figure 01: Custom Code Activities: SAP ERP vs. SAP S/4 HANA (Hamm, 2016)

apiphani will support both of the above efforts from a technical perspective and also provides architectural guidance, including design for performance and design for resilience and stability, as part of its base offering. The SAP Regional Implementation Group (RIG) also provides architectural guidance services, and lastly, there is a readiness check available via the SAP S/4 HANA value assurance packages.

Cloud Hosted vs S/4 HANA Cloud

In concert with the move to S/4, it makes sense to evaluate the end state, or “day 2”, support model.   Due to the technical effort required and the physical relocation of data, on premise clients that are internally supported may wish to consider this an opportunity to migrate to the cloud, either independently or with the support of a partner such as apiphani. S/4 HANA can be consumed in one of two flavors; the S/4 HANA Cloud or what SAP broadly refers to as “On-Premise”. Note that even though many SAP hosting partners use the public cloud as a platform, they will make use of the on-premise SAP licenses procured by our clients. The table below summarizes the differences.

Figure 02: Main differences between on-premise and cloud editions (SAP S/4HANA: On-premise vs. Managed Cloud. Which is right for your Enterprise?, 2018)

S/4 HANA Cloud

SAP offers its own SaaS offering for S/4 HANA called the S/4 HANA cloud. This flavor of deployment involves SAP taking over complete control of the infrastructure.  It offers a subset of ECC 6.0 functionality, although this subset does appear to be growing over time. Back-end integrations to Ariba and SAP Concur are also provided. With a controlled subset of functionality available and minimal customizing allowed, SAP can be much more “agile” with this approach and offer additional functionality and an ease of deployment that is not possible with a traditional model. As part of this solution, SAP will upgrade the application four times per year and they will set the schedule. Although the MTE solution provides some automated testing tools, adopters should plan on streamlining their regression testing models accordingly.

The appeal of SaaS model is undeniable for both SAP and a certain subset of their clients. We see this being particularly attractive to smaller and mid-sized companies who would like to avoid the complexities and overhead that come with more a traditional architecture. Certainly, if you are planning a greenfield implementation of S/4 this would catch your attention. However; organizations considering this path will need to weigh the benefits against their long-term strategy and ensure that SAP’s functionality roadmap matches their own as again, customization of the core is not allowed in this model.

SAP offers two approaches to adopt their SaaS model; an “all-in” approach that brings the client into the multitenant cloud (MTE), and a single tenant option (STE) that is meant as a way to ramp clients into their cloud offering by first adopting many of the benefits of that model, and it’s inherent limitations, before fully embracing the multitenant SaaS architecture. This allows companies with functionality not yet available on the S/4 HANA Cloud to effectively migrate to a platform tailored for future migration. The upgrade schedule is far less rigorous and some custom configuration is allowed in this model, as long as the core is kept clean. For example, it is not allowed to extend an SAP core table, but it is possible to create separate tables of your own within the customer namespace. Any changes made to the core would not be portable. The STE solution is not a viable option for those organizations unable to strictly enforce process discipline. Where upgrade cadence and configuration changes are not possible in the MTE solution, much of the responsibility for keeping the application “clean” and properly patched is left largely to the client with STE.

Partner Hosted Cloud

We believe that the S/4 HANA cloud is a solid solution for many entities and expect SAP to continue to grow the functionality on offer. That said it is not, and may never be, for everyone. The S/4 HANA Cloud option is certainly less attractive if you have an industry solution that hasn’t been incorporated as yet, e.g. Oil and Gas, utilize complex multi-ledger functionality, and/or if you have customization that you wish to retain.  By staying with on-premise licensing, but working with the right provider to leverage the benefits of the public cloud platform, clients can retain a measure of control over their environments while still seeing many of the benefits typically associated with a SaaS offering.

A Partner Hosted Cloud solution is preferred if

• Full Spectrum ECC 6.0 functionality is required
• Uptime requirements for the application are above 99.9% (or about 40 minutes of unplanned downtime per month)
• Specific Security/Compliance requirements
• Compliance with an as yet unavailable industry specific business processes, i.e., an unsupported industry solution is deployed
• The company has well established business processes integrated into ECC 6.0 that they do not want to change

It should be noted that this model also gives clients “one throat to choke”. Providers front the infrastructure, maintain partnership agreements with the appropriate operating system and monitoring tool vendors, and coordinate with SAP on all functional and technical issues. What has been lacking in this model over the course of the past decade or so has been consistent delivery and the ability to scale operations as business and client demands increase.

Conclusion – Current Trending and apiphani’s Position

Net-net, the decision to move to S/4 must be justified at the business level, and it is clear that SAP has some way to go in order to convince its clients that the value is there, deadline or no. The technical decision as to which path to take should be clear by reviewing the business requirements as described previously. The question of cloud adoption as part of this effort will depend on the degree of customization required to support the business, what level of integration with other systems in the ecosystem is needed, and if the business and IT organizations can stand the pace of 4x upgrades per year. The security posture and downtime tolerance of the organization will also have a place in the conversation.

apiphani has always seen value in the close technical management of an SAP system, from the infrastructure up through the operating system, and finally at the database and SAP basis layers. We feel this is the best way to engineer a stable experience for the business users of an SAP system at the application layer, which is really the only place where it matters. This is the guiding principle behind the design of our tools, our use of machine learning and Deep Automation, our platforming choices, and our hiring decisions.  It is therefore perhaps not surprising that, for most cases, we believe outcomes can be better managed by adopting the on-premise licensing model. We are not alone in this, however.

Per the Parizio article, “Most customers, particularly those in complex manufacturing and oil and gas, would avoid the cloud version of S/4HANA because the ability to customize the software is limited, according to Nguyen. While SAP offers the option to build extensions on the SAP Cloud Platform to address this shortfall, that also means companies will need to hire more developers with cloud skills. On the other hand, to maintain S/4HANA on-premises, they can train existing developers on S/4HANA, he noted. This learning curve appears to be much less steep.”

So, while we have little doubt that SAP will continue to provide a consistent SaaS platform, there is no question that to adopt this approach their clients must, by definition, sacrifice a certain amount of flexibility and control. Nor does this SaaS model address the need for enterprises to manage their ancillary applications. Many AMS providers include the management of these workloads as part of their core offering, keeping a focus on these as an integral component of the landscape.

We believe that through a unique combination of technology and talent we have effectively cracked the “quality at scale” code that has long been the Achilles heel of application managed services. Therefore, we provide a compelling answer for enterprises in search of a solution that retains the benefits of an on-prem model while avoiding the pitfalls so frequently associated with it.

apiphani looks forward to continuing this journey with its clients in the coming years and to keeping this conversation alive. As we embark on what is undoubtedly a significant shift in the way mission critical applications are deployed and managed, we hope to engage with the community to help support enterprises and service providers alike. Our mission is to redefine how tier one applications are supported, to use all of the tools at our disposal in order to ensure that we are providing tangible value to our clients and to the wider SAP ecosystem. We sincerely appreciate the time you have invested in reading this paper and welcome any constructive feedback you may have regarding the contents herein.

References

AG, S. (2019, October 21). 1648480 – Maintenance for SAP Business Suite 7 Software including SAP NetWeaver. Retrieved from SAP Support Launchpad

Chauhan, J. (2017, July 17). Converting to SAP S/4HANA: technical options. Retrieved from SAP Community Blogs

DAELE, R. V. (2017, August 28). Question on Support Lifecycle for Suite on HANA. Retrieved from answers.sap.com

Denecken, S. (2019, October 13). Where to find the latest information on running a successful system conversion to SAP S/4HANA. Retrieved from SAP Community Blogs

Ezra, Z. (2019, June 25). SAP S/4HANA Cloud vs. On-Premise. Retrieved from Panaya Blogs

Gupta, R. P. (2018, November 10). S/4 HANA On-Premise Vs S/4 HANA Cloud. Retrieved from SAP Community Blogs

Hamm, R. (2016, November 2). SAP S/4HANA System Conversion – At a glance. Retrieved from SAP Community Blogs

Kimberling, E. (2019, January 23). 5 Steps to Upgrade from Legacy SAP to S/4 HANA. Retrieved from Third Stage Consulting YouTube Channel

Meleegy, A. E. (2018, November 14). Is There Value in Moving to Suite-on-Hana First Prior to S/4HANA. Retrieved from SAP Community Blogs

Parizio, C. (2019, April 2). SAP S/4HANA Cloud vs. on-premises — benefits, limitations, adoption. Retrieved from Techtarget Search SAP

SAP S/4HANA: On-premise vs. Managed Cloud. Which is right for your Enterprise? (2018, May 28). Retrieved from Savantis

SAP, A. (2019). SAP Release Strategy. NA: SAP AG. Retrieved from SAP Support

Saran, C. (2018, August 21). The risk of upgrading to S/4 Hana. ComputerWeekly.com.

Smith, M. (2018, May 15). Is SAP’s 2025 Deadline Real? . Retrieved from Computer Business Review (CBR)

Snapp, S. (2019, April 5). A Comparison of SAP HEC with Virtustream Versus AWS. Retrieved from Brightwork Research SaaS Economy