Eursap's Ask-the-SAP-Expert – Ben McGrail

Eursap's Ask-the-SAP-Expert – Ben McGrail.

This month, we feature Ben McGrail. Ben has long experience in SAP data migration, making him one of the leading experts in the field. He has founded two businesses in the sector, and has worked with global clients such as Shell, Coca-Cola, EDF Energy and Sony Music.

Ben is the founder and managing director of Xmateria, specialist in SAP data migration. 

Ben and I caught up over a virtual coffee to chew the fat over all things data migration.

Q: To start, since not all our readers will know you, can you give a brief overview of who you are and what you do?

A: I've spent the last 20 to 25 years specialising in SAP and SAP data migration. I worked for various companies around Europe for the first ten years or so of my career, then around 2009 I started Harlex Consulting -- that's 17, 18 years ago now. We functioned as a specialist data migration practice, often running the data migration workstream as part of a much larger programme, working alongside larger partners for some of the UK and Europe's largest SAP customers. Back then it was very much classic data migration -- moving customers from non-SAP into SAP.

Then in 2016 we sold that business to SNP, at which point I was introduced to the world of landscape transformation and table-based migration, as customers moved from implementing SAP for the first time to transforming, modernising, separating, merging and upgrading SAP. That took me through to 2021, when I decided it was time for a fresh challenge.

Later that year, I founded Xmateria as a highly specialist data migration business. Where we're a little different is that most of the other players in this space are aligned to one product or one approach, whereas we work back from the customer's requirement. This gives us the independence to advise as well as deliver and act in the interests of our customers.

Q: You went through the Price Waterhouse (now PwC) graduate scheme. What made you go into data migration instead of the traditional functional or technical roles in the SAP space?

A: I didn't start out in data migration. I started as an ABAP programmer. There was a three-month programme -- management information training -- about 30 of us went through it, getting a broad introduction to various coding platforms. I'd done a French and Linguistics degree, so it was a real wake-up call. I hadn't quite appreciated I was going to be so focused on programming. When I graduated from that I was sent to Philadelphia for a one-month ABAP course, and that's how I started out. My first project was at Bertelsmann Music Group, which via a few iterations has become Sony Music, where I worked as an ABAP programmer building reports and conversion programs to specifications written by functional consultants. It was a strict functional/technical split in those days. I was actually doing data migration, but nobody called it that. You were writing programs to load data, but the thinking and testing were done by functional consultants. It was probably a few years later that data migration became a discipline in itself, requiring almost as much functional understanding as technical understanding.

I did about three years thinking of myself as an ABAP programmer in technical lead roles, then I was working in Brussels talking to someone at another company who said he was doing data migration. I asked what that meant and he said he was working to load customer master data, and that he'd been on it for six months. I couldn't understand how you'd spend six months on something for which it would take two days to build an LSMW program. That was the start of my understanding that data migration isn't really about the technology or building the program to load the data. It's about change and about how far the source data supports the target solution. If you're responsible for three, four or five objects, that's a significant piece of work over the course of a project, especially as the solution mutates a little as you go.

Q: You went on to found Harlex Consulting and eventually sold it to SNP, then started again from scratch with Xmateria. Why did you choose that route instead of the safer option of staying inside a larger organisation?

A: That definitely would have been the safer route. The first time, starting Harlex with Mitch Collinson, we almost fell into it. I'd been working on a project that took me to Asia, and I was at the start of a twelve-month stint living in China when the project got cancelled. My wife and I had just had a baby and taken a twelve-month lease on an apartment, so it was a case of 'what now?' We decided to start a company and look for customers. Someone I'd worked with at EDF got back in touch, we put a couple of data migration people on the project, and it grew from there. It was very organic - no plan, no real up-front investment, a bit of luck at the beginning, and then we were away.

This time was a much more conscious decision: hiring more senior people from the start and putting money in, which brings risk. After four and a bit years at SNP, where I was responsible for the UK and Ireland, I felt the role was becoming increasingly internal. I was a general manager for a territory, with a lot of reporting inwards and upwards. Perhaps half my time in a week was spent on internally focused activities, and I eventually realised my interest lay more in building a team and working directly with customers, particularly during the sales and solutioning stage. I enjoyed putting a compelling proposition in front of them and helping them through their challenge. We also really wanted to build some of our own technology, which wouldn't have been possible within SNP, where that was handled by a central team. I enjoyed working there, but it felt like time to do something new. 

It's a big move and you've no idea if it's going to work. You try not to think too much about the downside, you just do it, work as hard as you can, try to do the right things, and hope it comes off.

