Skip navigation

This blog was co-written with Melchior du Boullay, General Manager, Americas, at oXya.




Outsourcing SAP 2 - screen shot.jpgOutsourcing SAP 1 - screen shot.jpgToday’s blog is the 3rd in the “Outsourcing SAP” series. In the first blog, Outsourcing SAP: Should We Outsource Our SAP Environment?, we covered various questions and concerns that customers have regarding SAP outsourcing. We discussed security, the responsibility aspect, various types of outsourcing partners, and briefly mentioned two additional considerations – infrastructure and HR/headcount.


In the second blog, “Outsourcing SAP: Choosing a Partner to Manage Our SAP Environment”, we suggested several criteria to help you choose your SAP outsourcing partner. These criteria include SAP-specific SLAs, the reports you’ll get, and the delivery model the partner will provide you. We also suggested tips for negotiating with partners and ensuring you’ll get the service promised, such as a contract that includes fiscal penalties to the partner, should they fail to meet the agreed-upon SLAs.


Today’s blog expands on two considerations that customers usually deal with, when looking to outsource their SAP landscape – infrastructure and HR/headcount.




You’ve decided to outsource your SAP management. Now, you have two alternatives:

  1. Continue to own the infrastructure, host it in-house, and be responsible for it
  2. Have your SAP outsourcing partner also take full control over the infrastructure (purchase a service package that includes both SAP hosting/infrastructure & SAP managed services)


In-house SAP infrastructure


Why do customers choose to keep their infrastructure in-house, rather than outsource it as well? There are several reasons:

  • The customer just recently purchased the SAP hardware, they don’t have anything else to do with it, and they don’t want to lose their CAPEX investment. This is the most common reason.
  • The customer prefers to keep their entire infrastructure in-house, including SAP and non-SAP infrastructure. In that respect, it’s important to note that while oXya is a specialized SAP partner, we have many customers which have chosen to outsource their entire IT infrastructure to us, not only their SAP infrastructure. We welcome that type of business.
  • Related to the previous reason, when the customer has additional non-SAP systems they do not want to outsource; and they have a team of infrastructure and OS admins (but not SAP admins) that handle all of these servers; then removing a significant portion (SAP landscape) of the infrastructure may lead to layoffs which they prefer to avoid.
  • The fourth reason has to do with security/control perception. Some customers feel comfortable outsourcing the managed services side of SAP, but not the infrastructure that comes with it. They have a perceived threat of security, that the more access you give to someone else, the bigger the threat is, hence they prefer to keep the infrastructure in-house, and presumably reduce the risk. This is similar to the discussion we had regarding Security in the first blog of this series; whether that threat is realistic or not is less relevant; the perceived threat has increased for some customers, hence why they would not outsource the management of their infrastructure, only the services side of SAP.


When a customer experiences a perceived threat regarding their infrastructure, what often happens is we begin to provide them with SAP managed services, while they keep their infrastructure in-house. Over time, as they get a great service from oXya and trust us, they will often ask us later to also take full responsibility over their infrastructure—typically at the renewal of our contract. We’ve seen that happen many times before.


When the customer chooses to maintain responsibility for the hardware and for hosting SAP—whether on-premises at the customer, or at a third-party datacenter—we’re OK with it and would take just the managed services business. All we need is a good, reliable connection to the servers, to provide SAP managed services. We’ll just mention, regarding using a third-party datacenter for hosting your SAP infrastructure, what we’ve already discussed on the first blog in this series – the more providers you have for the same system, the less efficient it’s going to be.


Outsourcing the SAP infrastructure


The most important thing to remember regarding outsourcing your infrastructure, and the main reason why customers choose to do so – it enables you to transform your capital expenses (CAPEX) into operational expenses (OPEX).


denver_140821_3258_hi (Custom).jpg

There are two typical scenarios when customers want to outsource their entire SAP landscape, both services and infrastructure:

  • Common scenario: at the end of customer’s infrastructure lifecycle (typically once in every 3-4 years). This is a great timing, as you move your SAP landscape onto the latest, brand new hardware. Many of oXya’s customers are using this method; they get to upgrade their hardware without paying the huge associated CAPEX, and instead pay a monthly OPEX bill for combined managed services and hardware.
  • Far less common scenario: the customer recently bought new hardware, and then decided to outsource their SAP. Obviously, the customer doesn’t want to lose their investment in hardware, so oXya works with them to solve that. Typically, we will transfer the customer’s hardware to one of our datacenters and use it for their SAP landscape, until the next refresh cycle when they will move to new hardware, owned by oXya.


Amongst oXya customers, there’s roughly a 50:50 split between customers for whom oXya also manages the hardware and hosting, and customers who own their hardware and host it somewhere else. When oXya owns the infrastructure, we are responsible for everything – hardware, hosting, and including OS administration, database administration, and SAP administration. When we do not host the hardware, oXya is typically responsible from the OS layer and up (OS, database, and SAP administration).


For some customers we provide Platform-as-a-Service (PaaS) and host their entire IT infrastructure, not just SAP. In such cases we are always responsible for the infrastructure and OS administration, and sometimes also database management for the rest, non-SAP applications (if these applications have databases). The customer is usually responsible for the non-SAP applications themselves.


Disaster Recovery


One of the main infrastructure benefits that customers get from oXya, when we manage their SAP landscape, is a full disaster recovery (DR) solution (see our blog about disaster recovery for SAP).


