Skip navigation

HANA Multitenant Database Containers, or HANA MDC, is something fairly new in the SAP world. It first became supported in SPS 09 (Revision 90), less than two years ago, in late 2014. Since it’s a new technology, there are relatively few customers using it. At oXya, we do have customers to which we helped implement MDC. In this blog I will describe the technology, what challenges it solves, what issues it actually creates, and which type of organizations can benefit from it.



Background: HANA before MDC



SAP HANA is an innovative in-memory database system. We’re taking large database systems, and we’re putting them all in-memory, which is pretty expensive from the hardware perspective – they need expensive hardware, with strong compute power and lots of memory.


Before HANA MDC, you had to have a separate SAP HANA instance – possibly on the same hardware, but still a separate SAP HANA instance – for each different database (meaning for each landscape). The meaning was that every time you wanted to install a new HANA system, you either had to buy a new physical appliance; or you had to install a new HANA instance for each different database, on the existing hardware.


The challenge is that HANA appliances are installed by the vendor, and delivered to the customer as an already-configured system. The vendor also certifies that the appliance was correctly configured. Now, if you want to install another HANA instance on that appliance, you either have to engage the appliance vendor again, for them to install another HANA instance in a certified manner; or the customer has to go through the painstaking steps of making sure that the new HANA instance is installed correctly.


In order to perform the installation, you needed a HANA expert to install the new instance, and that’s often done by the vendor that sells you the appliance. In other words, each new installation of HANA was complex, took a lot of time, and often may have also resulted in the need to purchase a new appliance.


All of the above is a rather inefficient way to install new HANA instances, and it obviously generated a lot of extra work.


Another challenge, as you probably guessed, was that the above method was very wasteful, with regards to hardware usage. Not only did SAP face the challenge of making the HANA install process quicker and easier, but also the challenge of reducing hardware costs, that was slowing down HANA sales. The hardware needed for this in-memory computing system is very expensive; SAP’s goal was to reduce hardware costs and footprint of the HANA landscape.


Let’s use an example, to explain all of the above. Imagine a customer (and we have an actual customer like that), who has SAP ERP and SAP BW (Business Suite applications), and they’re both running on HANA. Each of these applications has Sandbox, Development, Quality Assurance, and Production systems, all running on HANA. Before MDC, if the customer wanted to run their ERP on HANA, they needed to buy multiple appliances, one for each system:

  1. An appliance for Sandbox
  2. Separate appliance for Development
  3. Third appliance for Quality Assurance
  4. Fourth and separate appliance for Production.


So far we’re talking about four HANA appliances, and that’s only for their ERP application. If the customer wanted to duplicate their data and also run their BW on HANA, then they would need to buy additional appliances for the BW systems (Sandbox, Development, Quality Assurance, Production).


And of course, it’s not just about the hardware costs, but also a matter of license costs. Do additional instances also mean you needed additional licenses, therefore additional license costs?


Well, the answer in general is “Yes”, or sort of. As a general rule, HANA is licensed by the amount of memory that the application needs. There is a difference between using separate appliances, and using one larger appliance with MDC; that can affect not only hardware costs, but also (to a lesser degree) the licensing costs. I’ll explain that later on, when referring to MDC sizing.



So what is SAP HANA MDC?

container-489933 (Custom).jpg


SAP released a newer feature, Multitenant Database Containers (MDC), which is supported as of HANA SP9 revision 95 and higher. In a nutshell, MDC allows us to take multiple SAP systems, say 2 sandboxes, 1 ERP, 1 BW, 2 development systems and 2 quality assurance systems, and put them all on the same HANA appliance.


The beauty of it: once the hardware provider had provided the appliance and did the initial set-up for the HANA system, we can very quickly and easily create the new database containers for each of our different systems, and allows these different products to cohabitate in the same appliance.


The MDC feature provides huge economy savings in terms of hardware, because instead of buying a separate appliance for each system (or perhaps not an appliance for each system, but an appliance for each landscape – possibly have your ERP’s Dev and QA on one appliance, and the same for BW), you can now take all of these, put them all on a single appliance, and better utilize that hardware.


Of course, as a general rule, we're not going to mix production and non-production systems. So, we still need to separate the Production system. However, for all of our non-production systems, MDC introduced significant flexibility.



MDC Challenges


MDC does come with some challenges, and we hope that SAP will eliminate these challenges in the future. These are current challenges, so you are aware:


First, when you perform replication at present, you take your HANA system and you replicate the databases to another site. There is no ability to replicate just a single database tenant – you have to replicate everything. The replication treats all database tenants as a single database system, as opposed to completely independent database systems. Hence, in the case of a failover to a secondary site, you'd have to perform the failover for all HANA database tenants on that appliance, and not for just one database.


Second, there’s a challenge in terms of version maintenance. In a traditional SAP landscape, we apply patches gradually:

  • We apply the patches to our Sandbox, and test
  • Then, we apply the patches to the Development, and we test
  • Then, we apply the patches to the QA system, and test again
  • And only then, after multiple patching is done on non-production systems, plus testing, we patch the Production system.


The benefit of the above method is we can test patching in many different systems, before going to Production. The challenge with MDC is that when you apply patches to this multitenant environment – you’re applying patches to all the systems simultaneously, because it’s impossible to perform individual patching for each database tenant. Essentially, once you patch your HANA appliance through the MDC, you have patched all the environments that are on the appliance – all at the same time!


“But wait”, you may say, “is this really a challenge? Is patching everything a challenge? Don't you want to patch everything? Doesn’t it save you work and time?”


The answer is – take another look at the patching process I outlined above. Our goal is to prevent impact to the Production system. In an SAP environment, we perform multiple tests on patches in non-production systems, before implementing in Production. The way to ensure that patching is successful, and doesn't cause any negative impact, is by performing multiple iterations: first Sandbox, then Development, then QA. By the time you get to Production, you've already performed patching 3 times.


However, in the case of MDC, once you performed patching on your non-production MDC system, you’ve done that simultaneously to all the systems within the same appliance. You’re not getting those multiple iterations, which is a huge disadvantage.


cargo-449784 (Custom).jpgAlso, there’s another caveat to patching. Let’s say you have ERP and BW on the same appliance, and patching is only required for one product, but not for the other. In the case of MDC, we don’t have a choice – we have to patch them both, at the same time.


This patching challenge is not an insurmountable issue, but it is something to get used to. This is also another reason why the Production system must be separate from non-production – you certainly don’t want to do patching on Production without testing it first!


But all in all, and despite of the above challenges – MDC is a great technology. We're able to spin up new containers in minutes, with a simple command on the HANA system. This, as opposed to having to engage a HANA expert to install the new instance, or perhaps even purchase new hardware every time you need a new a system. MDC adds significant flexibility, and I believe SAP is working to enable the replication of individual containers, and it will be available in the near future.



Difference between HANA system and the Containers


One important thing to understand is the difference between the HANA system and the containers, as each container has its own SID (system ID), in addition to the SID for the HANA appliance itself. For a customer that is going to use MDC, it’s important to realize that they have to name their HANA appliance uniquely for the entire appliance, and then name each container based on its purpose. In other words, you have an SID for the HANA instance on the appliance, and then you have a separate SID for each container.


Let’s explain that using an example. Let’s say that the SID of the HANA appliance would be HA1. Then, we’ll give various names to the containers, usually according to some kind of a key. For example, we will use "Q" for quality assurance, “D” for Development, “E” or “B” for ERP and BW, and an "H" to indicate that it's a HANA system.


With the above method, your development ERP container could be “DEH”, and your development BW container could be “DBH”. The QA containers will be “QEH” and “QBH”.



MDC Sizing

tape-measure-1186496 (Custom).jpg


Earlier, I mentioned sizing and said that customers may also save some money on license purchases. In order to explain that, let’s start with the traditional sizing for HANA, meaning separate appliances for each system.


HANA is a database, and each database system (Development, QA, Production, etc.) needs its own memory to contain its database. There are no savings in terms of reducing the volume of each database, because they stay the same, whether in separate HANA appliances or when using MDC, on one larger appliance.


However, when performing sizing, one doesn’t size just perfectly – you always leave room for growth, meaning a buffer. When you size for separate HANA systems (say one Dev and one QA), you will oversize for both systems, to make sure that you have sufficient space. However, when you do that, you often significantly oversize, and you actually “waste” hardware. In fact, I Can guarantee that if you look around the world, at various HANA systems, there's lots of memory and CPU that are not being used. Customers are paying for this over capacity, not only in hardware costs, but also in HANA licensing costs.


Consolidating systems omits the above, and provides great savings. When consolidating HANA databases, we don’t need to oversize for each database separately. We can better utilize the resources on the server, and oversize to a smaller extent, for all databases combined.


Basically, what you're saying is that if before we needed 2 appliances, let's say each 1 with half a terabyte of memory, then when we combine them all on the same appliance, we need actually 1 appliance with 1 terabyte, that's 2 halves and you may be able to save a little out of the 1 terabyte, put a little less because you don’t buffer twice or you don't oversize twice.


Take one of oXya’s customers, for example. This customer has 5 different HANA systems, with each database in need of 200GB (already includes space for future growth), meaning we need a total of 1TB. If you went ahead and bought separate appliances for each database, as was the case before MDC, then you would buy five appliances with 256GB each (5 x 256GB). This means you’re wasting more than 250GB, above and beyond your needs. These systems will be gravely underutilized.


However, when you consolidate those systems, then you only need to buy a 1TB appliance (which again, already includes space for future growth). Then, as some databases grow, those databases that need the additional resources are able to utilize them. Furthermore, not only do you better utilize the hardware and licenses, but you may even be able to add additional systems onto the same hardware, once it's running.


Having said all of the above, it’s important to understand that Sizing is a bit of an art (and not really a Science, as some people claim). When you perform sizing, you make assumptions regarding what is going to be once it’s running, and it doesn’t always happen this way. That’s one reason why there’s a tendency to oversize. When we're sharing several databases onto a single system using MDC, we're able to better utilize resources.


Come see us at SAP SAPPHIRE this week – stop by the Hitachi booth, look for the oXya team, and discuss your SAP challenges with us.




oXya_HGC_logo (Custom 300).jpgSevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Group company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of ten SAP professionals, at oXya’s service center in New Jersey.


oXya, a Hitachi Group 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 more than 650 SAP experts, who service more than 330 enterprise customers with more than 300,000 SAP users around the world.

Two interesting things happened in the last couple of weeks, that led to writing this blog:

  1. We received a new white paper from research firm ESG, analyzing the impact of SAP S/4HANA on the SAP market and on our own business – Technical SAP Consulting & Managed Cloud Services.
  2. I attended an interesting meeting with individuals from several other Hitachi Group companies, to discuss various things regarding the SAP market and our activities in the coming year.


One of the things I realized in that meeting, and this sometimes also happens in conversations with various people working in the SAP ecosystem, is that there’s a lack in understanding some of SAP’s newest technologies in the market. Specifically, I’m referring to the difference between HANA and S/4HANA; what each of these does; and what is the revolution taking place these days in the SAP market, due to these technologies.


By “lack of understanding” I don’t refer to fellow technical SAP experts, they certainly understand the above, and possibly also know the “behind the scenes” of the war that is taking place in the last few years. But do your business people, marketing experts, sales folks – all those non-technical experts in the SAP ecosystem – do they know what the difference is, and what’s going on? Or do they think, as I sometimes hear, that S/4HANA is in fact “HANA version 2.0”, or some other variant ?


So, today’s blog is dedicated mostly for the non-techi folks in the SAP ecosystem, but all you techi friends are also welcome to read. This will be a story full of emotion about the longtime rivalry between two of the world’s leading tech giants, and a real battle that’s taking place today around SAP customers.


For those who want the short version, here it is – SAP HANA is a database. SAP S/4HANA is the new business suite of SAP applications, that runs on the HANA database. That’s it, but there’s so much beyond that. So go ahead and read the full story.


And a word of caution – to best serve the non-technical audience for which this blog is written, it is going to be simplistic and high-level, with as little technology deep-dive as possible.



What is SAP – in 2 minutes


When an organization has a mission-critical SAP system, it actually means they have a system that consists of various layers of software and hardware. Let’s leave the hardware aside for the moment, since it’s less relevant at this point. On the software side, an SAP system has three main layers:

  1. Operating System (OS)
  2. Database (DBMS)
  3. Applications


Traditionally, SAP was an applications vendor. Everyone in the industry knows these applications very well – ERP, Supply-Chain Management, Finance, HR, Logistics, Manufacturing, Retail, and many other applications that SAP has been producing over the years, for running an enterprise at all levels.


Also traditionally, SAP applications ran on top of third party databases (this is where the actual data is stored), as SAP did not have a database of its own. The main databases on which SAP applications run are Oracle, MS-SQL and IBM DB2, though there are additional databases that SAP runs on, such as Sybase (which SAP acquired back in 2010, for $5.8 billion; here’s an interesting article from that year, on why SAP acquired Sybase).


Oracle Corp plays an interesting role here. On the one hand, Oracle is a bitter competitor of SAP, because it’s application suite – Oracle Applications – is a direct competitor of the SAP application suite. On the other hand, Oracle is one of the leading databases in the world, with many SAP customers running their SAP applications on the Oracle database. In other words, the SAP market is a major revenue generator for Oracle Corp on the database side; Oracle database license revenues from SAP customers make a major percentage of Oracle Corp’s total revenues.


All of that synergy lived relatively well until 2012 – SAP focused mostly on the applications side and led the market in that category, with Oracle being a distant #2 (here are two Forbes’ articles covering Gartner’s analysis of the ERP market and the Supply-Chain Management market). On the database side, Oracle has been the market leader as far as license revenues; Oracle generated (and still generates) a significant portion of its revenues from SAP customers running on Oracle.


And then came SAP HANA.



SAP Introduces HANA – The In-Memory Database


6224518717_976c2ba19a_z (Custom).jpg

SAP officially launched SAP HANA in November 2010. HANA is an in-memory database, which is a revolutionary technology, compared to “standard” databases. In regular databases, all the information is stored on disks that “live” in enterprise storage systems. When a database gets an inquiry, it goes to the disks, searches for the information, retrieves it to the system’s memory, and then performs various operations on (or using) this data. Once it has finished with the specific piece of data, it stores it back onto the disk, until the next time it needs this data.


An in-memory database operates differently. The infrastructure for this database consists of an enormous amount of memory and compute power (compared to “standard” storage), the data resides at the memory level at all time, and all actions are performed within the memory itself. Since memory is significantly faster than disk (memory access time is measured in nanoseconds, while disk access time is measured in milliseconds), HANA performance is also significantly faster when compared to that of standard databases. In addition, HANA brings other meaningful advantages – I covered HANA benefits in a blog that focused on Considerations Before Migrating to SAP HANA.


The launch of the SAP HANA database was like waving a red flag at a bull; the bull’s name was Oracle. Here, SAP no longer competed only on the application layer of the business; Oracle suddenly saw a direct, potential threat at its bread-and-butter – the database business and the revenues it generates. And it reacted (photo credit: Naoki Nakashima, Flickr).


Larry Ellison, Oracle’s Founder, Chairman and CTO (and one of the 10 richest people in the world), launched a series of fierce attacks on SAP and HANA. In a series of keynote speeches and interviews, that started almost immediately after the HANA launch in 2010 and is still ongoing, Ellison has been doing his best to bash HANA and install doubt and fear in the minds of SAP customers. Some of his speeches and recordings have become iconic in the industry, such as this 2-minute video from 2012, or his keynote speech at the 2014 Oracle OpenWorld, to name just two cases.

Larry (Custom).png

Bill_McDermott (Custom).png


The bottom line of Larry’s comments – HANA is a brand new system, not yet tested, and not proven for mission-critical workloads. SAP will never substitute their long-time, proven Oracle database, for the HANA database.


SAP’s reaction to these attacks was polite and respectful. Here’s an example from a Yahoo Finance 2-minute video interview with Bill McDermott, SAP’s CEO, following one of Larry’s bash attacks.


What actually happened in the field? Like with any new and innovative technology – not to mention mission-critical in its influence – adoption has been slow. It takes an Innovator, visionary CIO to be one of the first in the market to adopt a brand new technology for one of the organizations’ most mission-critical systems (SAP). (graphics credit: The University of Arizona).



Overall, HANA adoption lagged behind SAP’s own estimates. Customers did take their time to migrate to HANA. In its FY2015 reports, SAP wrote (page 7 of the PDF) that “In just a few short years, nearly 10,000 customers and startup companies chose to innovate on SAP HANA…”, which means an adoption rate of less than 5% from SAP’s customer base. However, the quarterly reports that SAP publishes also show an acceleration in adoption, as was expected.


At oXya, we had the privilege to work with a few such innovative customers, and support them in their migration to SAP HANA. As of May 2016, more than 50 out of our 335 enterprise managed services customers (roughly 15% of oXya customers) are already running on SAP HANA or are in the process of migrating to HANA. We are very proud of this significantly-above-industry-average percentage, and that we are an industry leader in migrating SAP customers to SAP HANA and S/4HANA (and I’ll write on S/4HANA in the following section).


Since SAP saw that adoption of the HANA database has been slow, what did it do to accelerate this adoption, and to further innovate in the market? It introduced SAP S/4HANA.



SAP Introduces S/4HANA – The New Suite of Business Applications


In February 2015 SAP introduced SAP S/4HANA, which is “a next-generation business suite designed to provide the digital core SAP customers need to run their entire business in a digitized world.” (quote from SAP’s FY2015 annual report).


SAP S/4HANA is not a database. Rather, it is a new and revolutionary application suite from SAP. Research firm ESG writes that “This (SAP S/4HANA) is perhaps the single biggest shift in SAP technology for the last 25 years, since SAP R/3 was introduced in 1992”. Many SAP experts agree with this statement. SAP S/4HANA includes many innovative technologies and features, that all have one common goal – to enable organizations to run their SAP in a simpler, faster, and far more efficient way, while supporting new work processes (such as mobile). With all that, SAP S/4HANA helps customers to be more competitive in the market place, and better align with modern challenges of the digital world. We wrote in the past about some of the new features in S/4HANA, such as Fiori, the new SAP GUI (see the table and video in this blog post, for a comparison of time and efficiency between the old SAP system and the new one).


And the kicker about S/4HANA – as its name implies, this new suite of applications only runs on the HANA database!


In other words, customers who will want to upgrade to the newest and best SAP suite of applications, will have to also adopt the HANA database and run on it. They will not be able to choose any other database – it only runs on HANA.



So what does it all mean?


There are a few interesting questions to ask, in the aspect of S/4HANA:

  1. What will the adoption of S/4HANA look like?
  2. Which SAP customers will migrate to S/4HANA?
  3. How will this migration cycle affect the IT industry?


Let’s answer these, one by one.


How will the adoption of S/4HANA look?

Like with any new technology, it will be in stages, exactly like in the adoption cycle graph shown earlier. First come the Innovators, and we already see enterprises who have migrated to S/4HANA, or new SAP customers who performed greenfield installations of SAP S/4HANA. oXya has a few such customers, including in North America – we hope to share their stories in the future. After the Innovators will come the Early Adopters, and then the Majority – Early and Late.


ESG estimates, in its paper, that “This (SAP S/4HANA) will become the mandatory standard for SAP customers in the near future, assuming they wish to stay current on SAP product enhancements. At some point, support of older versions will start to become increasingly difficult.”


My own estimate is that the “near future” that ESG is referring to will take some time. We are still at the Innovators stage. It will probably take a few good years to cover the percentages “needed” until the market reaches the stage of Majority adoption, but it will come. The reason for that is explained in the next paragraph.


Which SAP customers will migrate to S/4HANA?

In my estimate – everyone, eventually, or at least the majority of customers. After all, it is exactly like ESG says – any customer that wishes to stay current with SAP technology, and maintain a competitive place in the market. SAP customers cannot afford to stay behind with old, dated systems, that are less efficient.


Customers will want to keep current with their competition, and will eventually be “forced” to move to S/4HANA (which, of course, will continue to evolve and improve). I suspect it’s still 4-5 years away (and possibly a bit more) before we see the large mass of SAP customers migrating to S/4HANA (and to HANA, as a result), but I have no doubt that it’s coming.


How will this migration cycle affect the IT industry?

In a huge way. The move from “regular/current” SAP systems to HANA and to S/4HANA affects many facets of the IT industry:

  • Infrastructure for SAP: First, HANA requires different infrastructure than current SAP systems. There are already various infrastructure vendors who are playing in this field, with more who will probably enter the market. Hitachi Data Systems, with which we closely cooperate, is a leading player in the SAP HANA market, with its Hitachi Unified Compute Platform (UCP). And second, as customers choose new infrastructure, they will often want to avoid the high Capex costs that are associated with the HANA hardware; instead, many customers will prefer to move to a cloud system with an opex-based consumption of hardware, such as the one oXya offers.
  • Functional/Design for SAP: The system integrators’ (SI) community will also have its hand full with the transition to S/4HANA; while SAP recommends using the standard applications and creating minimal adjustments, many organizations will probably want to adjust the new applications to their specific needs. Hitachi Consulting (HCC), our sister company, is a leader in this area, and we’re closely cooperating with them.
  • Technical Services for SAP: Companies such as oXya will certainly have their hands full. Most SAP customers do not have the necessary in-house knowledge and expertise in order to migrate to HANA and S/4HANA; They will require external help, from the likes of oXya, who have already done that numerous times, and can help assure a fast and painless transition.
  • Managed Services for SAP: This is another market in which oXya is a major player. As SAP customers adopt these new technologies, they will require skilled personnel to run the new SAP systems around the clock, to make sure the new SAP provides peak performance and generates a great ROI for the organization. This may mean choosing an SAP partner that you can count on, a partner that provides you with a dedicated team that is an extension of your own IT organization, and various other unique features. As you can read in the new white paper from ESG, there is a shortage of skilled technical IT people in the market, across multiple areas. Many of these areas are covered by oXya’s dedicated support teams, once a customer chooses our services for running their SAP – so working with oXya as a partner can immediately solve multiple recruiting challenges, of the following expertise areas:
    • SAP Basis (not in the ESG table, but huge shortage in the market)
    • Server virtualization/private cloud infrastructure
    • Compliance management, monitoring and reporting
    • IT architecture/planning
    • Data protection
    • Database administration
    • Storage administration
    • Server administration
    • Network administration


Of course, there’s another potential effect on specific industry players – the database vendors. The main one to get hurt is probably Oracle, which presumably has the largest share of database revenues from current SAP customers. I wouldn’t go out on a limb in estimating that we can expect the level of bashing and attacks from Oracle to increase in the coming years, or at least stay at current (pretty high) level. Oracle Corp have very smart people, and no doubt they analyze the marketplace in a similar way to what I did above – some of Oracle’s core customer base is about to disappear, and migrate off Oracle in the coming years.


I hope to see many of you at SAP SAPPHIRE – stop by the Hitachi booth, look for me and the rest of the oXya team, and feel free to discuss your SAP challenges with us. You can also email me at any time, to


oXya logo for LinkedIn 300x300.png


Melchior du Boullay is Managing Director, 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 Group 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 more than 600 SAP experts, who service more than 330 enterprise customers with more than 300,000 SAP users around the world.

This blog was co-written with Melchior du Boullay, Managing Director, Americas, at oXya.




This is the sixth and last blog in our “Outsourcing SAP” series. It focuses on questions we received regarding all the blogs in this series, as well as a few recurring questions we hear from almost every customer and prospect.


Our previous two blogs in the Outsourcing SAP series focused on the Planning Phase of moving your SAP environment to oXya’s datacenter, and the Technical Operations Phase of this move. Previous blogs in this series covered various aspects of outsourcing your SAP environment. In the first blog of the series, we asked should we outsource our SAP environment, and suggested a few directions to think about. In the 2nd blog we wrote about choosing the right partner that would manage our SAP environment, and listed various criteria and tips for choosing that partner. The 3rd blog discussed various infrastructure and headcount considerations that each and every customer has, when considering whether and how to outsource their SAP.




Questions and Answers


Does oXya require a minimum term length for its services?

At oXya, we don't believe in "vendor lock-in", and as such many of our services require just minimal term commitments from our customers (if at all). Often we require no more than 30 days' notice to terminate. Our industry-leading customer satisfaction ratings (> 98%) are the best testimony to the fact that our customers want us there, month after month.


Can I build a Private Cloud on my premises?

cloud-businessman-computer-laptop-sky-celebrate-happy (Custom) (2).jpgYes, absolutely. Many organizations, who have already invested heavily in existing datacenter facilities, want the benefits of the cloud (flexibility, resiliency, consumption-based pricing, self-service, automation, etc.) but with the peace of mind and efficiencies that come with using their existing, private floor space. At oXya we understand this and work with our customers to help build, deploy, and manage both on- and off-premises cloud solutions, based upon world class infrastructure, tools, and services.


Does oXya have both Private and Public Cloud options?

Yes, oXya/Hitachi can provide off-premises cloud solutions for both Private (dedicated compute, storage, LAN, and floor space) and Public (shared infrastructure, logically partitioned) options. Typically, customers with demanding production availability, performance, and security workload requirements choose the oXya private cloud model; and when short-term, cost-effective options are preferred (e.g. for a sandbox system) the oXya public cloud infrastructure is a perfect fit.


My team is currently working on a HANA migration project and we're under a tight timeline. How can oXya help?

Approximately 25% of the global oXya customer base has already or is currently implementing SAP HANA (from Suite on HANA, to S/4HANA, as well as custom developed applications), and over half of these customers have already gone live and are currently in Production.  The oXya delivery teams were key components of those projects. This means project management, as well as execution of numerous upgrades, migrations, and installations, plus the architecture, design, and hardware selection for the HANA landscape components, including DR solution planning and implementation. Let oXya safeguard your SAP HANA implementation, leveraging our significant experience and expertise to ensure a stable, well-designed and built platform, that will dramatically shorten your time-to-value.


Where are oXya support personnel and facilities located?

oXya has over 600 team members located in facilities across the US (NJ, CO, CA), Canada (Montreal, Toronto), Europe (France, UK, Belgium), and Asia (China, Japan). Additionally, 99% of oXya's delivery team members are full-time Hitachi/oXya employees (with few exceptions, we do not use sub-contractors). What this means in practice is that when you choose oXya to provide SAP Cloud and Managed Services for your landscapes, rest assured that your systems will be managed by in-country or near-shore resources (your choice) who will speak the correct language (natively) for your organization’s needs.  Unlike most other globally certified SAP service providers, we provide the right resources in the right countries, in the right time zones, speaking the right languages, based on your requirements.


Our organization has had some poor experiences in the past, with another SAP managed services company. What makes oXya different?

oXya2 (Custom) (2).jpgAt oXya, we understand what it's like for customers who have been mistreated by the large, offshore providers who's service is typically over-priced, inflexible, and poorly delivered. In fact, some significant percentage of our customers came from such a contract/provider!  (and they’d be happy to be a reference, and tell you about their experience at oXya, compared to their previous provider).

And now, let’s answer the direct question, about “what makes oXya different?” The oXya delivery model provides teams of named resources who are assigned to your account and dedicated to your satisfaction. By design, your assigned and dedicated team will:

  • Be located on/near shore and provide 24x7 support.
  • Be your primary point of contact for ALL platform performance and availability issues (we will coordinate and drive support with 3rd party vendors as required, so you don't have to).
  • provide you with their email addresses and cell phone numbers (so you can contact them directly when required; we do not have a call center – you call directly to your dedicated support team).
  • Work to understand your unique business processes and requirements.
  • Have in-depth knowledge of your systems and landscapes.
  • Have working knowledge of every layer of your platform stack (SAP Basis, Database, Operating System / VM, Compute/Storage Hardware, LAN).
  • Have access to a global team of oXya consulting experts (for level 3 and 4 issues which require an additional level of knowledge).
  • Work with you from migration to renewal (to ensure consistency).


AWS seems like a cheap and effective alternative. Why wouldn't we just use Amazon?

At oXya, we provide support for the entire SAP platform (from SAP Basis through the datacenter floor), not just Infrastructure-as-a-Service (IaaS). We have several current customers who began their SAP S/4HANA implementation with AWS and found, for a variety of reasons, that oXya provided measurably better monthly service costs, performance, and support of their SAP stack. Additionally, some of our customers are concerned that other providers simply can't provide the security and data privacy that their enterprise applications (and auditors!) demand.


Most hosting providers just source labor from offshore. We simply can't trust (or even know) who has access to my data, or when.

At oXya, with very few exceptions, ALL of our delivery personnel are full-time Hitachi employees, not sub-contractors. In addition, you can choose which oXya region and facility will deliver your services (for example, US customers can choose between teams and facilities located in NJ, CO, or CA).


How many SAP HANA customers do you have?

oXya has more than 330 SAP customers (and hundreds of thousands of SAP users), as of March 2016. More than 25% of our customer base are currently implementing SAP HANA; of these, more than 50% have already gone live.


How many SAP S/4HANA customers do you have?

oXya has over a dozen customers who are currently implementing SAP S/4HANA (several are now live), and many other customers who are currently investigating how/when/if to proceed with their own implementations, relying heavily on input from the oXya team members regarding various upgrade, migration, installation considerations and options. Obviously, S/4HANA is in its infancy, so adoption has been somewhat methodical and slow-paced to-date, as customers take their time to examine and evaluate their business cases. We expect to see a significant increase in customer S/4HANA projects through the remainder of 2016. One of the many benefits of becoming an oXya customer is the ability to collaborate and knowledge share with other customers (often with similar landscapes, projects, and implementation challenges).





This is our final blog in the “Outsourcing SAP” series. If you have additional questions that were not answered in the series, including in the current Q&A, please post them to the Comments below or send us an email, and we’ll answer your questions. If we get enough additional questions, we may post another Q&A blog in the future. Our emails are: Scott LaBouliere <> or Melchior du Boullay <>.



Scott LaBouliere is VP Business Development at oXya, a Hitachi Group Company. As an SAP professional with more than 15 years of experience in the SAP market, Scott possesses in-depth knowledge and experience in architecting, selling, implementing, and managing Cloud-based solutions across the entire SAP application suite (SAP HANA, ERP, BW/BOBJ, SCM/APO/CRM, NetWeaver components, BPC, etc.) for a wide variety of industry verticals in the Large Enterprise and Mid-Market spaces – Pharmaceutical, Retail, Wholesale, CPG Manufacturing, Energy, High Technology. Scott came to oXya after nearly 7 years at FIT, where he served as the Chief Operating Officer. Prior to that, Scott was VP of Managed Services with SAP America, Inc.


Melchior du Boullay is Managing Director, 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 Group 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 330 enterprise customers with hundreds of thousands SAP users around the world.

Over the last several months, ESG Research has been performing a research project on oXya’s managed services for SAP. We hired ESG—a reputable IT research firm—to validate our services and unique offerings, including a dedicated team that is assigned to each customer, and our ‘all inclusive’ offering for a fixed monthly fee.


The end result can be seen in the below brand new video, but it wasn’t a fast nor easy process to get there. For those who think “OK, oXya paid them so they’ll say anything asks them to”, my answer is – no, it doesn’t work this way. As a reliable research company, ESG won’t say anything we ask them to, just because oXya hired them. We needed to prove to ESG, every step of the way, that we indeed deliver everything we claim. In fact, it’s similar to how we needed to pass multiple tests by SAP Corp over the past year, in order to get SAP’s GLOBAL certifications for SAP HANA® Operations Services, Cloud Services, Hosting Services, and of course – an SAP Global Partner certification. We just recently received all these global certifications (we already had certain certifications for many years, but not globally), and are very proud of that. See our SAP certification logos in this blog and in the video.


(oops, not sure I’m supposed to talk about the certifications… I may have just revealed something that we planned to release next month, before SAPPHIRE Orlando, to attract more people to come visit us at the large and amazing Hitachi booth; marketing won’t be happy…)



Let me tell you a little about the “behind the scenes” that led to this video; we worked really hard to prove to ESG that oXya does deliver on what we claim.



Nik Rouda, Senior Analyst with ESG Research, was skeptical about two main things:

  1. Personal Touch & Dedicated Team. Our commitment is to assign a dedicated team with all relevant expertise (Basis, DB, OS, HW, etc.) to each of our customers. This is what we’ve been doing since oXya was founded, back in 1998. Nik was especially skeptical about our ability to grow globally and continue with that approach. After all, none of our global competitors operates this way; when you call them with an issue, you get a different support person each time, from somewhere around the world; often they don’t know you nor your SAP systems, and your ticket circulates between various silo teams, until your issue was resolved. This kind of service significantly delays the time to resolution, and make customers unhappy (I wrote last month about the oXya unique delivery model, versus the standard model).
  2. ‘All Inclusive’ Service. Another thing that Nik was doubtful about is our commitment for an ‘all inclusive’ service for a fixed monthly fee. Many people believe this sounds insane from a financial perspective, and especially since we don’t suggest multiple change management ideas to customers, like many of our competitors do (and they also charge you and arm and a leg for that, of course). For oXya, having long-term customers who are happy and renew their service with us, time and time again, is worth all this. First, it’s our company values of Commitment, Trust, and Service that are driving us. But even more so, if you think of the acquisition cost for a new customer, or the cost of customer churn, you’ll understand why our approach also makes perfect sense from a financial perspective.



BTW, as part of the background work preparing for interviews with Nik, we wanted to learn what is our real customer churn, and how happy our customers are with oXya’s services. Here are the results:

  • As of this month, March 2016, oXya has ~335 enterprise customers around the world.
  • Over the last 5 years, oXya lost 2 customers who did not renew their services with us (yes, that’s not a mistake – just 2 customers in 5 years!). That’s a churn rate of 1% in five years!
    • One of these two customers, BTW, did not renew its service contract with us since they were acquired, and the acquiring company worked with a different SAP managed services provider. That loss of a customer felt bad, but it had nothing to do with our service, and there was nothing we could have done to keep that customer.



Let’s back to the “behind the scenes” story. In order to prove our service commitments and claims, Nik asked to meet with our customers, and he did. He held long interviews with customers, and heard from them exactly what we tell the market and what every prospect hear from us – about our great and committed service, which includes a dedicated team that knows the customer very well and the customer knows all team members; the 'all inclusive' service and the fact that we don’t look for ways to overcharge our customers; and much more.


We also proved to Nik how, nearly a decade ago, oXya expanded its services beyond the EMEA market, and built successful service and hosting centers—with local teams—in Americas and APAC (our Americas operations will celebrate 10 years next year). Over the last year, since Hitachi acquired oXya, we’ve been expanding more rapidly, yet we are still passionate about maintaining our service levels, personal touch and dedicated team, which are what brought us thus far and have been the basis of our amazing success and happy customers.



At the end of the process, Nik acknowledged that we indeed managed to grow and expand significantly, on a global basis, while still maintaining our unique service offerings. Still, he was a bit hesitant and skeptical whether we will be able to continue growing at this fast pace, and still maintain the same type of services and levels of service. You can hear that in the video, when he talks about our future growth, and that’s understandable – he is an analyst, so he needs to be cautious.


For us at oXya, on the other hand, there’s no question that we’re moving forward exactly like we operated thus far, and that we’re not going to let anything harm or change our amazing service, not even continued fast growth. Customer satisfaction is in our core DNA, and we’ve proven that time and time again. We also have a unique, internal model for how we train new SAP experts and build our teams for fast growth, but that’s something for a different blog.


So enjoy this video, and I hope to see many of you at SAPPHIRE – stop by the Hitachi booth, look for the oXya team, and feel free to discuss your SAP challenges with us. You can also email me at any time, to




Melchior du Boullay

Managing Director, Americas

oXya, a Hitachi Group Company





Melchior du Boullay is Managing Director, 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 Group 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 335 enterprise customers and hundreds of thousands of users around the world.

This blog was co-written with Dominik Herzig, VP of Delivery for US & Canada at oXya, and Melchior du Boullay, Managing Director, Americas, at oXya.



Outsourcing SAP 4 - Planning Phase - screen shot (Custom).jpg

Our previous blog in the Outsourcing SAP series focused on the Planning Phase of moving your SAP environment to oXya’s datacenter. That blog was the 4th in our “Outsourcing SAP” series, covering various aspects of outsourcing your SAP environment. In the first blog, we asked should we outsource our SAP environment, and suggested a few directions to think about. In the 2nd blog we wrote about choosing the right partner that would manage our SAP environment, and listed various criteria and tips for choosing that partner. The 3rd blog discussed various infrastructure and headcount considerations that each and every customer has, when considering whether and how to outsource their SAP.


Today we present the second part dealing with moving your SAP landscape to oXya’s management. Last week we wrote about the Planning Phase, and this time we focus on the Technical Operations Phase.


As a reminder, when providing managed services for our customers’ SAP landscape, oXya has two high-level types of offerings:

  1. Run Management only: oXya provides only the managed services portion, while customer chooses to maintain responsibility for their hardware and for hosting SAP. In this case, oXya requires a quick and reliable link between oXya and the customer’s datacenter, to provide the support services. We covered that option in previous blogs in this “Outsourcing SAP” series.
  2. Full Cloud Delivered service: oXya takes full ownership and responsibility for the customer’s infrastructure and hosting, and the infrastructure is installed at one of oXya’s datacenters.


This blog and the previous one, about the two phases of moving your SAP landscape to oXya datacenter, focus on the second option—the process of moving your datacenter and infrastructure to the oXya private cloud. The blog is based on past experience with multiple North American customers, where we’ve migrated these customers’ full SAP landscape, plus all of their servers (including non-SAP servers), to the oXya cloud.


The previous blog ended with oXya and the customer finishing the Planning Phase, we had all the necessary workshops and coordination done with the customer, the hardware was prepped, and everything is ready for actual transfer of the servers. This is where the Technical Operations phase begins. This phase includes the actual transfer, dry runs, and all actions until we go live, and oXya accepts full responsibility over all systems.


At this point, it’s important to note that there are differences between migrating SAP servers and migrating non-SAP servers (which oXya also runs for its customers).


Migrating SAP Servers

biz-people-data-center-140821-2379-high (Custom).jpg


This is our main expertise, we’ve been performing SAP migrations and hosting for hundreds of enterprise customers over many years. There are several migration options; the specific process depends on the customer’s sensitivity to downtime – some customers are OK with having their SAP servers down over a weekend, while others are extremely sensitive to downtime, and need it minimized. Generally speaking, and this is true for any type of migration (both SAP and non-SAP systems) – every time you want to minimize the downtime, there’s a tradeoff to be had, a balance of pros and cons.


Whichever process is chosen, there are some common operations for any SAP system. We will:

  • Begin with Development & Quality, make sure the process completes smoothly, from start to finish.
  • Then we execute a dry run and test the process for the Production environment, get validation from the customer that everything works fine and all the data is there, and they can access and perform basic operations.
  • If customer is happy with the dry run, we can perform the actual systems migration and Go Live on the following weekend.
  • We will then finish with a test, to validate that everything is OK and everyone can do their job.


If the customer is not happy with the dry run (step 2), then we’ll do the necessary modifications, perform another dry run to validate that this time everything is OK, and perform the Go Live migration afterwards.


The way we actually migrate each SAP system depends on the criticality and sensitivity to downtime of the specific customer. I’ll list them from the most standard process, that of a customer who is the least sensitive to downtime and can afford taking the systems down over a weekend; and ending up with the most sensitive customer, who needs the systems to be down for the shortest time possible.


Weekend Downtime


If the customer is ok with having 2-3 days of downtime over the weekend, there are two methods that can be used. The difference for using which one to use, depends on whether we want to change the operating system and/or database during the migration, or we continue to use the same OS and database as in the original customer SAP system:

  • Systems Copy. This method supports changing the OS and/or DB as part of the migration process, so the OS and/or DB on the new oXya systems are different from what customer runs before the migration. Systems Copy is done via export and import, using SAP’s “R3Load” tool. The result will be the customer’s SAP system, is running on a different OS and/or database
  • Backup. If we’re not changing the OS and database, we can build an entirely new system on the oXya side, with the same OS and database, take a backup on the customer side, and ship the backup to oXya. Then, at the oXya datacenter, we’ll apply that backup to the blank SAP setup we prepared, and start the system from the backup. The result will be an exact copy of what the customer has at their datacenter.


Minimal Downtime


The above methods are the simplest approaches to a SAP migration, given that the system can be shut down for several days. However, if you need to perform the migration with minimal downtime, there’s one method that trumps all others – the DR method.


hourglass-620397 (Custom).jpg

Disaster Recovery-like mechanism. If downtime is really an issue, the easiest method is to use a DRP-like mechanism for SAP. We will set up an SAP system at our datacenter, which is an exact replica of the customer’s system (same hardware, OS and DB), and configure it as a DRP (asynchronous) of the customer’s existing SAP system. This method enables us to shorten the downtime to a very short time period (half an hour, if everything goes well), of switching from the primary system (customer’s datacenter) to the DR system (oXya datacenter). We will still follow the common procedure described earlier – first do a dry run and a test with customer’s users to validate everything, make any necessary corrections, and then perform the real migration.


The dry run is done over one weekend. We will simulate the exact same system as the customer’s primary system. If successful, we will repeat the process on the following weekend. The purpose of the dry run is to make sure the process works, and everyone can validate and test the new system.


Once the dry run is finished we will shut it down, bring back the primary system on the customer’s side, rebuild the DR system on oXya’s side during the week, and repeat the operation on the following weekend, for the Go Live. This process significantly reduces downtime, to almost nothing (in a nutshell, the dry run is exactly the same operation as doing a DR test, and the Go Live is the same operation as switching to a DR system in a real crisis situation).


The main thing to remember regarding a DR-like mechanism – the new SAP system, in the oXya datacenter, must be the same (hardware, OS and database) as the current system on the customer side. The DR method only works if you’re not changing your SAP landscape (i.e. keeping the same DB/OS platform and SAP application versions, etc.).


What if you need to change the system?


We mentioned the DR method doesn’t work if you want to change either the hardware, OS or DB between the current customer system, and the new system at the oXya datacenter. If you want to perform such a change, there are two options:

  1. We first switch to an identical system at oXya (using the DR method), and later switch components in the system (OS, DB, etc.).
  2. We use the first method mentioned, Systems Copy, to perform an export/import, in which case the OS and database can be changed. However, this approach requires a longer downtime (you cannot configure the new system as a DR).


The bottom line: if you want to change your landscape—hardware, OS or DB—there’s no going around a longer downtime period, typically a weekend. What can be done, to minimize the risk of “all at once”, is to perform the migration in two steps: first migrate the system “as is” to oXya using DR, and then perform the OS or DB migration over another weekend. However, it doesn’t matter whether you’re moving from the customer datacenter to the oXya datacenter, or you do the change within oXya’s datacenter – whenever you change your landscape, you’ll need a longer downtime.


Migrating non-SAP Servers


As already mentioned, we have many customers for which oXya manages their entire IT infrastructure, not just their SAP systems. With regards to migrating non-SAP servers, it depends on the type of the system.

biz-people-data-center-140821-2982-high (Custom).jpg

There are essentially 3 types of other systems:


  1. Systems virtualized using VMware. If the customer already has a system virtualized using VMware, we will use one of the following two methods:
    1. Migrate the VMs to oXya using the VM container (this option is when customer already has SAP virtualized with VMware, and the system stays with the exact same server names, VLAN, IP addresses, etc. – no change as part of the transfer).
    2. Export of the VMs and ship them to oXya (this option is the SAP system is already virtualized, but the move to oXya involves some type of transformation/change within the VMware system, such as changing the host name, or an IP address). If the system is small enough, we can ship it over the network; if too big, we will put it on a fast disk and fly it over to the oXya datacenter.
    3. If a very short downtime is required, there’s a 3rd method when migrating VMware-based systems, using a tool such as Veeam Backup & Replication. This tool creates a backup, moves it to oXya, and keeps it in sync with the original/customer system, using the Veeam tool. This allows us to “bypass” the transfer time to oXya, significantly shortening downtime. This method obviously has a cost.

  2. Systems virtualized with a different hypervisor. The second type of migration is for servers that are virtualized, but not using VMware (for example, with Hyper-V). At oXya, we typically use VMware, though there are some exceptions. If the customer’s servers are virtualized using Hyper-V, and oXya servers are typically virtualized with VMware, then we will perform a Virtual to Virtual (V2V) migration, using the VMware vCenter Converter tool.


  1. Non-virtualized systems. The last type of servers are physical servers. If the customer has these, there are two options:
    1. If the server can be virtualized, we’ll perform a Physical to Virtualized (P2V) migration using the VMware converter, and ship the newly created VMware container to oXya.
    2. Some servers cannot be virtualized. If this is the case, then the situation is a bit trickier, and requires a conversation with the customer about what to do with this server. There are a few solutions:
      1. Sometimes the application needs to be upgraded, in order to be compatible with VMware. This is seemingly the easiest solution, but it’s not always possible.
      2. Another seemingly easy solution is to physically move the server to the oXya datacenter. However, it’s often not as easy as it sounds. The downside to physically moving a server is that it takes time, both planning and the transfer itself, plus there are inherent risks involved. Timing wise, we will use a specialized moving company that does these things—take the server from the customer’s datacenter, put it in a truck, and move it to the oXya datacenter. Once we receive it at the oXya datacenter we will install it, and bring it back up. The risk is that whenever you physically move a server like that, some components may break, or the server will not start after the move, and that kind of things.
      3. If physically moving the server is not an option, then we need to get a bit creative. IT all depends on the specific application, the reason why it cannot be virtualized, and what the customer wants to do with that application. These are the type of discussions we hold with the customer, when we face the case of a server which is physical, and can’t be virtualized. When migrating a customer’s entire IT infrastructure to the oXya cloud, these servers are the most complicated to handle.



What has been your experience, regarding SAP landscape migrations?


Did you experience any difficulties and issues? Where exactly?


How sensitive to planned downtime is your organization?


What do you think about this entire topic?





Our last blog in the “Outsourcing SAP” series, to be published in 1-2 weeks, will be a Q&A, based on questions we receive from customers, on all the topics covered in this blog series. Send us questions about any aspect of “Outsourcing SAP”, either by posting them to the Comments below, or sending them directly to us, Sevag Mekhsian <>,  Dominik Herzig <> or Melchior du Boullay <>.




Sevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Group Company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of team of ten SAP professionals, at oXya’s service center in New Jersey.


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 Managing Director, 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 Group 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 Dominik Herzig, VP of Delivery for US & Canada at oXya, and Melchior du Boullay, Managing Director, Americas, at oXya.



In previous blogs of this series we covered various aspects of outsourcing your SAP environment. We started by asking should we outsource our SAP environment, and suggested a few directions to think about. Then, in the 2nd blog, we dealt with choosing the right partner that would manage our SAP environment, and listed various criteria and tips for choosing that partner. In the 3rd blog, we discussed various infrastructure and headcount considerations that each and every customer has, when considering whether and how to outsource their SAP.


The next two blogs of this series focus on the entire process of moving your datacenter to oXya.


When providing managed services for our customers’ SAP landscape, oXya has two high-level types of offerings:

  1. Run Management only: oXya provides only the managed services portion, while customer chooses to maintain responsibility for their hardware and for hosting SAP. In this case, oXya requires a quick and reliable link between oXya and the customer’s datacenter, to provide the support services. We covered that option in previous blogs in this “Outsourcing SAP” series.
  2. Full Cloud Delivered service: oXya takes full ownership and responsibility for the customer’s infrastructure and hosting, and the infrastructure is installed at one of oXya’s datacenters.


The next two blogs focus on the second option, and specifically on the full process of moving your datacenter and infrastructure to the oXya private cloud. These blogs are based on past experience with multiple North American customers, where we’ve migrated these customers’ full SAP landscape, plus all of their servers (including non-SAP servers), to the oXya cloud.

000045034298_high (Custom).jpg

The oXya migration process entails two main phases:

  1. Planning – covered in this blog
  2. Technical Operations – to be covered in next week’s blog


The project as a whole may seem a bit daunting, and like it’s going to take a lot of time, yet both impressions are untrue. Leveraging oXya’s processes and experience, our customers experience a well-defined and streamed process, which can be done relatively quickly.


How quickly?


For example, let’s take one of our customers, for which we’ve migrated their entire datacenter, consisting of ~100 servers (both SAP and non-SAP servers), to an oXya datacenter. The entire project, from the moment the contract was signed, and until the last server was moved and started running within the oXya datacenter, took 4 months (and BTW, there’s a difference in process between migrating SAP and non-SAP servers; we will cover these in next week’s blog).


While other vendors may try to sell you on a shorter cycle, or you may have business pressures which demand otherwise, remember that a timeframe of 4 months is considered extremely quick in the industry. Obviously, if the customer does not have extreme time constraints, then we can allow for more time and buffers within the process; still, if the customer requires that, oXya is able to make the entire transition very quickly.


Important First Steps


Timing is the first thing you think about, when starting such a project. Some things take a long time to order, so they need to be handled immediately upon signing the contract.


MPLS connection. Most customers prefer to have a fast and reliable internet connection (MPLS) between their location and the oXya datacenter; MPLS is a dedicated line, between these two locations. The challenge is that getting the MPLS connection in place takes (relatively) a lot of time, and so do other things that involve the ISP. When a customer asks an ISP for a date commitment, the ISP will usually commit to anything between 45 and 90 business days, meaning the minimum time to wait is more than 2 months, and it can sometimes also be more than 4 months (sometimes actual delivery is a bit sooner, but these are the timeframes that ISPs are willing to commit to). Hence, ordering an MPLS connection must be done as early as possible.

It’s important to understand that MPLS is not a must. oXya has customers who do not have MPLS; these customers access the data via VPN connection only. The difference between the two is that VPN goes over the public Internet, hence it is not as reliable as an MPLS connection.


Even if the customer ordered an MPLS connection and the ISP is slow in providing it, we can still perform the migration and provide the customer with a connection to their servers, using a VPN connection. It won’t be as reliable as an MPLS connection, but it will get the job done while waiting for the MPLS.


denver_140821_3561_hi (Custom).jpg

Hardware. For the hardware we have two options, with two different timeframes. Customers can either leverage oXya’s already-available Hitachi-based hardware (UCP) for shared / on-demand needs; or they can ask for other, specific hardware they would like their IT environment to run on:

  1. Hitachi UCP hardware: oXya had standardized on Hitachi hardware long before we were acquired by Hitachi, and we recommend customers to base their SAP on Hitachi UCP. Whether it is a dedicated infrastructure that you need, or share/on-demand infrastructure—and choosing between the two usually depends on size of landscape, needs, and additional criteria—oXya has a large pool of Hitachi UCP hardware, so we’re able to offer these options immediately.
  2. Other vendors hardware: oXya is open to accepting other types of hardware—per customer’s request—as we explained in detail in our previous blog. The challenge is it takes quite some time to get other vendors’ hardware. From our experience, and depending on the specific hardware vendor, we’re talking about a minimal timeframe of 4-6 weeks to get hardware from some vendors, and often significantly longer from others. Then, when we get the hardware, we need another couple of weeks to setup everything (to be explained later). Unfortunately, there is no working around the hardware. Until the other vendors’ hardware arrive, there is no technical action that can be performed; we do perform other preparation actions.


Two Approaches for a Datacenter Move


When you think about moving your infrastructure and your datacenter to a partner, there are two main options to perform this move:


The “Big Bang” move. You move all servers at once, from your datacenter to the oXya cloud (or to another datacenter). It is not easy to do, especially when you have many servers, because each server is unique. Using the “big bang” will likely result in lots of headaches, trying to troubleshoot various issues; furthermore, it will be challenging to pinpoint where the issues come from. For that reason, oXya typically do not recommend this approach. We prefer the phased approach.


The Phased Approach. We define groups of servers that work together, and build “migration groups”, where each migration group consists of servers to be migrated together. Each group is migrated separately, usually over a weekend, so the entire migration takes multiple weekends. In the case of the customer I mentioned earlier, for example, the 100 servers were divided into 5 migration groups. The phased approach requires some work from the customer on a functional level – we need to identify which servers work in conjunction with each other; at this early stage of the process, the customer still has a much better understanding than oXya on their servers. We work with the customer to help identify possible issues that may occur with respect to each group of server.

Timeline for the Planning Phase


The following steps are needed to prepare the hardware before we can begin moving servers from the customer to the oXya datacenter:

  • Install all the hardware components (not relevant if you use our Hitachi UCP hardware, only for other vendors)
  • Prepping the servers
  • Installing vOS (typically in a VMware environment you need to thread the images that you’re going to use for the other servers)
  • Network setup (typically VPN, unless MPLS has already been installed)


Above steps are the beginning of the Technical Operations phase, on which we’ll expand in our next blog. What’s important to understand regarding this stage is the following:

  • Above steps are relevant when customer wishes to use a non-Hitachi hardware
    • In such a case, the hardware preparation stage typically takes two weeks, from the time we get the hardware.
  • When using our available Hitachi UCP hardware, some of these steps are not relevant, hence the prep work is very fast, and server transfer can begin almost immediately.
  • At this stage, no data has yet been sent; these steps are just to get the hardware ready for actual transfer of data.


Knowledge Transfer & Planning


Another important part of the Planning Phase is around knowledge transfer and planning. This is where a joint team from the customer and oXya define the migration groups: find what each server does, how it works, what it communicates with, etc.


In addition, oXya will have some joint workshops with the customer (typically 5-6 workshops), to cover specific topics around the migration process:000038046066_high (Custom).jpg

  • Network & Security. Covers customer’s requirements, so we can implement in our datacenter. The Network & Security is sometimes split into two separate workshops, depending on the specific customer and their systems.
  • Servers Migration. Discuss what servers do, with what they communicate, and define the migration groups mentioned earlier.
  • Communications. Define how oXya team will work with the customer’s team. Covers how customer prefers to submit tickets: via email, or phone calls, or a ticketing tool (oXya’s or customer’s). We also address the escalation process, and everything around defining how we will work together.
  • Monitoring. Define how monitoring is going to work for every specific customer. Includes what needs to be monitored, what actions to perform if one of the checks fails (do we call someone or send an email), etc.
  • Global Governance. Overview of the project and follow-up every week, to make sure the project is on track.


The workshops are spread over the entire length of the project. Some workshops are more urgent than others; Servers Migration is one of the most urgent ones, and so is Security. On the other hand, the Communications and Monitoring workshops can be done later in the project, right before we move the servers.


All of these workshops are customized for each and every customer. We may create another workshop, should there be another subject that requires a deep dive with the customer and a thorough discussion. The overall goal of all these workshops, and of everything else that oXya does, is to make sure the project is a success.


It’s important to note that the same team who will manage your systems long-term, is the one that also drives and executes all the migration phases, including the workshops. This personal touch & dedicated team approach, in which oXya is unique at, ensures both consistency and proficiency in the details of your landscapes, throughout your relationship with oXya. Our approach also builds the relationship from day one, and ensures that your team knows the oXya support team who will handle your systems going forward, and vice versa. We are very proud of this personal touch & dedicated team approach, and it has been one of the cornerstones to our great success over the years.



What has been your experience, regarding SAP landscape migrations?


Did you experience any difficulties and issues? Where exactly?


Does your vendor also provide the same personal touch and dedicated team approach? Or each phase of the project is done by a different team, and each ticket you open is handled by different people?




Our next blog in the “Outsourcing SAP” series will cover the Technical Operations stage of moving your datacenter to oXya. Then, the blog after that will be a Q&A, based on questions we receive from customers, on all the topics covered in this blog series. Send us questions about any aspect of “Outsourcing SAP”, either by posting them to the Comments below, or sending them directly to us, Sevag Mekhsian <>,  Dominik Herzig <> or Melchior du Boullay <>.



Sevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Data Systems company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of ten SAP professionals, at oXya’s service center in New Jersey.


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 Managing Director, 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 Group 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.




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 Dominik Herzig, VP of Delivery for US & Canada at oXya. It is the second blog in the “Outsourcing SAP” series. Please ask us any questions you have on the subject of “Outsourcing SAP”, either by posting questions in the Comments below, or sending us an email to Melchior du Boullay <> or to Dominik Herzig <>.




Last week’s blog, Outsourcing SAP: Should We Outsource Our SAP Environment?, was the first in a series of blog posts that focus on the subject of “Outsourcing SAP”. That blog covered various questions and concerns that customers ask about and examine, when they face a decision of whether to manage their SAP environment in-house, or use a partner that will provide SAP managed services for them.

Outsourcing SAP 1 - screen shot.jpg


We discussed in length the security concern, that each and every customer considers when thinking of outsourcing. The conclusion: security threats are similar, whether your IT is in-house or you manage it through an external managed services partner. We also discussed the responsibility aspect, and showed that using an outsourcing partner for your SAP systems did not mean that you, the customer, didn’t have any responsibility left; you still needed to manage the relationship, review reports, and more.


Then, we had a discussion on various types of outsourcing partners, and brought various examples regarding what you should be careful from (multiple outsourcing partners handling the same SAP systems, something that would slow the resolution processes), and what you should prefer (a specialized SAP outsourcing partner, with responsibility over your entire SAP landscape).


We also mentioned additional considerations that were relevant to outsourcing your SAP systems, such as infrastructure and headcount. We will expand on these two considerations, and possibly a few more, in next week’s blog.


Today’s blog deals with HOW to choose a partner for your SAP environment, once you’ve decided that this is the route you prefer. In today’s blog we’ll suggest some important criteria regarding what you should look for when interviewing partners and comparing between them; this will ensure that you select the best possible partner for you, to which you will outsource your SAP environment.


So how do you select your SAP outsourcing partner? What are some important criteria to check?


Here are a few things you need to look for when searching for an outsourcing partners. These criteria are important for any situation, but are especially critical with regards to the SAP domain.


SAP-specific SLAs


When dealing with SAP outsourcing, you must have specific SLAs regarding SAP response time, server uptime, frequency of backup, and so forth. General SLAs are not enough; for example, everyone that provides outsourcing services will give you some type of a guarantee for server uptime, such as 99% or 99.9%—depending on what you ask for an are willing to pay (uptime, at the end of the day, is based on the infrastructure on which the service is offered, including redundancy and DR systems, and the same for other SLAs).


However, a general uptime is not enough in the case of SAP. What you should be looking for are SAP-specific SLAs for server uptime. For example, a server may be up and running, but its performance is slow to a level which SAP determines as “bad” (and which would make the users’ experience miserable). SAP has clear guidelines regarding performance, running backups properly, and so forth – all that should be in the contract with your outsourcer.


At oXya, we typically guarantee our customer an average response time of under 1 second, across all dialog steps in the system (dialog steps are generated when a user interacts with SAP through the GUI). This is a measure of the system’s responsiveness to a user’s actions. SAP users will be frustrated if they click on something, and it takes the system 5 seconds to respond. The rule of thumb for SAP is that any response time below 1 second is good, and anything above 1 second is bad.


000038368138_high (Custom).jpg

Furthermore, on top of the general system performance SLA, we also have an additional SLA on the top 10 transactions, meaning the 10 most important transactions for the customer’s business. These transactions are defined by the customer at the beginning of the contract, and can be changed if the customer’s behavior changes.


Once these “top 10 transactions” are defined, their performance is being monitored and reviewed every month; we commit to the average performance of these transactions, that are highly important to the customer. Remember that we already provide an SLA of sub-one-second average across the entire SAP environment, as we mentioned above. By applying the same sub-one-second average performance to these 10 most important transactions to the customer, we actually commit to providing an even better response time and performance for these specific transactions.


Backups is another highly important SAP SLA. There’s a specific daily backup for our customers, and if we miss a backup we get penalized for it. Furthermore, our contracts are built in a way that the penalties for us increase. For example, if we missed a daily backup then the penalty is X, but if we missed 3 daily backups in a row, then the penalty increases exponentially. This ensures the customer that we will do anything, above and beyond, to meet the SLAs, provide a great service, and avoid the penalties.


As a general recommendation, it’s always good to have an SLA with an associated penalty to the outsourcer for these type of things. It will guarantee that you have some recourse if something goes wrong, plus the outsourcer will do everything possible to meet those SLAs and avoid the penalties. If there are no penalties associated with the SLAs, then the contract is not as constraining for the outsourcer, which is why you really want to have these penalties built into the contract. At oXya, we are so certain of the service level we provide our customers, that we suggest these penalties ourselves, sometimes to customers amazement.


And just for a full disclaimer, this penalty system unfortunately doesn’t work the other way around; meaning the outsourcer does not get a bonus for outstanding service (or at least we don’t have that in oXya contracts).




Another SAP specific thing that is of high importance is the reporting prepared for you by the outsourcing partner. What kind of information do you get from your SAP outsourcer on a daily, monthly, and yearly basis?



We recommend you ask the outsourcer for sample, standard reports that are being delivered to the customer, and ask about the frequency of these reports. At oXya, we have:

  • Daily reports that are sent in the morning and summarize the SAP system’s activity on the previous day; any incident, syslog, alert or error message that happened on the previous day would appear on that report. Also, any escalation, meaning any call to the administrator during off-hours, will be there. It’s really a status on the health of the system, on a daily basis.
  • Monthly report, which is more high-level. This report summarizes all the SLAs that we discussed previously, and shows if any of them were out of sync, compared to what we were supposed to provide. This report also includes capacity planning, meaning size of the database, growth of the database, how much space is left on the disks, whether we need to increase the size of the disk, and that type of info.


You want to make sure you get all the information you need, to feel comfortable with your SAP outsourcer. This is why at oXya, we build these daily and monthly reports together with the customer; we can add any metric the customer is asking for, to make the customer feel comfortable with our service.


The delivery model of your ‘standard’ SAP outsourcing partner


Another critical component for customers, and something you should examine in detail, is the delivery model of the SAP outsourcer you choose. You must be comfortable with the delivery model you’ll receive, and it’s not something trivial.


How does it usually work? Everyone working in IT have had the case where we needed to call for a specific issue, say a hardware issue. You call the number of a call center, and get someone who answers that call (that person can be located in Americas, EMEA or in the Far East). That person doesn’t really understand about the issue, it’s not her role to resolve it. She answers the call, writes down the issue, gives you a ticket number, and promises that someone will call you back. Then, you sit and wait for someone to call you back…


And you wait… and wait…


Sometimes, they even call you back. But quite often, no one calls back. And as you know from your experience, if they don’t call you back soon enough, you need to call them again, and ‘remind’ them of your issue, and that you need it resolved.


Standard Delivery Model.jpgHere’s what happens in the background with these standard outsourcers, and you can also see a graphical representation on the right-hand side of the slide:

  • You call the service number you have (a call center), and open a ticket with the issue you have.
  • Once you opened a ticket with the call center, the ticket goes to one team, that specializes in a specific area. That team determines whether it’s their issue or not. In the SAP world, let’s say you created a ticket because you have an issue with SAPyour Production is running slowly. That ticket gets sent to the SAP Basis team.
  • When that first team gets the ticket, they examine the issue. If it’s an SAP issue then they may fix it. However, quite often the SAP Basis team may say (internally, you don’t know about it!) “you know what, this doesn’t look like it’s our issue, we believe it’s a database issue”, and so the ticket gets forwarded to the database team.
  • Next, the database team looks at the ticket. Again, it may be a database issue, in which case they’ll fix it; but they may determine that it doesn’t look like a database issue, they think it’s a hardware issue, so they forward the ticket to the hardware team.
  • Now it’s the hardware team’s turn to take a look at the issue, and decide if they can fix it, or move it forward to the next team in line.


And so your ticket circles, between various teams (SAP, database, hardware, operating system, and more). Often, the ticket will move between teams located in different countries, and even different time zones.


The good news: at the end, the issue does get resolved.


The bad news (for you, the customer): every time your ticket hops between teams, you lose precious resolution time. Of course, there is no direct contact between you (the customer) and these teams, these are all internal hops. Unfortunately for customers, this is how things work among many of the SAP outsourcers (the huge outsourcers employ this model—the big and famous names that you know very well).


oXya unique delivery model: an extension of your IT team


The previous section described how service usually gets delivered in our industry. The way oXya works is completely different. We are unique, since we’re actually working as a real extension of your IT team.


First, we’re working on-shore or near-shore, as opposed to many other SAP outsourcers who provide off-shore services. When you call from the US to get support, you will speak with people located in either our Jersey City or our Denver support centers. For Canada, you will speak with people in our Montreal support center.


Not only is oXya working on-shore, but you have direct access to the people actually working on your systems. When you call, you will speak with the team leader, who leads the team working on your systems; that leader is an SAP expert, with many years of experience. You will not speak with a call center, simply because we don’t have such a thing. You always call directly to the team that is doing the work, and that team will identify the issue and solve it.


The way oXya is structured to provide service is the following. We have teams of 8-12 people in each team, and team members are located in the same support center, sitting together and collaborating continuously. Each such team is dedicated to a specific pool of customers. Each team only handles these specific customers, and are entirely dedicated to these customers. Furthermore, each team already has all the necessary skills and knowledge within the team—SAP Basis, databases, operating systems, hardware, networking, and more.


When a customer calls, the customer always calls and speaks with the same people on that team. Very quickly, the customer knows not only the name of the team leader, but also the names of all members of the oXya team that handle that customer; furthermore, all members of the oXya team know the people on the customer’s side.


Even more important, the oXya team will very quickly know everything about the various systems that the customer has, the criticality of the various systems, and all the complexities behind the various systems. This knowledge, and the intimate understanding of the customer’s systems, help to significantly reduce the time to resolution for each issue, and also help the team to proactively perform various activities that prevent potential issues.


This is why at oXya, we proudly say that we are always as close as possible to the customer, and that we really do work as an extension of the customer’s internal team. This is what we’ve been doing for many years, and for hundreds of customers.


oXya Delivery Model.jpg

Now let’s take the same example we brought in the previous section (with all the bullets), and assume that the exact same issue happens to an oXya customer. Let’s say that you, the customer, have an SAP issue, and you call oXya (see a graphical representation on the left side of the slide):

  • When you call oXya, you call directly to the team that you know, speak with someone whom you already know (let’s say John), and you tell John that you have an issue with the Production environment, and that it is running slow. Without further information, John already knows exactly which environment you refer to, and what is the criticality of that system. John also knows things like the exact built of this environment, in order to start working on a resolution. John is able to immediately connect to the system—while you (the customer) are still on the phone—in order to experience/replicate the issue by himself (slowness, in this example).
  • Then, the entire team handles the issue together, simultaneously checking it from all possible angles (SAP, database, OS, hardware, etc.), significantly reducing the time to resolution, compared to the 'standard' delivery model described in the previous section.


It’s really important, when you decide which outsourcer you want, to keep in mind that for some of the BIG and famous outsourcers out there, you don’t really know who will answer your phone calls, and what type of service you’ll get.


The experience that we’ve heard from numerous customers, who transferred to oXya from other BIG and famous outsourcers, is something like the following:

  • You call the call center, get someone offshore who sometimes understands what you want (and sometimes they don’t understand…); also, sometimes you will actually manage to understand what they are telling you; you may or may not get along with that person on the phone (language issues is a recurring complaint about some competitors).
  • Then, the person who answers the call may or may not know about your specific systems (usually not), and so begins the 'standard' support cycle we described in the previous section.


We are very proud of our delivery model, and see it as a key differentiator in providing service to our customers. Furthermore, we believe that this is something you should pay careful attention to when selecting an outsourcer, as this is one of the most critical things aspects of the service, and will affect the entire service levels you get, on a daily basis.




Our next blog in the “Outsourcing SAP” series will discuss the questions of infrastructure & headcount – two subjects that all customers ponder when considering outsourcing their SAP systems.


And please remember to send us your questions about any aspect of “Outsourcing SAP”, and we will answer them in one of the upcoming blogs in this series. Please post your questions to the Comments below, or send them directly to us, Melchior du Boullay <> or Dominik Herzig <>.




oXya_HDS_logo_300dpi (Custom) (2).pngMelchior 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.


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.


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.

As more customers are deploying SAP HANA, they are also moving to virtualizing their SAP HANA environment.   Hitachi and  VMware recently published two joint papers around virtualizing your SAP HANA environment.

One of these is a Infosys Case Study, a global SAP service provider. Early in 2015 Infosys deployed the world’s largest single instance of SAP Business Suite on HANA (SoH) with over 150,000 users running on Hitachi’s converged platform, UCP.  Since then Infosys has decided to deploy VMware vSphere 5.5 on Hitachi UCP at their Center of Excellence (CoE).  If you want to hear more about  the Infosys story, check them at SAPPHIRE 2016 this year, on May 18 at 2pm.

Here is a little synopsis of the challenges they faced and the benefits they have gained by virtualizing the SAP HANA environment.


At their CoE, Infosys demonstrates how SAP systems can improve their customers’ business efficiency. Infosys was challenged with meeting the growing demand for demos from its customer base. They had to accelerate the deployment time for SAP apps running SAP HANA instances. In order to tackle this problem, they first needed to upgrade their IT infrastructure. But they also wanted hardware that could be virtualized so they could maximize resource utilization. They decided to deploy with VMware running on Hitachi Unified Compute Platform. VMware vSphere was the only product certified by SAP to deliver virtualization featuring capabilities such as dynamic scalability, rapid provisioning through cloning and template based deployment.  They also deployed VMware vMotion and the Hitachi UCP was able to use these capabilities to migrate live virtual machines within clusters. “Selecting the Hitachi UCP converged platform to run the virtualization layer that would deliver SAP HANA enables us to take advantage of a ‘common building block’ approach’,” explained Mr Sharad Pandey, Senior Consultant, Infosys. “This would enable us to grow from 512 GB appliances to 6TB appliances in the scale up model and up to 32 TB on the scale out model just by adding Hitachi enterprise grade infrastructure components into the same stack, and help us maximize the returns our investments.” Additionally Hitachi created SAP HANA VM templates to further streamline the SAP HANA deployment. 


The benefits Infosys realized as a result of this deployment were:


1) New SAP HANA virtual machines deployed in few minutes using Hitachi’s SAP HANA VM templates

2) Reduction in the total cost of delivery by 85%

3) Cut SAP HANA infrastructure costs by 2.5 times with consolidation offered by Hitachi UCP

4) Reduction in power requirements by 96%


Learn more:

Infosys Case Study

VMware vSphere and Hitachi UCP White Paper

Every SAP professional knows about SAP TechEd. It is a huge event that encompasses many sessions, covering both present and upcoming technologies. My colleague, Melchior, already wrote a blog summarizing his experiences from TechEd and recommending a few sessions; in this blog, I’d like to recommend a few additional great sessions that I attended. I’m sure these would be interesting and helpful for those who did not attend SAP TechEd, as well as for those who attended and want a good refresh. At oXya, we use these recorded sessions for “training” and for introducing new SAP aspects to our teams. We distribute a list of recommended sessions to all oXya experts who did not attend TechEd in person.


The following is a short list of sessions I loved in TechEd Vegas. For each session I give a short explanation on what was interesting and a link so you can see the recording. The first two videos I recommend watching are the main keynotes that cover the SAP strategy; they show you what could possibly be the future of your IT. Then, there are four additional speeches that I recommend: a session on user interface, one on HANA direction as well as one on S/4HANA, and a session on Internet of Things.



SAP Executive Keynote: Steve Lucas, Las Vegas 2015


The first SAP keynote, given by Steve Lucas, Global President, SAP Platform Solutions Group, was not very techy. The keynote focused on how SAP was helping businesses to solve some real life challenges, using amazing tools; it showed how companies could use big data and other technologies to be more productive. They demonstrated a few things using the Amazon Alexa tool (it’s the Amazon Assistant, like SIRI is to Apple devices). Steve Lucas also spoke about SAP VORA, an analytics tool for big data, helping to analyze both structured and unstructured data. This was a “big picture” keynote, with lots of examples on how SAP could help your company, using some new technologies that would come, and how you would be able to leverage them.



SAP Executive Keynote: Bernd Leukert, Las Vegas 2015


The second SAP keynote was given by Bernd Leukert, a member of the Executive Board and the Global Managing Board of SAP SE. This session covered the SAP HANA platform and various tools around HANA, and how these integrate into your IT platform. One of the interesting ideas in this session was the transition from a B2C model (Business to Customers) into a C2B model (Customers to Business). The meaning was that customers provided lots of valuable information, big data, to the business (via social networks, surveys and more); the business—using various digital platforms—needed to digest all of that information and provide the right answers to customers.


Leukert showed all the IT you could build on the cloud, using HANA and HYBRIS. This was a general session about the HANA Cloud Platform, all the tools powered by HANA, and the architecture that SAP developed to help customers become more digital. The keynote showed a big picture of what could be achieved when using the SAP HANA Cloud Platform.



UX111: SAP Fiori Apps: An Overview


Those of you who already read my previous blog about SAP Fiori know that I’m a big fan of the new SAP user interface (UI), and don’t like very much the older SAP GUI. The new SAP UI has been a hot topic for the last couple of years; this session about SAP Fiori Apps provided a high-level overview on all the developments in this area. It showed how you could implement the new SAP UI in your company, from developing to installing to end-user extensions, and more. Several tools were shown in this session, like the SAP Fiori Library (website provided by SAP, where you could see how your application would look using Fiori), and also the SAP Fiori Demo Platform (demo platform for selected apps; you could use it to see if it fitted with your business and your applications). This session also provided some previews on future looking developments, like Fiori on smart watches, and Fiori together with Internet of Things.


Many customers have questions about the new UI. This session provides a good introduction for any customer considering moving now to the new SAP UI. The session helps understand what SAP Fiori is all about and how it will help the organization, including demonstrations of current technologies and future ones. It’s one of the best sessions I’ve seen at TechEd, for both Basis developers and for business people on the IT side.



TEC103: SAP S/4HANA Overview, Strategy, and Road Map


This is one of various S/4HANA sessions you could see during this SAP TechEd event. S/4HANA was presented as the future of SAP applications, similar to the role that business suite SAP R/3 had played in the ‘90s. This revolution starts now, and is based on IT simplification, leveraging the HANA platform and Fiori.


This specific session focused on S/4HANA Overview, Strategy and Roadmap, and provided the “big picture” on SAP S/4HANA and the new tools around it, as well as the future of S/4HANA. This presentation was a great introduction to Simple Finance, the first component of S/4HANA, and all the way to the latest component released, Simple Logistic. It showed which directions SAP was thinking of for the future, and how these technologies could help customers in simplifying their IT. This session also showed how it would integrate supply chain and CRM on future versions of this tool. It enabled the listeners to “see” the future, and envision how your company could implement S/4HANA. Related to that subject, I would also recommend to read Mel’s blog about considerations before migrating to SAP HANA, as it’s a great blog with valuable information.



TEC105: SAP HANA Road Map


Another session I would recommend watching is the one covering SAP HANA Roadmap. HANA has been around for the last 5-6 years and was the main topic of SAP during that time. HANA is also one of the most drastic changes SAP had ever made to their platform, and it is the foundation for all the new projects that are happening at SAP right now, to help your company become more digital (like S/4, VORA, and more). This session was interesting because of its structure; it covered subjects for various types of professions—developers, Basis admins, data architects, UX experts and more—emphasizing what was present, and what would come in the future of HANA for all these departments. It also focused on many Basis tools and tools for developers, regarding how to handle SAP HANA, how to use it and how to leverage it, both at present and in the future (near future and further away). This session also covered Multi-Tenancy, which was pretty new on HANA and interesting to hear about.



The Internet of Things and Its Impact on Corporate IT

network-782707_640 (Custom) (2).pngThe last session I recommend watching covers Internet of Things and Its Impact on Corporate IT. Internet of Things (IoT) was one of the hottest topics at SAP TechEd 2015. This session was very impactful as it showed how IoT could reinvent businesses in helping them build new offerings, help their customers, and make a tremendous impact. One of the most surprising things for me was a piece of data brought in this presentation, according to which the impact of IoT would reach more than $10 trillion within the next 10 years. Hence, when you are planning for the future of your company, then IoT is not something you can ignore.


The session brought many real life examples, like capturing data during driving and then analyzing it using SAP HANA; or an interesting project done at the city of Hamburg in Germany, collecting data from trucks and other vehicles used, analyzing that data, and managing to cut down 5,000 hours of trucks’ driving, which obviously saved a lot of money and also contributed to the environment. It was an awesome session that made me realize that all of these IoT gadgets were not just geeky things, but rather the new way that IT could help your business.



The above sessions are just a small sample of all the content and recorded sessions from TechEd, that you can review online. You can find all the replays at:



Mickael Cabreiro is a Senior SAP Basis Consultant, currently based in oXya’s Montreal, Canada office. Mickael joined oXya in 2008, and has consulted to customers across Europe and Americas, capitalizing on his multilingual proficiency. oXya was acquired by Hitachi Data Systems in early 2015.


Hitachi is a proud Gold Sponsor for SAP FKOM 2016 from Jan 26-29 in Las Vegas.


Here is a line up of our powerful SAP solutions we will be discussing at the event:


Enterprise Real-time Visibility and Analysis
A Hitachi SAP HANA and Business Objects Solution. Ties together transactions, operational data, and financial planning in real-time.


Industry Cloud for SAP Solutions
Hitachi Managed Cloud Industry Solution. Subscription based, supporting Process, Discrete, Wholesale and Consumer industry verticals.


Telco Churn – Real-time Predictive Analytics Solution

Hitachi’s end-to-end Predictive Analytics Telco Churn solution - on premise or in the cloud.


SAP HANA Analytics Platform
Optimizing Big Data Analytics using SAP® S/4HANA with SAP HANA® Vora and Hadoop


SAP and SAP HANA Application Hosting and Remote Services
Hitachi Cloud-based SAP and SAP HANA hosting services including analytics solutions


Zero Zero SAP Project Financing
0% Financing. 0 Payments till Go-Live or for the first 6 Months* Payment terms aligned with project milestones. All hardware, services, and software/maintenance bundled.


Compute and Storage infrastructure solutions for SAP and SAP HANA (Appliance and TDI)

Hitachi offers enterprise-class business and analytic applications, database, compute and storage for SAP that deliver future-proof scalability, five nines availability and unmatched agility.

SAP is one of the most mission critical applications for any organization, because it runs the entire business. An IDC study, published in 2015, determined that for a Fortune 1000 company, an unplanned downtime of a mission critical application will cost between $500,000 to $1,000,000 per hour of downtime. In fact, I can think of many organizations for which the damage resulting from unplanned SAP downtime will be significantly higher than $1 million per hour, because these businesses rely on SAP for conducting their ongoing operations, including sales.


I recently had a discussion with a colleague, regarding the main causes for unplanned downtime to the SAP environment, and how these can be prevented. That discussion led to writing the blog you’re now reading. The content and advise in this blog are based not only on my own 8 years of experience as an SAP expert and team leader; this blog is based on the accumulative experience of nearly 600 SAP experts working at oXya, a Hitachi Data Systems company, specializing in managed services for SAP customers. oXya has been managing SAP environments for enterprise customer for the past 18 years; we are currently managing SAP environments for more than 260 enterprises around the world, with more than 250,000 SAP users.


I’ll begin with listing some of the most common causes that lead to a crash of SAP, and then move to some proactive steps that can be taken, in order to avoid these crashes.


What are the main causes for downtime of an SAP environment?


Outages may occur in the SAP Production environment due to various causes. The following list describes the most common causes we’ve seen over the years for unplanned downtime of SAP environments:oXya14 (Custom).jpg


Lack of Monitoring. This is by far the leading cause for outages of the SAP Production environment. For example, we have customers that, prior to working with oXya, never used to monitor their servers, not even the Production servers. By “monitoring the servers” I mean that disk drives were not being monitored, so that when drives were running out of space and there was no storage space left on them, no one was aware of that; if we’re talking about a hard drive that is crucial for the database operations, and the database could not write to the hard drive, then that would bring down the entire Production instance, causing users to not be able to do their work.


Hardware issues. When there is a device failure on the system’s server, whether this is a hard drive failure, a motherboard issue, or any other type of general hardware issues, and there’s also a lack of redundancy in place – this can bring down the Production instance.


Network related issues. Network issues can occur, for various reasons. This can be hardware-related, such as a case in which one of the firewalls or switches has an issue, but it doesn’t have to be hardware related. What happens when a network issue occurs is that the users are blocked from being able to access the SAP system. Hence, even though the SAP system itself is up and functions properly, this type of issue is considered an outage, because the business is not able to connect with the SAP systems, and users are unable to do their work. In many cases, network issues occur due to lack of redundancy, meaning systems that are not built with sufficient redundancy in place. If there is a single point of failure, somewhere, and that single point does fail, then it will cause an outage or outage-like consequences. The key here is to identify and minimize single points of failure, by as much as possible.


Performance related issues. Performance issues are is not necessarily an outage, yet it can impact the users to a point where it makes the SAP system unusable. For example, during end of month activities on an SAP Production system, there are critical tasks that must be completed within a certain timeframe. If there is a performance issue, such as database performance or something similar, the business is unable to complete the work within the allocated timeframe. This is considered an outage to some extent, because the system is not working as intended; the system does not provide what it needs to, even though it is still working and didn’t crash.


Insufficient proactivity or reactivity to the system. From a pure technical perspective, and this is also tied to monitoring—if there is a critical issue and this issue is not resolved, then down the line, if continues to be neglected, there’s a high chance that it will come back and bite your behind. This is one of the sure ways to guarantee unplanned downtime. Let’s begin with an example for what I call ‘lack of reactivity’. For example, assume that we observe a disk that is on its way to getting full. It still has some space so we’re not taking any steps now. Then, it indeed gets full and causes a system crash. This type of crash can fall under the ‘lack of monitoring’ category, but it’s also the lack of taking the necessary steps when witnessing possible things that can cause issues. This is lack of reactivity.


By lack of proactivity, I mean making sure that alarms are not being triggered on the system. For example, in SAP there are health check jobs that need to run – clean some tables, and so on. If these health checks and house cleaning jobs are not being performed, it can lead to issues that cause downtime. The proactivity here means that at oXya, we have people who are handling customers’ systems on a daily basis, making sure that the systems are in healthy state. If this piece of proactive treatment is missing on your Production environment, it can certainly cause issues and even downtime at some point.


Testing. We view testing as major cause for downtime, and it has both technical and business aspects. From a technical aspect, patches and updates (software, firmware) need to be applied, in order to photo_58702_20151221 (Custom).jpgkeep the system up to date. If a system is out of date (patch wise), there can be a software failure that causes the system to go offline. Lack of testing, when applying a patch to the Production system, can cause issues. For example, let’s say that there’s a Windows patch that needs to be applied to the server, because it’s a critical software patch that fixes a known bug. Let’s further assume that this bug is known for its ability to crash the SAP system. The correct way to perform testing is to apply this patch to your Dev environment and test it for a week, to make sure that everything is working fine. Then, you install the patch on your Quality environment, do another week of testing to make sure there are no issues. Only then, you install the patch on your Production environment.


We’ve seen cases where this testing routine was not performed, and the patch was applied simultaneously to all three systems (Dev, QA, Production). If this is done, you’re at risk of discovering there’s a potential issue with SAP and this patch—for whatever reason the patch causes an issue with the SAP application, which can lead to an outage.


The key is to perform rigorous testing whenever a change is introduced to the SAP environment, whether it’s a patch, a functionality that is being implemented by the business, etc. Such changes need to be gradually applied and thoroughly tested, with large-enough time window, so that any issue is caught before the change hits Production.


Updates & patches. Keeping the system up to date should be a top priority for any SAP team; unfortunately, we see many systems that are not kept up to date, and this is especially the case with Production systems. We do ‘understand’ the reasoning for systems that are not up to date; downtime, especially planned downtime where you have to bring a system down to apply a patch, is not something that can be easily provided by the customer/business. Hence, it’s always a challenge to keep the systems up to date, whether it’s an operating system patch, a firmware update, or any other type of patching that needs to be applied.


If the entire system is not kept up to date, there are potential bugs or issues that can occur, and can bring down the system. We’ve seen that in the past – there was a bug in the Windows environment that crashed systems; this occurred because a specific patch, that was released two years earlier, was never applied to the systems that crashed. If patching and updating of the environment is neglected, this can (and most likely – will) eventually cause downtime to your SAP environment.


Unplanned Downtime & Human Error


The majority of unplanned downtime events can be tied to human error. Whether it is the result of lack of planning, lack of testing, lack of reactivity or proactivity actions, and so on. Of course, downtime can also occur without human errors, like for example if there is a circuit outage at the datacenter, and the entire datacenter goes offline. Such a case would usually be considered as force majeure; and still, one can say that even a circuit outage can be considered a human error, because something wasn’t tested, and/or something wasn’t done right, and/or there should be a disaster recovery (DR) site so the entire system (spread across more than one site) never fully crashes, and so on. However, at the end of the day, in such cases it’s difficult to put the blame on human error, because there are a lot of teams and many elements in play.


Some items are usually attributed to human errors and some aren’t. The items that are usually attributed to human error are:


Performance issues. Let’s look at an Oracle database, for example. The database has tables, and the tables have indexes. If an index is in ‘bad shape’, and hasn’t been rebuilt (this was not caught by the database administrators), then this can lead to performance issues. Furthermore, it can lead to a scenario where it is the end of the month, and the business cannot run specific actions on time. This causes headaches and ‘downtime’ for the users. If the administration team, through their proactivity and monitoring tools, found that this index needed to be repaired and caught that before month-end, then this downtime can be avoided.


denver_140821_3258_hi (Custom).jpg

Patching (or lack of) issues. If a crash took place, it resulted from a bug, and that bug was known and there was a patch that was not installed, then that also falls into the human error category. Such patches should be installed, after scheduling with the customer.


Lack of DR and/or single points of failure. Many Production systems have disaster recovery and replication in place, especially for enterprise customers, so that even if the main Production system goes offline, it is brought up on the replicated DR site pretty quickly. Still, there are many smaller companies that do not have a DR site. Such companies often host their SAP onsite, at their own offices, sometimes in a small onsite datacenter. Such installations typically have many single points of failure, such as not having a generator and relying on a single source of electricity; not having DR and replication for your system; having just one piece of network device that failed; and so on.


If we take an overall, honest look at human error, we have to admit that mistakes do happen. For example, administrators have above-average access to the system, so they can accidentally delete files, shut down systems, and so on. It’s not unheard of that an administrator had deleted a critical piece of software, which was a must for the system to be up and running. So, human errors along those lines can and do cause outages.


The constant struggle is to have some sort of a system in place, that minimizes such human errors by as much as possible. This involves having second checks in place. I can tell you how we operate at oXya – if there’s a critical action that’s being performed to a Production system over the weekend, for example, we don’t let a single person perform that action. We have a minimum of two experts, and sometimes three, working on the same item. The purpose of having multiple people working together, on the same item, is to double check everything and go over the actions that any specific person would take, in order to eliminate human mistakes by as much as possible.


Through these types of check systems, we can eliminate or at least significantly reduce the types of human errors that occur. At oXya, there’s a second person assigned to checking all the work being done, especially when dealing with the customer’s Production environment.


How can unplanned downtime events be minimized or omitted?


I’ve already provided some advice earlier, like always having more than one person when applying changes to the Production system; or keeping the systems up to date.


Taking the ten thousand foot view – the key to minimizing downtime is proactivity. All of the monitoring and automated checks that exist on all systems (or for most) is great, but it’s not enough. You need something extra on top of those automated systems, and that something extra comes from the “human touch”. Through proactivity, and the experience that oXya has in handling these sophisticated landscapes, we provide this extra layer of security for our customers.oXya1 (Custom).jpg


What do I mean by “human touch”?


At oXya, of course we have all of the possible monitoring on the Production landscapes, including automated monitoring. However, we’re not settling with these alone. The “human touch” aspect is that on a daily basis, we have people logging into these systems, performing manual daily checks, and making sure that the systems are up, running, and in good condition. We believe that in addition to the automated checks, that are very thorough, what really ensures that everything is being caught is having human interaction with the systems, on a daily basis; and if something is being caught, then it is handled immediately by SAP experts.


Furthermore, testing is very important, especially with patches, to prevent unplanned outages. Make sure that both the hardware (firmware) and software are up to date, and that these updates are done through rigorous testing. If there’s a database patch that needs to be applied, for example, we would coordinate that very carefully with the business; if there is a sandbox environment then we’ll do that first, to have less impact on the business.


To summarize, I see four key elements to omitting unplanned downtime: patching, monitoring, reactivity to issues, and lots of proactivity. These are the key elements that oXya has been following over the years, and that have led to having lots of success with our customers.




Sevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Data Systems company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of team of ten SAP professionals, at oXya’s service center in New Jersey.

SAP TechEd 2015 in Las Vegas, held a couple of weeks ago, was a great show and successful as usual, with many thousands of attendees and hundreds of sessions. TechEd is the place to meet colleagues, hear news and upcoming developments from SAP, and get training on new products. TechEd is like getting an energy shot about everything-SAP, and leave it pumped up with excitement.


oXya has had great presence at TechEd, with a large team and successful booth. We had visitors from more than 1000 unique companies visiting our booth. In addition, I attended a few excellent sessions (see below), met with and had great discussions with a few SAP Mentors, and also had good discussions with SAP executives. In this blog post, I’m summarizing the highlights and key trainings from TechEd. We’ll expand on some of these in the coming weeks.


Key Trends in SAP TechEd Vegas


The main trend in TechEd was around HANA. No surprise there, and it’s not the first year that TechEd focuses on HANA. The difference from previous years is that HANA has become an increasingly central component of the SAP market, so naturally also a focus of TechEd. The event featured multiple “HANA Heroes”, companies that have migrated to or implemented HANA, with the help of SAP and companies such as oXya. See this short interview with Frederic de Belloy, President and co-founder of oXya, in which he shares some insights Frederic.pngabout customers’ adoption of HANA, and what led oXya’s decision to be acquired by HDS, earlier this year.


We featured one such customer Celio, the leading global men fashion retailer, in a webinar that we held a few weeks ago. For those of you who missed the webinar, here is a link to watch the full webinar, and also a link to the specific presentation from Celio’s CIO, Laurent Rousset, including their HANA project.


Another major focus at TechEd was around Internet of Things (IoT), and what SAP is trying to promote on this subject. The subject of IoT is related to something relatively new for SAP, which is analytics. SAP recently announced a new and impressive version of its SAP Predictive Analytics software, which I recommend everyone take a look at, to see what SAP can do with big data, data mining, and analytics. Hitachi Data Systems, our parent company, is also doing a lot around IoT and analytics – see this short interview with Dr. Greg Smith from HDS, which we recorded at TechEd, in which he explains what we do in this area.


As analytics was taking center stage due to SAP’s investments in this area, SAP also introduced three new products on Hybris. These are micro products for specific customer usages, for example a marketing tool that enables marketers to create highly personalized content, based on customer data. There is an entire, thriving market of small tools Greg_and_Parisa.pngconnected to Hybris, and this trend is expected to grow even further next year, as it is a key driver to leveraging SAP’s CRM.


SAP’s CRM tool hasn’t been great until now, and they’ve had lots of competition from excellent and strong tools, such as Microsoft’s CRM and SalesForce. SAP is trying to bring some new tools and services to the market, to better compete with the other CRM providers. Hybris and the marketplace around it are a major step in this direction. The Hybris marketplace includes a lot of micro products from SAP and various partners, and these services are consumed on a pay-per-use model (“as a service”).


Interesting Sessions at TechEd Vegas


As already mentioned above, we attended many great sessions at TechEd, and I would like to highlight three sessions that I round most interesting. This is also a good place to say “Thank You!” to SAP for a great event and for recording most of these sessions and providing them online – in the text below you’ll find links to video recordings of the first two of these three sessions, and at the bottom of the blog I'm attaching PDF versions of all three presentations (if anyone has a link to the third video recording, please let me know and I’ll add it as well).


The first session was TEC114, “Transition Paths to SAP S/4HANA”. I will expand on this session below, as this subject is something we’re discussing on a daily basis with our customers. For those of you who haven’t seen it, here’s a link to the video recording of the TEC114 session, as well as to the attached PDF version of the presentation.


The second session was SEC203, “Hacking and Protecting RFC Communication”, which focused on a highly sensitive security issue, a subject which is very important for customers, and also something that is easy to solve. The hacking demonstrations in this session focused for getting into SAP using the “ALEREMOTE” user, and were very interesting. The hackers demonstrated how they were able to change a system user, which is usually safe from external users, into a Dialog user with special programs, and get into the system with remote login. The session also had a discussion on how to protect RFC connections, and recommended reports that should be run in order to find out which RFCs are never used at all by users, and can therefore be disabled. In addition, it recommended reports to run authorization checks on RFCs, to find out which authorizations are most needed. The goal of all this is to avoid giving ALEREMOTE the unsecure role of SAP_ALL. Here’s a link to the video recording of the SEC203 session, and also attached is the presentation in PDF format.


The third session was BA262, “Monitor the Health of Your SAP BusinessObjects Business Intelligence Suite”. This session focused on a new BI support tool, to troubleshoot BO issues. This tool is a must have for all BO platforms: no real setup, transparent usage, and can be used directly on your production systems. This tool can generate reports with very interesting content (whereas EWA for BO is hard to configure, and provides too little info). In short, this new tool provides high value for BusinessObjects customers, and I highly recommend taking a look at the attached presentation, in PDF format, of this session (and a quick tip: "high" trace server level should never be let to 'on' on prod, it just kills performance).


Upgrade paths to S/4HANA


As already mentioned, there was a lot of focus at TechEd around S/4HANA, with many sessions and discussions around it. S/4HANA remains a grand statement from SAP, with some answers that SAP still needs to provide to the market. First, it is a new solution that still needs multiple components developed, probably in the coming year, for it to be a viable option for customers.


Furthermore, the shift from a current SAP version to S/4HANA is really opaque at this stage, and is unclear for customers. Customers are asking us many questions around how to migrate from their current SAP to S/4HANA, and SAP is not providing clear guidance and migration paths. Each time that SAP has come up with a new version, including with HANA, they have also offered very clear, straightforward guidance on how to perform the migration. However, with regards to S/4HANA, it’s the first time that I can remember in which SAP releases a product, and there is very little information about the migration process.


For this reason, the TEC114 session, on “Transition Paths to SAP S/4HANA” was very interesting, since it started answering some questions, though not all. What we learned in this session was about the 3 transition scenarios to S/4HANA, which you can see on slide 11 from the full presentation, on the right.



The first scenario is a New Implementation. In this scenario, you are not reusing your ECC or R/3 instances, you just “burn” your old SAP environment, flip to a new page, and start with an entirely new SAP installation, from scratch. This approach allows you to redesign some of the business processes. Once you have adapted S/4HANA to your needs, then you can transfer the data from the old SAP system. When choosing this scenario, you can either choose to deploy S/4HANA on-premise, or SAP also offers customers to deploy on the SAP S/4HANA Public Cloud.


The challenge with this New Implementation scenario is that you cannot migrate any of your adapted business processes; you must ditch all the investments in business processes you have made over the years, and go with the SAP standard processes. I’ll detail more about this when describing the second scenario.


The second scenario is a System Conversion. You have an SAP system that you want to keep “as is”, and migrate it to S/4HANA. You also want to continue using the same business processes that you have deployed in your company over the years. To achieve that goal you take your current ECC system, migrate it to S/4HANA, and at the end of the migration you have your current business processes running on S/4HANA. My estimate is that most customers would want to use this migration scenario, meaning keep their current business processes.


With that in mind, there is one very important thing that customers must realize—the only available options for this migration scenario is on-premise, or through a 3rd party cloud. The SAP S/4HANA Cloud does not support this option, so you cannot use SAP S/4HANA Enterprise Cloud to achieve this scenario!


SAP is pushing customers to use their SAP Enterprise Cloud, but if you want to use the SAP Cloud, then you’ll have to go back to standard SAP processes. All the development that you have done in the last 5 or 10 (or more) years – you will have to get rid of all these, because SAP will not allow you to have specific development on their own cloud. So, if you want to take the System Conversion path, then you’ll have to do it on-premise, or on the oXya cloud, because we do does allow you to do this type of migration and keep all the investments and developments you have done over the years.


The third option is the Landscape Transformation. This is pretty much a new implementation, only the emphasis here is on consolidation. You take some different ERP systems that you have in different branches, locations, or geographies, and you migrate them to S/4HANA. You perform a selective migration – you keep your old ERP systems and continue to run some activities on it, but do a consolidation of Finance (for example) on S/4HANA.


With the Landscape Transformation scenario, SAP says you can use either the on-premise option or the S/4HANA Cloud, but again – the S/4HANA Cloud does not support any type of developments or business processes that are different from the SAP standard. So, if you want to leverage the S/4HANA Cloud option, then the consolidation must be in SAP standard, meaning you cannot use your own business processes that you have developed (similar to scenario #1). Once again, if you want to keep your own business processes, you can use either the on-premise option, or the oXya cloud.


Conclusion: out of the above three scenarios that SAP provides, my estimate is that most customers will want to keep their current business processes. As a result, they will choose the second scenario, System Conversion, in order to not lose all the investments they made on the business processes side. However, the System Conversion option is not supported by S/4HANA Enterprise Cloud, so the only options available to customers are an on-premise installation, or with a 3rd party cloud which supports this migration, such as the oXya cloud.


We should take into consideration that SAP are trying to convince their customers to move to the SAP HANA Cloud. Customers who didn’t yet thoroughly investigate the various migration options may not realize that if they indeed decide to go with the HANA Cloud option, they will be forced to get rid of all the specifically-tailored portions (modifications) that they have, and only use the SAP standard, as nothing but the standard is supported on the S/4HANA Cloud.


In the coming weeks, we will dedicate a specific blog to S/4HANA considerations and migration paths.


And of course, come to see us next week at SAP TechEd in Barcelona - we have a joint booth for Hitachi Data Systems and oXya.




Melchior du Boullay is VP of Business Development and Americas Geo Manager at oXya, a Hitachi Data Systems company. oXya is a technical SAP consulting company, providing ongoing managed services (run management) for enterprises around the world. In addition, oXya helps customers running SAP with various projects, including upgrades and migrations, including to SAP HANA. Enterprises migrating to HANA are using oXya to perform the HANA migration for them, since they usually don’t have the in-house skillset and prior knowledge to perform that migration.

As every service provider knows, customers tell the best stories about your service. The best references that exist. When a happy customer tell their story, about how they benefited from your service, then that’s the best story there is. Much better than you speaking about your own service.Webinar_open_screen.png


Yesterday (Oct 14, 2015), I had the pleasure and honor to take part in a webinar that oXya held for customers, prospects and partners. I was specifically proud to open the webinar and introduce three of our distinguished customers – Celio, Smurfit Kappa Group, and Nextiraone – whose IT executives presented their SAP story, and how oXya helped them achieve their business goals.


These are not small companies. In fact, they are world leaders in their respective fields:

  • Celio is one of the world’s largest retailers for men’s fashion, with more than 1,100 stores across 60 countries around the globe.
  • Smurfit Kappa Group is a global leader for paper-based packaging, and Europe’s largest corrugated packaging company.
  • Nextiraone is a leading European IT Services firm, with operations across Europe.


Our business is all about our SAP customers. They are the ones for whom we work around the clock. We support them so they can achieve their business goals, grow and be successful. It is always heartwarming to hear complements for our service when we speak with a customer. All of you who provide services to customers, know what I mean. It is really special when a busy IT executive at a customer is willing to participate in a live webinar, invest the time and resources to develop a presentation, and provide a public reference to the entire world.


We are deeply grateful to Laurent Rousset, CIO of Celio; Tewfik Noumri, Director of Group SAP Competence Center at the Smurfit Kappa Group; and Flip Vandijck, Director of Global ERP Production at Nextiraone, for participating in our webinar, and for the warm words and compliments. We were honored to have them at our webinar, blushed at the compliments, and would continue to work hard and provide a great service to all of our customers around the world.




Listen to their stories, as there are some very interesting things in there, about how they developed their SAP strategy, implemented HANA, and are using SAP to run huge, international businesses. Any SAP customer can probably take something from these stories.



In addition to the customer stories, our webinar presented a decision-making framework that we developed specifically for this webinar, based on nearly 20 years of servicing many hundreds of SAP customers. This framework provides a process for SAP customers who consider a migration to SAP HANA. The framework addresses the two main challenges that such HANA migration entails – the human experience & expertise gap with regards to HANA, and the high cost of infrastructure that is tied to HANA.


We take the listener step by step, and present some options and decision criteria to solve these challenges. This framework is also relevant for current SAP customers who are not thinking about a HANA migration, but would still like to improve the level of service they are getting from their SAP environment – for both the human factor and the infrastructure.


Take a look at our webinar – the three customer stories are presented right at the beginning of the webinar, one after the other, followed by the framework for HANA migration. I’d love to read your comments and questions here, in this blog, and will answer everyone and everything.


Also, come see us at the HDS/oXya booth at the upcoming two TechEd events, next week in Las Vegas, and in a few weeks (November 10-12) in Barcelona. We would love to meet with you face to face, hear about your SAP challenges and concerns, and discuss how oXya may be of service to you.




Melchior du Boullay is VP of Business Development and Americas Geo Manager at oXya, a Hitachi Data Systems company. oXya is a technical SAP consulting company, providing ongoing managed services (run management) for enterprises around the world. In addition, oXya helps customers running SAP with various projects, including upgrades and migrations, including to SAP HANA. Enterprises migrating to HANA are using oXya to perform the HANA migration for them, since they usually don’t have the in-house skillset and prior knowledge to perform that migration.