Q: It must have been tempting to try to do everything when starting Xmateria. What was the thinking behind keeping it narrowly focused on data migration, carve-outs and selective transitions, given you had skills in other areas too?

A: It was tempting the first time round, running Harlex in the early days, before we'd really learned by experience. As a smaller organisation, if you offer too many things you're in danger of just falling into the crowd. I think there's space in the market for large generalist organisations that operate at scale and take overall responsibility for big, wide-ranging programmes, and there's space for small, highly specialist, customer-focused companies that can move quickly and get things done, working closely with customers and with the larger partners. We see it as a bit like a special forces model versus the larger army. We do one thing and we do it really well.

Focus allows you to stand out from the crowd, both in terms of people knowing what you're there for and when to call you, and in terms of quality. One of our recruiting messages has always been that for people who want to spend their career in data migration, this is the best place to do it, because you're working exclusively with others who want to specialise in it. At the larger implementation partners, a lot of people fall into data migration, enjoy it, but don't have much of a career path there, particularly if they want to stay hands-on, so we become a good option for people who want to specialise. 

That was very clear to me the second time round with Xmateria. There was no question it would be tightly focused. That said, there are various types of data migration, and we have to be able to react to what customers need rather than being too wedded to one method. But absolute focus from the beginning.

Q: You've worked on projects including the West Burton Energy carve-out for EDF, and worked for Shell and Coca-Cola. You must have seen things go wrong that changed your approach. There must also be things that were conventional wisdom in data migration years ago that are now outdated. What's your take on what typically goes wrong, and how the approach to migration has changed over the years?

A: That West Burton Energy project was an interesting one. Six months end to end to move a divested business from ECC to S/4HANA. What went wrong there? What nearly scuppered it? Honestly, nothing, and I'll explain why, because I'm sure that sounds doubtful.

There are various things that drive data migration in SAP: business transformation and modernisation, which at the moment is largely manifested as customers migrating to S/4HANA; mergers and acquisitions, where data is separated out through a divestment or systems come together through a consolidation; and what we at Xmateria loosely call business evolution: systems that need to change in some way, such as a currency conversion, plant reallocation or company code consolidation.

Whatever the driver, the work tends to fall into two fairly distinct technical approaches. There's classic data migration. In the old days this would have been LSMW or Data Services, now it might be Migration Cockpit, where you load data through the application layer, normally via a BAPI, essentially repeating and automating what an individual would do manually, but at scale. Then there's what's often called landscape transformation, or SLO - the old name for the team at SAP that do this kind of work - where you use specialist software to go into a system and reorganise it at table level. That's a table-based migration, and it's what you'd use on a carve-out or a selective data transition to load large volumes of data quickly, often including integrated historical data. 

A table-based approach, which is what we used at West Burton, tends to be best deployed when there's relatively little functional change. You're applying technical change rather than process change that's driving a change to the solution. That makes it much more controllable. You're still reliant on other teams for some things like standing up systems, testing and so on, but you're not downstream of large-scale solution change, so the work is very predictable. On a carve-out into S/4HANA like West Burton, you might have a performance challenge because you're migrating historical data, sometimes billions of records, certainly tens or hundreds of millions, but that's a technical challenge you can control within your own team.

Compare that with a large greenfield migration from, say, ten legacy systems into ECC or S/4HANA. That's where the real challenge lies, and it's not so much a technical one. It's more about change: what should this look like, has the solution team finished designing the process, does the material master or customer master sit across three or four different areas of process across multiple territories, and has all of that been considered when working out the full complexity of what needs to happen to the data on migration? Greenfield is where you get the classic data migration challenges. A carve-out, a divestment, or a currency conversion: you can predict that in advance and get a lot done.

West Burton was six months, very short for an ECC to S/4HANA move, but we were moving a business almost unchanged into S/4HANA. Some chart of accounts reorganisation, a move to a new group currency code, business partners had to be activated, new GL, but those were all predictable challenges. We're working on one at the moment, which is the deletion of a divested business for a chemical company, with an end-to-end timeline of 6-8 weeks. That's an extreme timeline to remove 20% of a system but it’s doable under the right conditions. Three to five months would be more normal, with more test cycles. But with M&A projects you're typically doing right-to-left planning: it has to be done by the end of the transition service agreement (TSA) period, and you work back from there, rather than a typical implementation programme where you work out requirements and planning first and build cost and budget from that.

Q: Thinking about technology projects normally in terms of people, process and technology -- with data migration you've also got data as a fourth element. Across those four areas, where have you seen most of the problems? Is it the data, the tooling, the people, or the process?

A: It's not the technology. One of the myths is that when you're talking to a customer for the first time, some people want to lead with 'what tool would you use to migrate this data, how does your software work?' That's rarely the real challenge. It is important to get the right kind of software, though. There are companies that have done a divestment or a carve-out with a partner who didn't have access to, or experience with, landscape transformation software, and who've essentially stood up a new system, rebuilt the processes and delivered a classic data migration effectively running an expensive re-implementation project over twelve months when they could have done a carve-out in three.

We did some work last year with a customer who had upgraded to S/4HANA but had over 200 company codes, only about half of which they were actually using, so we were brought in afterwards to run a deletion. What they should have done, and what we would have advised at the time, was use a landscape transformation technology and run a selective data transition to S/4HANA, doing all of it in the same timeline as one project.

So it's important to have the right kind of software. Is this requirement best served by a classic data migration through BAPI layers, or by a table-based migration where there's less functional change and the business wants to retain more of its historical data? That's why it was important to us not to align ourselves too closely with one particular approach. When a customer comes to us with a requirement, we need all the options available so we can advise them honestly and independently. I'm always cautious of people who say 'we have this particular software, and this is what customers need for data migration': it isn't true. There are normally three or four software options available for any given requirement, some cheaper, some with more functionality. But I've never seen a data migration project fail or struggle because the wrong software brand was used. Maybe sometimes the wrong type of software. Technology matters, but it's more important to get the right type of technology than a particular brand.

So back to the question, what goes wrong? Definitely people, and definitely data. The two things that tend to go wrong most in a greenfield implementation: firstly, customers start too late. They engage an SI, work on the business case, put together a programme, think through the solution and process, bring the business in and run workshops on how things will work in the target. While they don't completely forget about the data, if it's an SI-led programme, the data team is often some way downstream of where the real decision-making is happening. Data gets handled too late. I've never spoken to a customer at the end of one of these projects who said, ‘we should have started later with the data.' That never happens.

We did a report at the start of this year titled “The true cost of data procrastination”, looking at the causes of disruption and delay in SAP programmes. When we asked customers when they'd started their data migration preparation, one of the options wasn't just 'did you start early enough,' it was 'did you start early enough to inform planning?' Only about a quarter had. That's the key question: do you know enough about your data, and has a data migration team been involved early enough to inform the approach and the plan? Sometimes there's as much value in having one or two weeks of our team's time at that stage as there is in having us deliver a project over four to six months. Just having a voice in the room who understands the options can drastically change how you approach a project, not just in terms of cost and timeline, but risk. How complex do you want to make this? So an early look at the data is one absolute focus area.

At the other end, where these projects go wrong once they've started is usually as a result of a misalignment between data and solution design. Over the last six or seven years there's been a trend for solution design to become agile through a project, working in sprints, which is fine from a solution perspective, but you have to set milestones at which enough is confirmed that you can decide, for example, what the material master or customer master needs to look like. When data migration teams end up working in silos, and the implementation partner doesn't see themselves as having a role to play in data migration, that gap opens up. You run a first or second load cycle and realise you've got all sorts of problems. There's a big role for the implementation partner within and around the data migration workstream, and if I were advising a customer, I'd say build that into the SI’s contract.

Q: I'm assuming you use a suite of technology products at Xmateria. Is it exclusively SAP products, or do you use others as well?

A: It comes down to what I said earlier about having a range of approaches available. If we're talking about a carve-out, you'd expect it to be landscape transformation software, but maybe it's a carve-out where the buyer has their own product, or it's a private equity buyer who doesn't want to run SAP because the business is too small as a standalone and the target ERP is, say, NetSuite, in which case it might just be an extract. Or it might be a greenfield data migration project coming from non-SAP, in which case we'd look at different tools.

For table-based migration projects such as carve-outs and SDT, we work with Natuvion’s DCS product suite which is incredibly powerful at a competitive price point. 

We also have our own product, Pioneer, a discovery tool that sits within SAP. We use it to run discovery and strategy projects, coming in early ahead of a project to look at the SAP dataset, profile it, and extract it out, whether that's for a greenfield S/4HANA project or a carve-out to a non-SAP target where we're taking data out into files. It has been really exciting to build our own specialist product over the past 4-5 years.

We also use SAP's own products, the tools that come out of the DMLT/SLO team in Germany for specialist engagements such as currency and fiscal year conversions. There's also SAP BTC, known as Lean SDT, a lighter version of selective data transition that lets you leave behind company codes and fiscal periods when moving to S/4HANA. It doesn’t have quite the flexibility of Natuvion DCS, but it's free to customers.