When you host the SAP infrastructure in-house, it is quite challenging and expensive to have a DR solution: you need another, remote location; another set of servers installed in that location; have fast communications lines between the two sites; and have someone maintain that remote site—all that so the second site would serve as a DR site.


Once you choose an SAP outsourcing partner such as oXya, all of these are given. Any reputable and reliable provider will have a DR sites, and often multiple sites. Hence, the decision to outsource your SAP systems—on the infrastructure side—is not only about replacing the infrastructure, but it is often about the ability of adding onto the infrastructure you currently have, without incurring huge CAPEX costs. Just by moving your infrastructure to an external SAP provider such as oXya, you can make your SAP landscape far more secure and more reliable.


We even have a few SAP managed services customers who choose to keep their infrastructure in-house, but ask oXya to serve as the DR provider for them. In such a case we provide space in one of our datacenters, and can even provide the infrastructure on the DR side. The customer is responsible for the link between their datacenter and ours. Once the link is up, we can configure the system so that our site serves as the DR for their in-house datacenter. It’s not a very common option, but some customers do leverage it.


Who Chooses the Hardware?

denver_140821_3970_hi (Custom).jpg


Sometimes we’re asked whether—when oXya owns and operates the infrastructure—the customer is involved in choosing the infrastructure. Another question we’re often asked is what type of infrastructure we typically use, and what we recommend.


The answer to the first question is “yes”, of course oXya customers are involved in the decision making process about their infrastructure. Since oXya offers a private cloud solution, and the infrastructure will be solely dedicated to the specific customer, they obviously want to know all the details. Furthermore, when a customer has specific preferences or requirements, then we’ll do as they ask.


As for the second question – whenever there’s no specific preference from the customer, we will typically advise and use hardware from Hitachi Data Systems (HDS), which we have been using over the last few years. We have a very good experience with the HDS hardware, as it is extremely redundant and extremely reliable. (Disclaimer: oXya started using HDS equipment back in 2013, about two years before HDS acquired us in February 2015).




HR/Headcount is a very important criteria when companies consider whether to outsource their SAP infrastructure. From an HR/headcount point of view, we see two main challenges companies have when looking to outsource their IT in general, and specifically SAP.


The hiring challenge


Some industries choose to be located in very specific regions of the country, due to tax benefits. These tax breaks are usually given at relatively remote areas, where the specific state would like to create new jobs and attract employers. One industry for which this is typical is the automotive industry, but also for various other industries.


While these tax breaks make a valid reason for a company to relocate to that region, the downside is these areas can be very challenging for recruiting experienced IT personnel in general, and even more so for recruiting SAP experts. Some companies experience major challenges in hiring infrastructure admins, and even more so SAP professionals. Often, these companies will turn to SAP outsourcing, which solves all of their recruitment needs, as they no longer need to hire people to manage infrastructure, SAP, databases, and so on—all these roles are covered by the outsourcing provider.


The Headcount Challenge


From a headcount perspective, some companies are very sensitive to headcount, to the extent that they’re OK with sometimes paying more to external consultants and outsourcers, just to reduce their headcount and avoid hiring people. If that’s a driving factor in your company, then outsourcing is certainly the way to go. You can remove the entire IT team from your headcount, if this is important to you. This is something that we see, and one of the driving factors of companies who choose to outsource their SAP landscape to oXya.


What do you really get when outsourcing SAP?


One of the interesting things to check is what exactly you get when outsourcing SAP. Do you get the exact same thing, only done by an external team? Or is it something different, possibly more?

oXya16 (Custom).jpg


The answer is that when you outsource, and specifically to oXya, you get a lot more for the same amount of money, compared to when you do the same thing in-house. Let’s show that using a few examples:


  • When you host your systems internally, you probably have at least one SAP Basis person (for smaller SAP installs), or a few SAP Basis experts (for medium-size installs). Not only is this small team always overloaded with work; what happens when the one person you have gets sick? When someone takes a vacation? When one of your SAP Basis experts leaves the company? Are you set to manage your SAP with fewer resources?
    • At oXya, you get an entire team of SAP Basis administrators (8-12 people) that is dedicated to managing your account and that of a few additional customers. While this team is not dedicated only to your account, they know your systems inside-out (because they’re directly responsible for your systems), and when someone is sick or on vacation there are always several other team members to answer your calls and handle any issue.


  • When hosting SAP internally, do you get 24x7 monitoring and support? Or is SAP support only provided during regular work hours? After all, to achieve 24x7 support you need to have 2-3 shifts, meaning you’ll need to at least double the number of SAP Basis personnel on your team.
    • At oXya, you get 24x7 monitoring, which includes shifts around the clock. We look after your systems all the time, perform proactive maintenance work, and more.


oXya14 (Custom).jpg

  • When you host SAP internally, how much ongoing training do your people get? Do they have time for special projects, outside of regular maintenance? Customers tell us that their people were often overworked, didn’t have enough time (or any time, quite often) for ongoing training that is critical in SAP. Also, since buried with ongoing support work, these internal teams don’t have time for various projects.
    • At oXya, we have cross training inside each team and between teams. We can also “afford” to send people to external training, since we have enough backups to keep on supporting our customers (if you attended SAP TechEd in Vegas in October 2015, you probably saw lots and lots of green oXya shirts around; these were all our SAP experts, going to many training sessions. Later, they pass the training to their teams).
    • As for project work, this is one place where oXya can help you, even without managing your SAP landscape. On top of our ~260 enterprise customers for which we provide SAP managed services, we have another ~1000 customers who manage SAP themselves, and use our services for various projects, such as installing new products (including HANA and S4/HANA), various upgrades, and more.


And above are just a few examples, there are more. The bottom line is that for a small to medium size SAP install (not that of a Fortune 100 company, but smaller), replicating in-house the kind of support experience and expertise that you get from oXya is extremely expensive. The result: the vast majority of companies have nothing even close to that level of support, or that number of dedicated SAP Basis experts.


Above is one of the main positive aspects of outsourcing, from an HR perspective. oXya already has all HR processes in place to guarantee 24x7 service and replacements when someone is sick, on vacation, or leaves us. That’s an added bonus to our customers.


So how do we do it at oXya? How do we make money? Well, that’s our business model. Since this setup is mutualized—one large team, dedicated to a number of customers—we can spread the costs and still provide it all to our customers, at a much lower rate, compared to the scenario where you do it all in-house. So, there’s a huge advantage, in terms of HR, to outsourcing your mission-critical applications such as SAP; you simply get much more manpower for a similar or smaller cost.


Something about costs


We can’t finish a discussion about HR and headcount considerations, without saying something about costs, can we? So, let’s clearly explain the statement we made in the previous paragraph:

  • oXya’s managed services for SAP will always cost significantly less when the customer wants internal 24x7 support and a rotating SAP Basis team, and compares all these internal expenses to oXya’s price offer.
  • When customers compare their existing headcount cost that does not provide 24x7 support, with the oXya’s price offer that does include 24x7 support, then our cost is very competitive and often lower, compared to cost of the customer’s internal SAP team. This is true even though oXya provides many more services, that the customer’s  internal team doesn’t and cannot provide.



What has your experience been like, regarding the infrastructure and/or headcount considerations?


What is your view on these topics?


How are these dilemmas impacting your business?

Share with us your thoughts and experience below, in the Comments section.





Our next blog in the “Outsourcing SAP” series will describe in detail the process of moving your SAP landscape from your in-house datacenter (or from a different vendor) onto oXya, and the exact steps we take to minimize downtime and risks to your business.


Send us questions about any aspect of “Outsourcing SAP”, and we will answer them in the last blog of this series, in a few weeks. Please post your questions to the Comments below, or send them directly to us, Dominik Herzig <> or Melchior du Boullay <>.




oXya_HDS_logo_300dpi (Custom) (2).png

Dominik Herzig is VP of Delivery for US & Canada at oXya. Dominik has 10 years of SAP experience, starting as a Basis Admin, and then moving to SAP project management and to account management. Dominik was one of the first few people to open oXya’s US offices back in 2007.


Melchior du Boullay is General Manager, Americas at oXya, responsible for all of oXya’s operations across North, Central and South America since 2007, when oXya started operating in the Americas. Melchior has nearly 15 years of experience as an SAP Basis admin and technical consultant, SAP project manager, SAP account management, and business development.


oXya, a Hitachi Data Systems company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs ~600 SAP experts, who service more than 260 enterprise customers with more than 250,000 SAP users around the world.

This blog was co-written with Melchior du Boullay, General Manager, Americas, at oXya.




The decision to outsource your data is not an easy one. It consists of at least two major steps:

  1. The first step is for you to make a decision that you want to outsource your SAP environment; in other words, you decide that you would like to entrust a 3rd party with providing ongoing managed services for all your SAP operations;
  2. Then, once you’ve decided to outsource, the second decision is for you to select an outsourcing partner; be mindful that it is a partner that you are choosing, not a vendor.


Each of the above two steps has various questions and concerns that customers address. Some are questions they must ask themselves, and some are questions for the partners they are interviewing. Then, after you’ve made the decision, comes the actual process of transferring your current SAP systems to the outsourcing partner; or working with that partner from the beginning, to build your new SAP environment.


In a series of blogs we’re starting today, we will address all of the above. We will share with you from the experience of oXya, who has been managing SAP environments for enterprise customers for the past 18 years; these days we are managing SAP environments for more than 260 customers, with supporting over 250,000 users. This is the experience, on which this blog series is based.

oXya1 (Custom).jpg


In today’s blog, “Outsourcing SAP: Should We Outsource Our SAP Environment?”, we address the first decision. We will cover the various questions and concerns that customers ask and examine, when they decide whether to manage their SAP environment in-house, or to use a partner to provide managed services for them.


Next week’s blog, “Outsourcing SAP: Choosing a Partner to Manage Our SAP Environment”, will address the second part of the decision. Next week we’ll discuss how to select an outsourcing partner, and suggest some important criteria regarding what you should look for when interviewing partners and comparing between them, to make sure you select the best partner possible for you, to which you will outsource the management (infrastructure & ongoing management and support) of your SAP environment.


Then, in additional blog posts, we will dedicate a blog to the questions around infrastructure and headcount; we’ll describe how the process of actually transferring your current SAP systems to oXya actually works; and we’ll end up with a blog that answers the questions we’ll get from you, the readers, throughout this series.


We invite you to post your questions below, in the Comments; or feel free to email them directly to us, Dominik Herzig <> or Melchior du Boullay <>.


But before we dive in, let’s first clarify that when we say “Outsourcing SAP”, it doesn’t necessarily mean to outsource your infrastructure. Rather, it can mean that you keep your infrastructure in-house, and only outsource the support services, meaning you get managed services that are based on your own infrastructure. At oXya, we have customers of both “types” – some asked us to handle their entire SAP environment, meaning to run their SAP on our own infrastructure, at oXya’s datacenters around the world; and some customers preferred to keep their own infrastructure, in-house, and have manage their SAP support services.


Should We Outsource?


This question is always an internal one, within the organization; furthermore, it is often a political question, and has nothing to do with technology or any specific partner. There are various reasons why organizations decide to outsource their SAP (or keep it in-house), and these include the service levels provided to the business; infrastructure considerations; headcount; various accounting dilemmas (Capex vs. Opex); and more. Here are some thoughts about a couple of these reasons:


Infrastructure: fact is that most companies do not operate their own datacenter. Owning the datacenter is something that is typically only done by very large enterprises, those with lots of financial means (and even then, not by all large enterprises).


denver_140821_3561_hi (Custom).jpg

When a smaller company owns its datacenter, it will usually need to make some compromises: the datacenter will have small space (closet-type space), with very little redundancy. That is why the outsourcing model has great advantages for most companies. If you go to an outsourcing company and ask them to take care of your systems, such a company would typically have a full datacenter, redundancy in place, possibly a second datacenter for disaster recovery purposes, and more.


These are big advantages to the outsourcing model. All of that infrastructure, that supports your SAP environment, is very costly when you’re trying to do it on your own and maintain everything by yourself. However, it’s quite easy and affordable for the outsourcing provider (which offers the service to many companies), and of course it’s also easy and affordable for the customer, who purchases a service, and not the full infrastructure and everything around it.


Headcount: this is often seen as an advantage for outsourcing. For some companies, headcount is an important metric and managers are often asked to lower their headcount. Once you adopt an outsourcing model, all the technical people who manage your systems and provide you with SAP support are not considered part of your headcount.


When working with oXya, we take care of all the SAP Basis aspect so you don’t need any internal SAP Basis people. You also don’t need any database administrators, because our experts are taking care of that as well.


We will dedicate another blog post (beyond the two mentioned above) to deal with the above subjects questions (infrastructure, headcount) and additional ones regarding outsourcing your SAP environment. In that blog, we will offer ways to look at these dilemmas that will help you get to a decision.


In this blog, however, the starting point is that you’ve already gone through the decision process described above, and decided to seriously examine the option of outsourcing your SAP service. Hence, in the remainder of this blog post, we will cover the various questions and doubts that you now need to deal with.


The Security Concern


The question of security is the first concern that each and every company always has, regarding outsourcing their SAP systems. It is also an important question to address. The bottom line answer? Yes, you can have a very secure internal environment, in-house, if you can afford it. It all depends on your resources. Because security, much like many other things, depends at the end of the day on how much you are willing to invest in your infrastructure, training and procedures, when you’re hosting your IT internally.


The main concern regarding security is a trust issue. Do you trust an external company with handling your most valuable data? Do you trust that they have procedures in place, to restrict access to the systems and data? This is the most common concern when considering (Custom).jpg


Here’s the simple answer to that concern: when you decide to outsource, you obviously need to select a partner that you can trust. Once you found a partner that you can trust, then the risk—from a security standpoint—is not necessarily greater than the risk from your own employees. To explain that, let’s look, at a very high level, at both external attacks and internal ones.


Regarding external attacks, you obviously need to protect yourself from them, and this is what firewalls and IDS/IPS solutions are for. All of these solutions protect your systems from external attacks, and these solutions can be replicated in an outsourced environment. In fact, it’s quite possible that an outsourced environment will have more solutions and more security measures in place, compared to your in-house systems; this is typically very visible when talking about security procedure (what are the processes to prevent attacks; how to react when an attack has been detected) as this is the core of the business of your potential outsourcing partner.


However, the main security threat is always your internal people, meaning some sort of attacks that leverage internal access. When an attacker wants to get access to your data, the main vector of attack will go through your internal people. If someone can get to them, then the attacker will have a pretty easy access to your systems. This is true whether you run your systems in-house with your own employees, or through a managed services partner. In my view, the nature of the security threat doesn’t change much once you move to outsourcing.


Couple of examples to the types of internal security threats that I’m referring to include:

  • Mishandling passwords: someone who has a weak password, or wrote the password on a piece of paper, or someone who gives a password to someone else who should not have it.
  • Disgruntled employee: if someone internal wants to harm you, then obviously it’s easier for them, compared to someone external.


Still, the above threats will be the same, whether your IT is in-house or you manage it through an external managed service partner.


You can and should request your SAP managed services partner to put in place the same type of protections that you have internally. Typically, this means things like background checks on the team that handles your systems (internally or with the external partner; we’ll touch on that in the next blog), and similar preventative measures. The bottom line is that in my view, the security threat is similar whether you have your SAP systems internally or you outsource them. Again, in this case, this is the core of your potential partner’s business, they should have no issues to at least match what you have currently in place, in terms of security procedures.


The Responsibility Consideration


The second major consideration when you want to do outsourcing, and especially SAP outsourcing (which is what we specialize in), is the responsibility consideration. To be clear, outsourcing doesn’t mean that you—the CIO, or the person who leads SAP in the organization—no longer have any responsibility, and that you can give all the responsibility to the managed services partner. Not at all.


One of the most important things that you need to think about when you do outsourcing, and especially when you outsource your SAP, is that you need someone to manage the relationship with your outsourcing partner. In our case, typically we need an IT person that works for the customer, to be the link between the customer’s user community, the customer’s internal IT resources, and us at oXya. This is relevant for any SAP issues, SAP projects, and even the daily management of the systems.

oXya2 (Custom).jpg

An example for the daily cooperation is that we send daily reports, and these reports need to be read by someone. So, you definitely need a resource on your side (the customer) whose job it is to manage that relationship. It’s not necessarily a full time job, but it’s something you should keep in mind when you decide to outsource. Furthermore, having someone specific who manages the relationship is especially true if you have multiple, specialized outsourcing partners. The more outsourcing partners you have, the more work it will be to coordinate between them.


Let me give you a very specific real-life example. We have a customer that decided to outsource their entire SAP infrastructure. They selected one partner just for the datacenter part, a second partner for the SAP managed services part, and a third partner for the SAP functional part. So, they ended up having three different partners for their SAP landscape. That is a lot of partners, around only one system.


What does it mean, in daily life? It means that for every issue, they have to coordinate with these 3 entities; make sure that everyone is aware of everything going on; and that these 3 partners are communicating between themselves and with the customer, in order to resolve that issue. That is a lot of work, and it needs to be taken into consideration when you select your outsourcing partners. If you decide to outsource to multiple different partners—and there are good pros and cons for such a move—then you have to take into account that it will take a lot of time to manage these partners.


How many outsourcing partners?


To continue the on the same subject we started above, there’s another thing you should consider regarding the number of outsourcing partners you select. When you have several outsourcing partners involved, like in the above example, you also need to take into account that all processes will take longer. Meaning, it will take longer to resolve issues, to perform upgrades, and so forth – due to all the coordination work needed between the various partners that support the SAP environment.


Let me give you an example, and I’ll tie it into the oXya model of servicing customers. When we are working with customers, we prefer to take overall responsibility over your SAP environment, including datacenter, infrastructure, SAP Basis services, databases, and more. Another alternative is for the customer to own the hardware, and oXya provides the SAP manages services.


How does it work? Let’s take a case where you own the hardware, and oXya performs the SAP managed services. You give us a call regarding an issue you’re experiencing. You call directly to the team leader—he is an SAP Basis admin as well, with many years of experience; with oXya, you don’t call a call center and wait for someone to get back to you.


Once you convey the issue directly to the team leader, he is able to determine immediately what type of issue it is, and start working on the resolution with the specific oXya team that is assigned to service you (each customer has a specific team assigned to them). The team will identify whether this is an SAP issue, a database issue, an infrastructure issue, and so forth. Then, as soon as the cause has been identified, the oXya team can immediately begin working on the resolution. Even if it is an infrastructure issue, the oXya team can still call to order a replacement part, and take immediate actions by themselves (remember that in this example, the infrastructure is owned by the customer and is under the customer’s responsibility, but oXya would still help resolve the issue. Obviously, things work at least as fast when the infrastructure is owned by oXya and is under our responsibility).


So where do the issues begin, and processes begin to take longer and longer? The additional time comes in when neither oXya nor the customer own the hardware, because the customer selected a different partner for the hardware. This means that we (oXya) have limited access to the hardware and to the operating system. It also means that it’s going to be more difficult to troubleshoot some issues and identify the root cause. And on top of what I already mentioned—when the hardware is not owned by oXya, then we can only give our recommendations and ask to check specific things, but we are not able to perform the operations by ourselves; the actual ordering of the parts and performing the operations will need to be done by the other partner. And all of these things always and definitely add some time to the resolution process.


The rule of thumb, when considering the number of partners you will outsource to, is that the more partners you include in the process, the slower everything will be. The other party needs to be aware of the issue, run tests by themselves, perhaps validate something on their side, and only then order the necessary parts to solve the infrastructure issues.


General outsourcing partner, or an expert one?


In addition to the question regarding the number of outsourcing partners, another question you’ll need to deal with is what type of outsourcing partner you want to choose for your SAP systems. At a high level, there are two options:

  1. Outsource your entire infrastructure and all applications to one “generalist” outsourcing partner
  2. Use specialized outsourcing partners to handle specific applications

oXya14 (Custom).jpg

The two options listed above represent two schools of thought. At oXya, we believe in specialization; we specialize in SAP and related systems (e.g. databases and more) at the highest level, so obviously we have a very firm opinion on which approach is better. We also have many customer success stories that support the specialized outsourcing model. In this model, you entrust a portion of your IT infrastructure and applications to a company that specializes exactly in that area, and have expertise in that area. This company does everything around certain applications, but not necessarily everything related to all your applications and IT operations. In other words, it means you may need several outsourcing partners for different applications. This way you get the best, most specialized service.


Note that the multiple outsourcing partners mentioned in the previous paragraph, a specialized partner for specific applications and everything around them, is very different than the multiple partners we discussed in the previous section. Earlier, we discussed the case of several partners that handle various tasks related to the same application (one partner for SAP services, another partner for infrastructure), so the process ends up slower and tends to be problematic. In this case, we’re talking about a specific, specialized partner for everything related to SAP (or other applications), so the end result is actually better and faster service.


As already mentioned, oXya specializes in SAP Basis, and due to that we are a very good partner for any SAP Basis needs. We can provide managed services on-site, meaning you have your own datacenter, want to keep it because you’re happy with it, and you just want a company to provide the SAP Basis services based on your own infrastructure; or you want to leverage oXya’s datacenters and infrastructure around the world, in which case you can outsource just your SAP systems, and access them via MPLS (for example).


The other option, which we’re not going to expand on, is the one we actually listed first – hire an outsourcing partner that will handle all of your applications, and in some cases all of your IT needs. These types of outsourcing partners are often the biggest, most famous names out there, so it sounds like a “good bet” to entrust your entire IT in their hands. Furthermore, this approach also sound simpler to execute and manage on an ongoing basis, since you have less partners to manage.


However, real life experience shows that such “generalist” outsourcing often comes at the expense of expertise. Also, you would often suffer from slow service, since you don’t know who exactly, from their multiple service centers around the world, will handle your specific, current issue, and how much time it will take. Resulting from that, you’ll encounter support personnel that do not know anything about you and your systems (each issue may be handled by different teams, in different time zones), and more. oXya has many happy customers, that came to us after being burnt with outsourcing partners of the “generalist” type.



oXya_HDS_logo_300dpi (Custom) (2).png

To summarize what we discussed in this blog, remember that:

  • The security threat is not greater when outsourcing your SAP systems, compared to managing everything in-house;
  • Once you’ve decided to outsource your SAP systems, it doesn’t mean that all responsibility has been transferred to the partner(s); you still need someone in-house to manage the relationship;
  • When considering the number of outsourcing partners related to SAP, keep in mind that the more outsourcing partners you have involved with your SAP systems, the more work it will be for the in-house person responsible for the relationship;
  • Keep in mind that the more outsourcing partners you have related to your SAP systems, the longer it will take to resolve each issue, since each issue will bounce between the various outsourcing partners;
  • And last, when choosing between a “generalist” outsourcing partner and one that specializes in SAP (or specializes in other, specific applications), we recommend going with the specialized partner, and giving them the full responsibility over that application and everything related.



Our next blog will discuss the question of how to choose the right partner to manage your SAP systems.


Please post any questions you have about “Outsourcing SAP” to the Comments below, or send them directly to us, Dominik Herzig <> or Melchior du Boullay <>. We will address all of your questions.





Dominik Herzig is VP of Delivery for US & Canada at oXya. Dominik has 10 years of SAP experience, starting as a Basis Admin, and then moving to SAP project management and to account management. Dominik was one of the first few people to open oXya’s US offices back in 2007.


Melchior du Boullay is General Manager, Americas, at oXya, responsible for all of oXya’s operations across North, Central and South America since 2007, when oXya started operating in the Americas. Melchior has nearly 15 years of experience as an SAP Basis admin and technical consultant, SAP project manager, SAP account management, and business development.


oXya, a Hitachi Data Systems company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs ~600 SAP experts, who service more than 260 enterprise customers with more than 250,000 SAP users around the world.

Disaster recovery (DR) for SAP has always been a hot topic, since SAP is one of the most mission-critical environments for any organization. Research company IDC analyzed the cost to the company, should a critical application fail. They calculated that cost—if you’re a Fortune 1000 company—to be between $500,000 to $1 million per hour of downtime. They further calculated unplanned application downtime (all applications) costs a Fortune 1000 company between $1.25 billion to $2.5 billion every year.


I believe that in the case of SAP, the cost of hourly downtime is on the higher side, and can go even higher than $1 million per hour. Failure and downtime to the SAP environment can bring an entire organization, or at least large parts in it, to a halt.


For that reason, significant thought is invested in a DR plan for SAP. If your main site suffers a disaster, such as flooding, fire, major earthquake, and so on—the DR plan should get you up to running your normal operations in as short time as possible and with minimal data loss.


There are several DR optionsfireman-100722_640.jpg in the SAP world. The emergence of cloud technologies have added options that did not exist just a few years ago; there is also more flexibility today, for choosing the DR option that’s right for you. Of course, various options also carry different price tags. At oXya, we’ve been using all of the DR solutions I’ll cover here with our various customers, according to their needs and budget. There is no one single solution that fits everyone. In this blog post, I’ll list the various DR options we’re using with our customers, as well as the pros and cons for each of these options.


But before diving into the various DR options, let’s clarify two things:


1. We focus on the Production landscape. The SAP environment can be huge, with many landscapes and multiple servers. When speaking about DR, we limit the discussion to the Production environment. Due to cost considerations, organizations are usually not thinking about DR solutions for other landscapes.


2. DR in SAP world means copying the database log files. All the information handled by SAP is stored in the database (i.e. Oracle, DB2, MS-SQL). Any changes to the database are represented in the logs. By sending the log files to the remote/DR site, we can recover all the information for SAP to run properly on the DR site.



About Disaster Recovery Technologies: Synchronous and Asynchronous


This post deals with DR options for SAP, so I don’t want to dive too deep into core replication technologies. However, we can’t do with nothing, as these technologies play a critical role later on, especially when dealing with HANA. So, here’s a very short description about the two main replication technologies, also explaining which one we use for DR:


Synchronous: the database at your main site will not commit any database changes, before it received confirmation that this change has also been replicated to and committed at the DR site. This creates, in essence, two identical sites.


Asynchronous: the database at your main site acts normally and commits changes. All the changes are sent to the DR site, but committing (or not) the changes at the DR site does not affect the main site. By definition, there is always a lag between the main site and the DR site—the DR site lags after the main site. The size of lag depends new-orleans-81669_640.jpgon latency, which in its turn depends mostly on the distance between the two sites.


For a more thorough explanation of synchronous versus asynchronous technologies, see this HDS document; page 4 has a great explanation of synchronous versus asynchronous replication, including a nice comparison table.


As already mentioned, the latency between the two sites depends on the distance between them. If the two sites are distant enough, as required for true DR, the latency will be significant. If you try to implement a synchronous replication, this will bring the database performance (on the main site) to a crawl, and make it unusable. The reason is that every time there’s a small change, there will be a major wait until the order is also committed to the remote database, and that will crash the database. For that reason, any typical DR solution for SAP will use an asynchronous solution.


