In our previous post, we discussed practical steps to consider when planning a SAP cloud migration project. Now, let’s take a look at cloud deployment options for SAP.
Companies have a tremendous amount of choice as to where to deploy their SAP landscapes, including S/4HANA. Also, SAP landscapes don’t function in isolation anymore. You will almost certainly deploy systems at various places in the cloud. This has the drawback of additional integration and complexity, but the upside is that you can fine-tune and optimize your landscape to meet different business needs.
Customers who primarily deploy on-premise will have at least some parts of the landscape extended into the cloud.
Your three main SAP Cloud Deployment options
SAP customers primarily have three cloud deployment options:
1) The public cloud (the DIY option)
The public cloud is essentially the DIY option for SAP cloud deployment options. It is a good option if you already have an experienced SAP technical team that are responsive and keen to learn new technologies, and you can give them the time needed to become experienced with SAP nuances on public cloud platforms. The public cloud provider supplies the infrastructure you need to deploy on, but it’s up to you to take it from there.
At first glance it might seem like the least expensive option, but remember that infrastructure typically accounts for less than 20% of your total costs. You still have to add the management costs associated with keeping an enterprise application up and running. This is something that specialist managed service providers can typically do more cost effectively, because they operate at scale.
If you select the public cloud as your best option, the first thing you need to think about is a SAP cloud migration plan. We’ve outlined the high-level steps in a previous post. If you combine this cloud transition with an upgrade to S/4HANA, you have to build in enough time to work through the teething problems (and maybe some broken limbs along the way!) of the first conversions. From our experience, there are crucial small steps that can easily be missed if you haven’t done this before. Don’t skip the initial sandbox system migration, as you will learn valuable lessons here that you will need to document and use in the rest of your landscape migration.
When you eventually have the migration process figured out, you have to think about the production management of your landscape. Naturally, you will have to make sure you have a team who can keep everything up and running on an application level, since the public cloud typically only includes SLAs on an infrastructure level. Make sure you plan for back-up and recovery processes, high-availability and disaster recovery. Public cloud providers are not impervious to service outages, and you need to factor this into your processes.
2) SAP-managed: HANA Enterprise Cloud (HEC) (the cookie-cutter option)
HEC is the cookie-cutter option for SAP cloud deployment options. It is a step up in services from the public cloud providers, since HEC includes technical application management services. This is a good option if you have a fairly straightforward landscape, and are currently happy with SAP’s support levels and processes.
I call it cookie-cutter, because you choose to do things the SAP way. SAP publishes a standard services catalog and service level agreement. Be sure that these services and SLAs meet your needs, especially if you plan to reduce or reassign your in-house SAP technical team. Currently, the standard uptime guarantee is 99.5% for production and 95% for non-production systems, but higher levels can be purchased at an additional cost. SAP may also place restrictions on what software may be installed on HEC systems. If you have invested in any add-on software, make sure that SAP will be happy if you continue to use it.
Unlike the other options, HEC is SAP-only. If you have an on-premise third-party system that is tightly integrated with your SAP landscape, you won’t be able to migrate it with the rest of your landscape.
HEC is more expensive than the public cloud options, but this should not necessarily deter you. As mentioned above, economy of scale counts, and HEC might well be less expensive than an apples-to-apples comparison for the same service levels with a DIY solution. The same goes when comparing HEC to the managed private cloud option. When you do a Total Cost of Ownership (TCO) comparison, be sure you do a true like-for-like evaluation, as managed private cloud often includes additional services, not part of the standard HEC services catalog.
While HEC is signed on SAP paper it is also important to understand that HEC is not always deployed by SAP Operations. SAP can choose to outsource it to partners such as IBM, Virtustream, HPE, Dimension Data and others, so while the same contractual SLA might exist, the experience and referenceability of HEC deployments will vary wildly.
We’ve heard various opinions on customer experiences with migrating to HEC. As always, it would be wise to speak to other HEC customers of similar size and complexity to learn from their experiences and to obtain HEC references from happy customers.
3) Managed private cloud (the tailored suit option)
Managed private cloud is the tailored suit option, where you have a personal tailor who takes time to understand what you like and need, and creates something that fits “just right”. This is the best option if you have unique requirements and require a long-term partner that can adapt to you, not the other way around. Companies operating in this space can provide varying options at differing price points. Here at EPI-USE Labs we combine our managed services portfolio with our Unified Platform to provide customers with a tailored managed private cloud.
Our clients typically approach us when there are changes looming on the horizon. They are thinking about an upgrade, a migration to S/4HANA, an acquisition or divestiture, or a corporate strategy directive to move to the cloud. These events usually serve as a logical time to consider moving to the cloud as well. Most companies don’t have internal capacity to deal with both business as usual, and a big change project. Through discovery sessions, we first understand the business objectives for the project and then work on a SAP cloud migration plan accordingly. We usually take responsibility for the migration project. These projects differ depending on scope, but it will be along the lines outlined in our previous post on this topic. While there is always a place for normal homogeneous migrations, most migrations are heterogeneous, since customers want to replatform their architecture and possibly also be selective in what data moves to the cloud. Using our Data Sync Manager product suite, we can usually perform any type of cloud migration more dynamically, with less human intervention and room for error. The migration process can be templated, and the template parameters can be tweaked as many times as required, until you have full confidence that a production cut-over will happen without incident. If you have non-SAP systems that you want to migrate to the cloud at the same time, this can also be accommodated.
As with tailors being discerning of the materials they choose, we too have spent considerable time and effort in choosing the right Data Centers and hardware vendors for our cloud offering. For our data centers we partnered with Equinix, as we found they are the only company that could provide first party data centers across the globe that met our enterprise hosting requirements. On the hardware front, we partner with Fujitsu, who have a long history of designing and manufacturing some of the best hardware for SAP systems. We work closely with Fujitsu to architect, deploy and support hardware that is custom built for performance, and reliability suitable for SAP workloads. It makes a difference.
The service catalog and SLAs are adjusted as required. Our standard offering is used as a baseline and fine-tuned with our customers to specification. This flexibility helps customers fill gaps they might have internally, and meet realities of their business. Typical specifications that can be added are additional security requirements, more regular refreshes of the non-production landscape and additional application management services.
One common requirement from our customers are that they require more flexibility and transparency in running their environments. They don’t want the burden of managing everything themselves, as they would need to do with the public cloud, but they want the freedom to do some things themselves, like creating new sandbox or project-specific systems on demand. To that end, we’ve created the Unified Platform, a SAP-aware management platform that allows clients to perform common tasks through a simple self-service web portal. Customers have full transparency into their landscape and can provision or clone systems, view monitoring and performance data and schedule common tasks. We actively use and develop Unified Platform at EPI-USE Labs, continually improving the software based on customer requirements.
For many customers, a managed private cloud, with all the additional services, could be a better option than a public cloud. Boutique providers, like EPI-USE Labs, can provide a more flexible and customized offering while reducing the number of additional third parties required for the migration off-premise. Specialized managed services layered over a more traditional hosting model, realised as OPEX, could make that journey to the cloud a much smoother experience.
Key differences:
? - this option is sometimes supported
FREE HANA READINESS ASSESSMENT
Leave a Comment: