SAP SuccessFactors migration to HANA begins in earnest

This year will see the SAP HANA database face its biggest test yet, as the entire SuccessFactors customer base moves onto the platform in a series of migrations that have long been planned for the first half of 2017.

The transfer to HANA has been in preparation for a couple of years already. In late 2015 I quizzed then senior VP of product management Dmitri Krakovsky (shortly before he left for a role at Google acquisition Bebop) about the scale of the task. At the time, SuccessFactors had already become HANA's largest user, having implemented analytics and reporting on the database. But the migration of SuccessFactors' large-scale, multi-tenant, transactional applications was going to be a far bigger test, he told me.

Nobody runs HANA in a multi-tenant environment at this scale. That’s why we want to be careful, thoughtful — because it’s live customers in production environments.

Even then, there were a small number of customers whose core applications had already moved to HANA so that SuccessFactors could finetune and test the implementation. That's continued throughout 2016, along with work to scale out the migration tools so that customers can be moved in tranches rather than individually.

At the company's EMEA customer event in late November, I caught up with Adam Kovalevsky, who as Executive VP of Product Management, Engineering & Operations, has overall responsibility for the success of the project. He brought me up to date with where things stand as the company prepares to roll out the migration in earnest.

A series of migrations

Designing the bulk migration tool has been a critical piece. The company runs "in the order of 30,000 schemas," he says — the blueprints that define the structure of each individual organization's data. Moving them one at a time was fine for development and testing purposes, but that process has had to be automated to permit large-scale migration. That too has been carefully tested with small numbers at first before ramping up the volumes:

It doesn't sound like a super impressive number, but we migrated nine customer environments [in October] with that [tool]. Essentially, we're scheduling the next fifty and then, over the course of 2017, each weekend in each of the ten data centers we'll have a series of migrations that we're running.

Similarly, the early migrations are of less complex implementations. The largest customers will move across to HANA later on in the project, he explains.

Not surprisingly, we choose simpler examples first. The gigantic 300,000-employee company running every possible application ... no that's not the first one that we migrate.

They tend to be organizations — 10,000 employees or less with simpler configurations — that we migrate. That's working well. We'll see that accelerate as we go into Q1 and we go through the course of 2017.

Standardizing on HANA has given the company an opportunity to simplify its data center operations from a "hodgepodge of databases" that the SuccessFactors family of applications was originally built on, says Kovalevsky. That has already proven itself in analytics:

Honestly, we don't think that we would be scaling our analytics and EmployeeCentral reporting at the rate that we do today if we were still on SQL Server/Hadoop. We don't think it would have handled the volume that we have today.

Optimizing performance

The developers have been working closely with their HANA colleagues to deal with issues as they arise.

I'm running HANA at a larger scale than anyone else has ever attempted to run HANA before. Obviously we encounter issues, and we work closely with the HANA engineering teams to resolve those issues as we go forward.

With the core transactional applications, there's been a strong focus on ensuring performance remains the same or better on HANA as it has been on Oracle. In some cases, that involves a rewrite of the original function to better optimize it for HANA, as Kovalevsky explains:

At the end of the day we can't migrate customers to HANA for them to have a materially different performance experience.

There's probably 10% of transactions where we see that HANA is significantly more performant than what we had in Oracle. There's probably 85% of transactions where, honestly it's more or less similar. And maybe there's 5-ish percent where it's materially slower on HANA than on Oracle.

Those are the ones where we essentially do a whole rewrite of, how do we optimize for how it can work on HANA? Then does that, in that rewrite, also change our thoughts on how do you approach the problem in the first place?

Moving to public cloud

Once the migration has been completed, a longer-term aim is to supplement SAP's own data centers with public cloud alternatives, building on the partnership with Microsoft Azure that was announced in October. For now, the Azure option is used primarily for internal purposes — sales demos and testing by professional services — before being rolled out to customers. But it is likely to become more strategic in the future, says Kovalevsky:

If I look ten years into the future, I would imagine that our growth will predominately be in public cloud data centers, because however competent we get at buying equipment and standardizing environments, I have to think that there are bigger and larger fish out there that are even doing that at a scale that make us look like a drop in the ocean.

So, we have a partnership with Microsoft that we announced the end of Q3, beginning of Q4. We're frankly very excited about that. It enables us to explore that as a potentially a long-term option for how we grow and scale.

My take

This is a major undertaking by SuccessFactors — which mirrors similar ongoing migrations by other products in the SAP portfolio, including Ariba and Concur. Successful completion will be a major milestone for HANA, but until the migration is complete, customers will be watching carefully for any signs that things aren't going according to plan. So far, all seems to be on track, but we are now heading into the most critical phase of the project. Time to buckle up for the ride.