Another thing I’d like to clarify is the difference between a High-Availability solution (also known as Active-Active) and a Disaster Recovery solution (Active-Passive), because I heard in the past people relate to an HA solution as also a DR one, in parallel. A high-availability solution means two servers, usually within the same datacenter or at a very close proximity, that create a cluster and enable you to access and use them both at the same time. A high-availability solution is not a DR solution, or at least it’s a very bad DR solution. Think about some major disasters in the last decade, such as Hurricane Katrina in New Orleans, Hurricane Sandy in New Jersey, and the tsunami in Japan; a high-availability solution would have been totally destroyed in these cases, which brings us back to the point I made above – for a true DR solution, the DR site must be far away, hundreds and even thousands of miles away, in order to avoid the disaster impact. It also means, by definition, that the DR solution must be an asynchronous one.



Traditional Disaster Recovery for SAP


Traditionally, what we had in the SAP world was a main server at our main datacenter. In addition, we had a DR datacenter in which there was another server, usually identical to the server in the main datacenter. The traditional SAP approach to DR was to use “log shipping”. This means you gather the database logs at the main datacenter, and ship (send) them over the network (usually over MPLS) to the DR datacenter.


The traditional approach has been around since the beginning of SAP, and we’ve been using it for many years. It works great, and many customers are still using this method. This approach is very sturdy, works with any type of infrastructure, yet it’s the old fashioned way.


There are at least two drawbacks to the traditional approach: cost, uptime speed, and audits:


1. Cost: using this approach, we need to own both datacenters, and have servers in both of them (or we can lease space in a datacenter for DR purposes, but that’s still a major cost).


2. Uptime speed: newer DR technologies enable us to get the DR site up, running and operational in a shorter amount of time, compared to the traditional approach. I’ll discuss it shortly.


3. Audits: the traditional approach only replicated the database log files. While these are sufficient to get the SAP environment at the DR site up and running, there are additional log files that are created by the SAP system itself, whenever a job is performed, or there’s an error, and so forth. These files are not replicated when using the traditional approach. These SAP logs can be important for audits, for example.


The rise of cloud solutions has given us additional, newer options for DR. I’ll describe them from the cheapest to the most expensive one; all of these solutions have been used by oXya customers.



DR to the Public Cloud


Generally speaking, one of the cheapest solutions for DR would be to use a public cloud service, such as Amazon Web Services (AWS). If your server needs to be backed up, and it doesn’t have frequent changes (i.e. web server, front-end applications, or interface applications), then a public cloud can be an option. You backup to a server on AWS, and have that server “sit” there, turned off, so you don’t pay for that service/server until you bring the server up. You only bring it up when a disaster strikes your main servers, or once in a while for updates.


This is a very cheap option to achieve some type of Disaster Recovery, because you would pay very little so long as your servers are turned off (down).


For SAP however, you’ll need to keep you databases in sync, which means the database server on Amazon must stay online and continuously receive updates.


It’s important to emphasize that this method is NOT recommended for everyone due to security concerns of having your production data on a public cloud. You may also run into some difficulties in setting up all your SAP interfaces for the DR, within a public cloud (Bank interfaces, etc.). Still, this option can become relevant in cases where budgets are very small, and customers can’t afford to invest in one of the other, more expensive DR solutions for SAP. In such a case, some DR is better than none, so this solution can be considered.


How does it work, in practice? The method is quite similar to that of the Traditional DR method. You install all your DR servers on AWS, shut down all the applications servers (to avoid ongoing payment), and only keep the database server live, on a continuous base, to receive ongoing updates of the log files. You will then send the database logs from the main customer site to the DR database server on AWS. Once a disaster occurs you bring the other servers up, and can operate your SAP environment directly from Amazon.


This setup enables budget-strained SAP customers to obtain a fairly cheap SAP disaster recover option. It is a far cheaper option than having a physical server at another datacenter, because you only pay, on an ongoing base, for the uptime of the database server, that is kept in sync with the logs. All the other servers on Amazon are shut down, and cost almost nothing (you would still have to pay for the cost of the storage used by these servers).


This solution can be used with various providers, not necessarily just AWS. oXya, for example, provide this service through its own cloud, and there are additional solutions in the market such as Microsoft Azure. The idea behind all of these is similar – you only pay for servers that are actually being used.



SAP DR using VMware SRM


Another DR option to use with SAP is VMware SRM (Site Recovery Manager). For some of our customers, we implemented and are now using the VMware SRM method, instead of using the Traditional DR method. The difference is that the traditional method uses database-level replication, by sending the database log files. With the VMware SRM method, we perform a full server replication. This means we include all the additional files that are created as part of the SAP operations, such as the SAP logs. All of that additional data can now be replicated directly to the DR site.


With VMware SRM, you have a VMware farm on your primary datacenter. You would also have a VMware farm at the DR site, yet this is probably a smaller farm, to only satisfy the needs of the Production environment. Then, you perform a VMware SRM replication across these two VMware farms (in other words, you duplicate the full VMs, including SAN replication and the VM setups).


VMware SRM can be based either on Storage replication or on the vSphere hypervisor. Without going into the technicalities behind these two options, Storage replication is usually used when a very low Recovery Point Objective (RPO) is required. That option is somewhat less flexible and requires having the same type of high tier storage infrastructure on both sites.


