It's back on - SAP SuccessFactors HANA migration take 2

Will SAP SuccessFactors ever complete the planned migration from its original BizX stack to run on SAP's own HANA database? I've been tracking this long-running saga because I believe it will be an important proof point for HANA's ability to run a high-volume, multi-tenant application at scale. It's also a matter of interest for SuccessFactors customers because, although to some extent this is an under-the-hood issue that shouldn't directly impact them, they will want to know whether there's going to be a noticeable impact on performance and functionality.

So the question was top-of-mind yesterday when I met Amy Wilson, Head of Product, SAP SuccessFactors, at the Unleash show in London. Especially since, according to the timescales quoted eighteen months ago by then EVP of Product Management, Engineering & Operations Adam Kovalevsky, the migration was already supposed to have finished late last year.

It seems the project had lost momentum by the time Wilson came on board last summer, but she insists that it's now back on track, mainly because she sees real benefits from moving ahead with it. Already a significant number of customer instances have migrated across, although the largest, as was always the plan, will be the last to move, she tells me:

We started with moving customers that were only on our talent applications and now we're adding customers that are also using learning. And in a month or two we'll start with Employee Central. With each area we're going with bigger and bigger schemas. So our largest customers, with the biggest footprints leveraging Employee Central, they'll be moving to HANA later in the Fall.

I believe that we are now at 60% of customers [that were] on our BizX platform — 60% of customers on that stack have been migrated. So I think we have almost 3,000 customers that are running on HANA.

No more backsliding

The process is now too far advanced for there to be any further backsliding, she insists. The longer it goes on, the longer SAP has to support two separate database stacks, she explains:

We've never had 3000 customers on HANA. We're half pregnant now.

The last thing we want to do is be supporting both HANA and that other database ongoing. So that's what I mean by, 'We're half pregnant.' The faster we can get it done, the faster we are only testing on one solution and all that kind of stuff.

The migration is back on in earnest because there are real benefits from being on HANA, she believes:

From my perspective, it's really about being able to take advantage of the technologies within SAP. Some of those technologies exist inside HANA, but some of them it's really about the fact that other parts of SAP are on HANA, [such as] SAP Analytics Cloud and S/4 HANA, so it allows us better interaction and better leverage of the SAP tech goodness.

I don't think that was well understood before. [The migration] was seen as a big effort without a lot of value I think in the past. But now we see a lot of value in the move.

HANA potential

There will be further advances once the migration is complete, she believes:

The second part is really about optimizing for the HANA database itself. If you go back into the history of the S/4 migration, the very first thing that they did was basically a lift-and-shift over to HANA. And then throughout the years they started to completely optimize.

So that's what we'll be doing as well. The first stage is the lift-and-shift and immediately we'll get those benefits of the SAP reporting, analytics and connections. But as we progress forward, we'll be looking at different ways that we can optimize the solution.

Can we leverage HANA for a more performant and intelligent search capability? Can we leverage HANA to move our role-based permissions into a different category? Can we use HANA to do inline machine learning, in the moment? There's all sorts of different possibilities with HANA.

The extent of this potential was not fully appreciated in the prior regime before she came onboard, she believes. Moving to HANA perhaps seemed more like an obligation than an opportunity.

Right now we're just scratching the surface. We're just doing phase one — some initial benefits. But I think previously none of that was really understood. It just seemed like, well, 'It's SAP's database so we should move to it.' And that didn't seem like a compelling enough reason. Now we understand that it is quite compelling. So we're moving faster.

We're a bit of a guinea pig, but we're partnered up really closely with HANA and we understand so much more what it's going to bring us. So it's worth it.

My take

Three thousand instances is certainly a big advance on the first nine that Kovalevsky told me had been moved back in October 2016. But one has to wonder what exactly was happening throughout 2017, when the migration was originally planned to take place. Not very much of any substance was happening, apparently, but the reasons for that remain an unexplained mystery.

That hiatus has allowed other applications to increase their HANA footprint, and as Wilson explains, that creates a new incentive for SuccessFactors to complete its migration. There are also proof points with S/4 HANA for what can be achieved on the HANA platform. To that extent, by delaying, SuccessFactors is now less of a 'guinea pig' for running HANA at scale than it would have been a year ago.

But therefore that proof point of running large multi-tenant instances on HANA at scale still has to be demonstrated. Meanwhile the competitive bar has been raised by advances at Oracle, whose technology underpins the old BizX infrastructure. SAP is fully committed to making the break with Oracle and standardizing entirely on HANA, and no doubt customers are confident that SAP will deliver a solid platform. But they can only benchmark the actual results of that once the migration has been completed. We'll continue to watch developments.