If we're migrating from non-SAP, or transforming a lot of data outside SAP, we might use Talend, which is very easy to use. 

And then, of course, there are the free-to-use tools like Migration Cockpit and LSMW, which still have their place. People sometimes say LSMW isn't supported for S/4HANA or doesn't work, but that’s not quite true. It works very well in S/4HANA as it does in ECC, so we use those too.

Q: Is there a line in your mind for when clients should rely more heavily on automation and validation tools versus manual data cleansing, in the extract and transform parts of ETL?

A: There's a bit of a myth around data quality, and I'm talking specifically about how it supports data migration, not as part of an ongoing data management operation in an SAP system. Often the conversation with a customer starts with how you'll manage data cleansing, but you can't really think about cleansing until you've defined what you mean by data quality. It's sometimes talked about as an objective grade, such as missing telephone numbers or an incomplete street address, but that's almost never really the problem in an SAP implementation.

In a carve-out, where there's little or no solution change from source to target, there are no data quality challenges. There might be questions about what you take and what you leave behind, but no data quality challenge, because you're moving data from an environment where it already exists into a copy of that environment. It's more of an issue in greenfield implementation projects, and specifically in the gap between the source data and the target solution. So really, it's not about data quality, it's about data readiness: how ready is the data, how closely is it aligned with the target solution, and how do you close that gap?

When it comes to transforming or cleansing data as part of a migration, there's a hierarchy of options. Option one, and this is important to understand at the start, is that you might just not take it. Not because the data has a quality issue, but because that data is not required in the target. We did some work with a council a couple of years ago. They had around 300,000 vendors and were concerned about the data quality and how they'd decide what to take and leave behind. We ran a vendor ageing analysis and found that 92% of their vendors hadn't been interacted with in three years and had no open balances, so they were straight out of scope. That left 8% to look at. So, your first option is to understand what you're taking and what you're leaving behind before you worry too much about data quality.

Your second option is to deal with it as part of the migration. If it's a rule that can be defined, you handle it in an automated way during the load. If it can't be handled as part of the migration, or the view is that it should be dealt with beforehand, your third option is to automate that cleansing in the source, again if the rules can be defined. 

Only after exhausting all other options would you say this needs eyes on it. There are data quality tools now that combine rule-based matching, fuzzy matching and machine learning. Ideally, you'd assign only the role of validation to the user rather than the actual cleansing itself. You'd use technology as much as possible, but even before that, you'd look at what you can avoid taking in the first place. 

There are some very sensible approaches to data quality, data readiness and data cleansing that take it slightly outside the critical path and de-risk the project.

Q: With the 2027 ECC support deadline looming, what's the feeling you get from clients in sales activities, pre-sales, and with existing clients? Panic, denial, genuine readiness? Or do you think that deadline isn't really an issue anymore, given we're in the age of AI and the back-end ERP is becoming less relevant?

A: Even a year or two ago, the world was dividing into customers who had moved to S/4HANA, customers in the process of moving and customers who knew they had to move but hadn't started and were beginning to worry about how. The end of 2027 deadline was certainly a factor in people's thinking. 

Over the last twelve months I've noticed that's changing. Maybe a third of customers have finished moving their ECC footprint to S/4HANA. There are various numbers going around - Gartner seems to be the most trusted - and SAP obviously knows itself, but the consensus seems to be about a third have moved and another third are moving or have started programmes but haven't gone live.

What I'm seeing now is that the last third are not moving. They're not doing it. I haven't spoken to anyone in the last year who's said they haven't started but need to get it done by the end of 2027 to avoid losing support. They've accepted they're going to go out of support, and they're looking at what they can agree with SAP, or through third-party support companies. The 2027 deadline date gets talked about on LinkedIn by people who have services to sell, but I don't see customers treating it as a reason to accelerate their migration to S/4HANA. If they haven't started the move by now, they're not going to start just to hit that date, and that's a real change. There's enough political and economic uncertainty in the world that boards are looking at this and saying they're not sure this is the year to commit to a project that could be anything from ten million to a billion. That's a lot of money for an organisation to spend if they don't see the value.

The AI point is interesting, because you can argue it both ways. Why move to S/4HANA when so much of the potential upside in IT might come through AI instead? Or, on the other hand -- what will AI offer in five years? I wouldn't have the first idea; it's moving so quickly. Five years before the iPhone, nobody would have guessed the change it would bring to business and social behaviour. I don't think anyone really knows where AI will be in five years. People can speculate, but they don't know. So, would you really want to be in the middle of a global S/4HANA upgrade at that point? Or would you rather get it done, get it out of the way, and not commit too heavily to a particular solution? That leans more towards a more technical upgrade, perhaps an SDT, rather than a big new greenfield implementation. If you haven't started one now and don't have an immediate business case, there might be a case for doing something more tactical to get it done and onto a new platform.