The VMware SRM method allows you to have a full server replication to SAP, whereas before, with the traditional method, you only had database-level replication. In most cases, the database-level replication is enough, but you still have some work to do before you can get the DR system up and to par with the main, original site.


Therefore, a VMware-based replication will allow for a quicker/shorter Recovery Time Objective (RTO), which is the time for a business process (SAP, in our case) to be restored after a disruption. In addition, you keep all the files that are not residing within the database, and which are lost when using the Traditional DR for SAP.



HANA-specific Disaster Recovery


The last type of DR we should discuss is HANA-specific disaster recovery, because this one is a bit different. HANA usually runs on its own application server (its own appliance), or it can be installed as a Tailored Datacenter Integration (TDI) setup.



However, HANA has its own replication method. For customers who have HANA and want a DR solution, HANA offers a tool called HANA Replication, which replicates the entire HANA appliance to another site. There are several ways of doing that, but first let’s describe the typical setup for HANA.

In a typical setup on the main, Production site, you have one application server running the SAP application. In addition, you have the HANA database

running on its own appliance. This database setup is similar to how you did it prior to HANA – you could have had your database server separate from the application server (running an Oracle database, for example).


On the DR site, you need to have another HANA appliance, in order to replicate HANA, and also another application server. Let’s cover the HANA replication first, and then I’ll relate to the replication of the application server.


To replicate HANA from your main datacenter to a DR datacenter, you must have a second operational HANA database on the DR site (and yes, it’s quite costly, as my friend and colleague Melchior du Boullay covered last week in his blog post, Considerations Before Migrating To SAP HANA). You can have any combination of HANA appliance or TDI at your main datacenter and your DR site, that doesn’t matter, so long as both databases are operational and the DR database is at an equal or higher release level.


In theory, there are two ways for performing that replication, like any other replication – synchronous and asynchronous, with which we started. However, due to HANA’s enormous speed and performance (after all, it’s an in-memory technology), any attempt to implement a synchronous replication without sub-millisecond round trip latency will practically bring the HANA database performance to a crawl, and make it unusable. You will lose all the benefits of HANA. This is why in HANA’s case, using the asynchronous solution is the only practical solution for DR. Synchronous replication is really only an option for High Availability, where both HANA databases sit next to each other; and even then it requires careful consideration.


As for the application server itself, there are two methods for replication:


1. Using VMWare SRM: if you have your primary application server on VMware, you can use the SRM method we mentioned above, in order to keep it in sync with your original application server.


2. Install another server: alternatively, if you’re not using any kind of virtualization, then all you need is to install a fresh application server that has the exact same SID (same system number) as your original application server, and shut down this DR server. You can bring it up when you need to switch to the DR site, and it would work fine. The only thing you would lose are the SAP logs and potential interfaces files. But still, the SAP environment will work just fine, it will allow you to log into the system, and you will see all the transactions and all of your data.



Handling RPO in SAP


Recovery Point Objective (RPO) is defined as the maximum targeted period of time in which data might be lost, due to a major incident (disaster). In other words, how much data can you “afford” to lose in case of a disaster, as defined in your Business Continuity Plan. How is this handled in various SAP disaster recovery methods?


The answer is that it varies, depending on your DR solution. In the Traditional method, your RPO depends on the size of your database logs. The bigger the logs, the bigger the RPO. The smaller the logs, the smaller the RPO. However, if your logs are too small, then you’ll have performance impact, because you need to create a lot of files very frequently. Hence, there’s a balance to be had there. The RPO is always the result of a discussion between the customer and oXya’s SAP consultants, to define what is the acceptable RPO for the customer. Once the RPO is defined, oXya’s experts define the size of the database logs, in order to match that RPO.


For VMware SRM, the RPO can vary between zero (using synchronous storage level replication; again, not recommended across long distances) and 24 hours, depending on the replication settings. It’s important to clarify that 24 hours is not a realistic RPO in the SAP world, but rather the maximum RPO that is set by VMware SRM (page #48). A typical RPO if not using the storage replication option is 15 minutes.



So which DR method is preferred for SAP?


This is the million dollar question, which oXya’s SAP experts are frequently being asked.


The answer: there is no single disaster recovery solution that will be best for all cases. The DR solution needs to be adapted to the customer’s environment, and most importantly to the constraints of each customer. DR is always a compromise between how much money you’re willing to pay, and how much protection you get. oXya’s experts work within the constraints that you set, in order to build the best DR solution possible for your SAP environment.


The Traditional method is still being used by many of our customers, it is working very well, and it has proven over the years to be highly reliable. If a customer comes to us and asks about DR, and this customer has no specific constraints, then we start the discussion with the Traditional method, and explain to that customer the various constraints of that method. If the customer is comfortable with these constraints, then we will move forward with that.


If the customer requires a more sophisticated DR solution, then we discuss the VMware replication solution. However, implementing the VMware solution depends on whether the customer has already virtualized their SAP environment. If they are still running SAP on physical servers and are not considering virtualization, then SRM is irrelevant.


And if the customer has severe budget constraints, we will talk about having an AWS-type of DR solution. This means a relatively cheap DR solution, but it comes with its constraints, which I listed above.





Dominik Herzig is VP of Delivery for US & Canada at oXya. Has 10 years of SAP experience, starting as a Basis Admin, and then moving to SAP project management and to account management. Was one of the first few people to open oXya’s US offices back in 2007, and performed numerous projects of moving customers’ SAP environment to a private cloud, and including disaster recovery solutions.