We're talking to one organisation at the moment that was created through a divestment. They're sitting on an old, unsupported ECC system that's already been compromised once, that’s run by the previous parent company, which they don't really have access to or control over, and it's highly customised. For an organisation like that, the priority is to get off that system as quickly as possible so they're ready with a modern architecture and platform to support whatever comes next. That's probably the most interesting angle on AI and S/4HANA migrations: do you hold off and wait to see what's possible, or do you move to a modern architecture now, so it's not still on your plate when the real opportunity comes along?

Q: AI must be changing data migration in practice. How is AI accelerating data migration, or is it largely just noise?

A: There's a bit of noise, I'd say. On table-based migration especially, it's already automated end-to-end. If you wanted to carve out a divestment into a new shell of SAP, there's no role at all for AI in doing that. Partly because it's already automated end-to-end. If you wanted to reorganise the chart of accounts as part of a carve-out, that chart of accounts, the GL account and related objects within SAP are highly structured and understood by the software and handled in a rule-based manner. For that kind of project, I don't see a role for AI. Maybe on the testing side, but not in the actual migration. And secondly, you want that process to be highly rule-based, not probabilistic. You need to be able to explain why the data looks the way it does in the target, because it's gone through defined rules and selection criteria, and trace that transformation all the way back to the source, so that if you have issues during testing or worst case, post-go-live, you can see exactly what happened and why. So, in that kind of project, there's no role for AI at all. I get asked the question a lot, because people assume there must be a big role for AI in data migration, but I don't think there is, at least not in SAP-to-SAP migration.

Where there is a role is on the data quality side, and in the scraping and analysis of non-SAP systems, where there isn't such a structured database or where the data model isn't well known to the people working on it. There's a role for first-pass analysis of a source platform and its data quality, and also for data integration -- pulling together a mixture of structured and unstructured platforms to produce an intelligent analysis of what it all means. Absolutely, there's a role there. But in SAP-to-SAP data migration, there’s less of a requirement.

Q: One final question -- the one we always ask our experts. Imagine I'm a newly qualified, certified SAP consultant coming into the market now. What's your advice? What should I be looking at, focusing on, and looking out for?

A: There's a question of how many people are coming into SAP now as graduates, in Europe and North America. When I started in 1997, Price Waterhouse, later PwC, would bring in hundreds of graduates a year, a third of whom might go into SAP, ABAP and functional roles. Andersen, later Accenture, were doing the same, as were Deloitte and EY and the rest. I'm 51 now, probably at the younger end of that cohort, many of whom are starting to retire, and there's been so much offshoring that the skill base has thinned. I'm not sure graduates are moving into SAP in the same numbers now; it doesn't seem to be such a popular career move. If you were a technically minded graduate today, would you move into SAP business applications, or into something more AI-focused? I think we probably know the answer to that.

The advice I'd give: it took me a little while when I started out to make the shift from being a student, where people were paid to help me, to being an employee, where I was being paid to help other people. That student mindset stayed with me for the first couple of years, until I realised no one is being paid to help me. Once you're off the graduate scheme, you're on your own, and you have to take responsibility not just for doing what you've been asked to do, but for delivering the outcome for the people you work for. Being outcome-focused rather than activity-focused: not just 'I did the thing, but I couldn't finish because of X, Y, Z'. Because if you haven't finished, you haven't done the job. That took me a few years to learn.

More general career advice: people often say 'do the thing you love.' For me it wasn't quite that. Whatever career you move into, your role becomes less technical over the first few years. In any industry, like a lawyer who spends less time drafting contracts and more time advising clients, you move up the chain a little, and as you get good at something and become skilled at it, you start to enjoy it. As you move away from the technical aspect of the job and become more commercial, or more focused on managing people, that shift happens almost regardless of industry. So, it might matter less what kind of job or industry you're in, you tend to enjoy the things you become good at. I wouldn't worry too much if, like me, you don't have a burning passion for one particular thing. That enjoyment tends to come as you get better at what you do.

Perhaps most importantly, understand that everything we do in our careers should start and end with the customer.  Beyond your own role and your own tasks, try to understand the commercial landscape of the organisation you work for. How does it earn its money? Who are its customers? And what do they want? Becoming commercially aware as early in your career as possible is a massive advantage.