Webinar:

Rethinking the path to SAP S/4HANA: Is Selective Data Transition a 'muddy field'?

Clear up the confusion around Selective Data Transition (SDT) and explore a structured path to S/4HANA.

.

 
Play video
So good morning, everyone. Welcome to today's webinar. I'm Joey, and I look after the marketing here at EPI-USE Labs Asia. Just a quick housekeeping note, your line will be muted through the session, but please feel free to submit your question through the control panel, and we will actually address them at the end of the session. Let me just quickly introduce who we are and what we do. We are an SAP Go partner. So at EPI-USE Labs, we deliver value to our clients through innovative products and services with a strong focus on enhancing and optimizing SAP landscape. Today, we support more than a thousand eight hundred clients worldwide. We are also a part of a larger group called Group Elephant. The group owns and fund a nonprofit organization called Elephant Rhino and People. So in short, it's ERP. And as part of this commitment, one percent of our revenue goes towards this ERP program. Now you can see we operate in fifty five countries worldwide with a local presence across many of this region. Now let me introduce our speaker for today, Jessalah Remyhill, transformation consultation at EPI-USE Labs. Jessalah bring years of experience in business and transformation sorry. Business and landscape transformation with a strong focus on SAP data transformation and s four HANA projects. So let's see what we are going to cover today. In today's session, we will talk about why now is the time to retain your S4HANA strategy. We will also explore the limitation of traditional greenfield and brownfield approaches and ask a very important question. Is selective data transformation really a muddy field or is it often misunderstood? From there, we will walk through what SDT actually is and why it offers a more flexible path forward. We will then look at how our solution support a more control or a smarter transition. And then, Jessala, we'll also share some of the use cases and outcome so you can see how it works in real life. And finally, we will share the final step, next step forward towards a transformation strategy that works for every organization. Well, let's start now. Over to you, Jessila. Okay. Thanks for that introduction, Joey. I welcome you all for today's webinar. My name is Jessella, and I bid you a pleasant day to all of you here. So in relation to what we are going to discuss during this session, which is selective data transition, let's discuss for a while why there is a need for this so called data transition. So as we know, ECC is currently stable, but it is aging. So it's been here for decades, and SAP is constantly reminding its customers of the end of support by twenty seven, which is basically next year. So on top of that, based on today's business demands, ECC doesn't support the innovation to where SAP is headed. Our industry is constantly changing, innovating, and every investment in ECC becomes a sunk cost once you move out of it. So the message here is now is the time to modernize your foundation. Today is the right time to position your organization for the future by modernizing your foundation. In today's session, we will help you realize, the need for transition into S4HANA and how you will be able to get there. So moving on to our next slide. So here we have the hidden costs of inaction. So these are what it means to do nothing while we know ECC is aging, and we are approaching a deadline on ECC support. Few years back, you might think it's still safe to wait and see before moving to s four HANA, but the risk of delaying your s four HANA move doesn't actually buy you time. In fact, in contrary, it increases risks and cost. So what feels like buying time is actually compressing the transformation window now. As you probably approach, ECC support deadline and rush through, oftentimes, the case is that rush reactive transformation is always more expensive than a planned phased one. So in similar fashion, organizations that continue to invest in their ECC enhancements while delaying S4HANA may face regretful spending on new reports, workflows, or integrations that won't be compatible with S4HANA soon. So custom code may need to be simplified or eliminated entirely. So well, during the migration phase. You effectively pay twice. Once when you build it in ECC and, again, to adopt and rebuild it in, s four HANA. So EDC environments also tend to become more expensive over time. The older databases and hardware require higher maintenance and support cost. Performance tuning becomes more frequent and complex. So vendors may increase support pricing for legacy stacks. So this rising maintenance cost eventually adds up and proves that keeping legacy infrastructure is more expensive, well, over time. So another factor to consider, which is a result of inaction, are missed, innovations. Sorry for that. So staying on ECC means missing out on capabilities that directly drive inefficiency and also revenue, which are oftentimes innovation driven. So the likes of innovation around AI, driven forecasting, let's say, anomaly day detection, and automation are often, missed. Now these factors ultimately drags you on transformation bottlenecks where complexity only grows with time. The longer you wait, the harder the move becomes. More customization to accumulate, data volume grows, making migration more complex, and integration with other systems can multiply. So instead of simplifying the landscape, delay compound complexity, leading to longer project timelines and higher implementation costs later. And so the bottom line here is that waiting may feel like the safer, lower cost option, but in reality, you increase technical debt. You delay business value. You raise the eventual costs and risk of transformation. What we need is a proactive stage move that spreads costs over time and lets you start capturing value earlier while also avoiding the premium of a last minute, transition. So moving on with, our next slide. So now we discussed the, the hidden cost, of inaction earlier. Now we jump into an approach that will help you start your SAP, S4HANA journey. You've probably heard of these two approaches, which are often the choice organizations have in moving from their ECC system. So greenfield is basically start fresh. You rebuild from scratch. Greenfield means you're not carrying forward your SAP, ECC, DNA. You're reconstructing the enterprise system intentionally. So it's also high on cost and requires long, timeline since you're doing far more than a system conversion. You're effectively redesigning how the business run. The greenfield can also be called the lean slate, a clean slate rather, because you are free to design the S4HANA system, without being constrained by how things were done on your SAP ECC system. But remember, at the same time, that same freedom is exactly what makes a greenfield disruptive. So with greenfield, you're not inheriting your legacy system. You adopt standard s four HANA processes instead of copying old one. So you remove years of customizations, workarounds, and duplicate logics. So you redesign data structures and reporting from ground up. Why this is disruptive is that familiar processes disappear. Roles and responsibilities shift, standardization often forces compromise, and heavier training and change managements are taking place. So greenfield really is often an overkill for most of the use cases. Brownfield, on the other hand, is a more popular choice. It is the easier approach. So, however, even Brownfield can fall short given that it is a technical upgrade of your existing system. It moves entire system, all your company codes, all your historical data come along, all structures, and unused entities are retained, which means it carries over all of your legacy issues as well. So, also, since Brownfield's principle is to take the existing system and technically convert it to S4HANA, it falls short and may only cater minimal transformation. So it means same process, same structures, same logic. So in brownfield, you might find yourself wondering and asking, should this process even exist? Is there even a better way to do this in S4HANA? So brownfield really is same process, just new system. And lastly, brownfield approach tends to move too much of the wrong data. So because its goal is system continuity, not data selectivity. So you continue at s four HANA what you've been doing on ECC. That also often translate to bringing, unnecessary baggage of poor data quality that's still preserved on your new system. So moving along to our next slide. In s four HANA migration discussions, greenfields and brownfields are often presented as two standard option, but both can fall short when compared to selective data transition or SDT because they sit at opposite ends of the spectrum. So one prioritizes, full reset, the other prioritizes full continuity. So as such, SDT is often informally called a muddy field, not because it is poorly designed, but because it sits in the middle and combines the elements of both a green and brown field. So blending elements of both in a way that can feel less clearly, defined. However, in fact, this hybrid nature creates both flexibility and ambiguity in your migration approach. Others may have reservations for SDT for fear of losing transformation control. So oftentimes, will arise such as on whether, let's say, you may not have full control on what get, what get transformed versus retained. Other factors why SDT is labels, labeled as muddy is due to confusion between process design and data strategy. SDT separates but also intertwines two complex layers. So first, your process transformation, the how business should operate, and data migration strategy. So the what data moves and how each, it is shaped. So there are also concerns on lack of preparation or suitable tools for SDP to work. So, generally, SDP requires strong data governance and advanced migration tooling and skilled architects who understand both ECC and your s four HANA model. So complex SAP data landscapes, so years of accumulated data, configurations, and dependencies naturally add complexity to transformation projects. Then there is the aspect of manual migration method that increases risk. So scripts of semimanual tools struggle to isolate the right datasets without breaking business logic. And, of course, the topic around risks of fragmented target system. So meaning poor data continuity can result in environments that are neither fully modernized nor historically, well, reliable. Moving along to our next, slide. Now the question stands, is selective data transition a muddy field? Again, as we've defined on earlier slides, SDT sits in the middle and combines the elements of both green and then brownfield, giving you control and agility to modernize without unnecessary risks, costs, or disruption. The term muddy for such a flexible strategy doesn't give this approach justice, really. Anyway, any approach will be muddy if not done right. That applies to, both Greenfield and also Brownfield as well. SDT is called a muddy field not because it lacks value, but because it blends two opposing migration, let's say, philosophy. It requires high coordination across data and process layers. It demands a strong governance to avoid inconsistencies. But when well executed, SDT is actually the most balanced and flexible approach. But without maturity or even clarity and the right pooling, its hybrid nature can make it feel less structured than the clearer but more extreme options, which is green on greenfield and brownfield. So with STT, you can basically move only the data that you wanted. No need to migrate outdated redundant data. You can bring only data that adds value to your S4HANA environment. You can also migrate in phases, not all at one. Unlike brownfield's typical big conversion approach, STT, well, supports incremental transformation strategy. Migration rollout can happen by function, by region, or by business unit, all while keeping your ECC and S4HANA running in parallel, so minimizing business disruption. SBT can also help you reduce your data footprint. SBT actually directly addresses one of the biggest SfourHANA cost drivers, which is data volume. You can now eliminate the need for copying full system. Any historical data can then be, archived with tools such as Archive Central to help cut HANA storage cost and simplify compliance. So next is that SDT helps set up your transformation to your goals. SDT is not just about data. It enables structures and business transformations during migration. And lastly is that SDT helps accelerate time to value. SDT can focus effort where it matters most, like critical business units or high value processes that can be prioritized first over your nonessential or low risk areas. This then reduces, like, fatigue on your project structures. So, is SDT really a muddy field? No. We don't think so. Despite it being often, labeled as a muddy field because it lends elements in both green and brownfields, SDT is better understood as a purpose built flexible transformation approach rather than your unclear, compromise. So here on our next slide, presync STT solution, Kinect methodology, Kinetic, rather, methodology. We make the most of such flexible strategy of SDT by introducing this methodology that can perfectly utilize SPT's advantages over greenfield and brownfield. This is what we call Prism, SDT solution kinetic methodology. So Prism is our migration and transformation methodology that is designed to structure complex SAP transformation programs into clear, repeatable phases without with strong governance, tooling, and automation support. So this methodology can be broken down into phases, which guarantees an effective migration and transformation execution. So we start off from the preflight phase wherein a free s four HANA assessment establishes the baseline of the current ECC landscape using automated tools and analysis. The expected outcome of this phase is a data driven understanding of migration readiness. So that includes key risks, estimated, effort, and a high level conversion road map. Then we move into the prepare phase. So this phase translates technical findings into business aligned transformation objective. This is where we start conducting, business and IT workshops to interpret as and assess, result. So, the outcome of this phase is a clearly defined transformation blueprint and pilot strategy, ensuring both business and IT stakeholders agree on, what success looks like before we even do the execution of it. Sharpen is the next phase. This is a controlled providing ground for the migration approach. This is where we address data issues from S4HANA conversion pilot, validating your, let's say, custom code adjustments and compatibility with S4HANA. So the outcome of a Sharpen phase is a validated migration approach, including proven SDT methodology, early technical, lessons learned, and refined estimates for performance and downtime behaviors. Now we move on to the f four HANA project execution phase, which starts off from the realize phase. So this is the core build and preparation phase. Activities on this phase includes perform full scale system built for your dev and tests landscape. So we apply here the data migration rules, cleansing, logic, and transformation mappings. And this is also the phase wherein we fix defects and stabilizer system behavior across all rest of the cycle. So the expected outcome from the realized phase would be a stable production ready s four HANA environment in a nonproduction system, so with the validated processes and resolved defects. Brief space, on the other hand, is a full simulation of your go live condition. So this page is where we run a complete end to end mock conversion, execute the full cutover plan, and on and also realize if there would be under realistic time constraints, validating also hour per hour migration steps. So during the brief phase, we expect a full validated and time confirmed cutover plan with clear operational readiness for deployment. And then comes the deploy phase. This is the controlled production transition window where ECC is converted to s four HANA. This is the go live, basically, for HANA conversion execution over gated business outage windows. Outcome of this phase would be a live S4HANA system successfully running in production with business operation resumed and initial stabilization underway. Then we have what we call the last phase, which is run. This phase ensures operational stability and user adoption after go live. So this is what we typically refer to as your hypercare period of support. So the outcome of this phase is a stable, supported HANA environment, which users fully transitioned and operational ownership has already been handed over to the BAU teams, so your business as usual, teams. Moving on to our next, slide. With an elaborate methodology discussion on what, Prism aims and delivers, it's not an exaggeration to say that the, the phases of Prism can cater the requirements of all three known approaches. May it be greenfield, brownfield, and STT. So there's a use for Prism in any of these three approaches. If we slice through it, while Greenfield aims to fit a standard of a clean, new s four HANA with its massive functional changes, you can still selectively bring only the data that you want in this new system and sunset the rest of the data that you don't need. For brownfield strategy of retaining tailored ERP, approach, you can still cut on nonproduction systems to reduce footprints and optimize builds for BAU in the future. So selective data management has a role to play regardless of the migration approach that you've chosen. On to the next slide, we ex we expound more on what Prism can offer in both worlds of brownfields and greenfields. If, say, you are pushing for a private cloud, the PCE, RISE, or on premise, we can bring that into a straight brownfield conversion, make nonproduction system lean by design, apply time slice, or draw data from production system to a smaller target and also apply scrambling to that. So on the greenfield environment, on the other hand, that would be TCE or RISE or s four HANA public cloud option. So we can help copy small subsets of data, maybe copying master data, maybe also just building a lean TCE, which is a workbench or configuration, and then putting a small set of data into it or maybe helping extract data from the source into a migration, runbook format so it is easier to load to your public cloud when receiving and building that public cloud solution. On to our next slide, to support a controlled and low risk s four HANA transformation, the Prism methodology is reinforced by a set of proprietary tools designed to bring structure automation and repeatability to each of the phases of your migration journey. So this tool works together to provide end to end visibility from initial system assessment and data profiling through to selective migration, validation, cutover, execution, and post go live, stabilization. So, the range of tools that we have covers the data migration itself with DSM System Builder, for example, and Shell Sync as well as DSM Client Sync. We also cater for validations with a tool like Variance Monitor and our archiving platform, which is Archive Central. So collectively, these tools realizes the aim of Prism and delivers our expected result. Outside of Prism, these tools can also engage in VAU scenarios. Those post migration data management, validations and reportings that an organization might need. So moving ahead on our next slide. So jumping from our discussions and methodology and then approaches, let us now on this hybrid migration look with an easier but technical point of view. So, technically, we're going to start from an e c r three, e c six system, and we're going to move to s four. And we want to bring subsets of data. So with Prism, the Prism solution, we can create a lean target of empty shell system, effectively getting the table structures, repository, and cross client configurations. Then into that, we can now bring the client that we want. Say you only want to bring one client into your new S4HANA, which is also possible, then we bring in the client dependent customizing and subset of transactional and master data depending on how you are trying to reduce actually or selectively transition into your target system. So verifications, transformations, and managing the conversions, can be wrapped around the process as we decide on your migration, approach. Moving on with our next, slide. So a little bit around downtime minimization with Prism for S4HANA is that oftentimes downtime comes a lot as a key need, especially during a production cutover. So downtime during cutover is one of the biggest risks in NES for HANA migration, especially when large data volumes and complex transformations are involved. So Prism helps minimize this by combining methodology, like your planning, rehearsals, and sequencing with specialized tooling, like your optimized downtime so that the actual outage window is as short, predictable, and controlled as possible. Basically, in relation to the previous slide, in order to minimize the downtime, we've already done a shell copy of your target prior to the actual dine downtime itself. And then staging into that are batches of copies of data at a client level. So when we reach the downtime period itself, we've actually built the bulk of the system. Then we start the downtime when the logic of preparation of data and movement of it happens as well as any conversions needed for your s four. So this is the idea. We are staging the, data pre downtime. So mostly bulk of it has already been staged pre downtime, scenario. Now moving along on to our next slide, going back to Prism. So, generally, when we think about Prism, we classify them into two area. The one is Prism for technology and the other is Prism for business. Both of these are driven by the same Prism consultants, same solution, but they differ in what they are trying to achieve in terms of either technology or business change. So in technology, this side is more on structural change to the system with minimal or no impact to business process. So examples are when you make smaller, leaner systems anonymizing and identifying data in test systems, but are not impacting the nature of your business processing itself. On the other hand, the person for business is more on aligning to where that business is at and where it wants to be and feeding that movement in s four HANA context. So this is more suitable for carve outs, mergers, and acquisitions, deletions on also plant reallocations, which are common, and many more. Prism for Business is looking into my system doesn't match my business anymore. So how do I adjust my system to match my business in the future? On our next slide, we are now going, we've now covered, actually, the methodology and approach of, Prism with STT. It's helpful to see how this comes to a real life and real word scenarios. I'll walk you through a couple of customers examples where Prism was used to support selective, data transition. So one global technology company leveraged Prism to execute a selective data transition as part of its S4HANA journey. Instead of migrating the entire enterprise in just one go, the organization adopted a phased approach, selectively transitioning specific divisions and functions while retaining certain legacy ERP environments. This allowed them to better manage risks and align the migration with business priorities. So using a brownfield approach enabled by Prism, this company was able to selectively migrate data while also transforming key financial structures. So this includes redesigning the general ledger, merging controlled areas, and standardizing reporting through their new divisions and group level currencies. The demonstrating how SDT can balance continuity with targeted transformation. So on to the next slide, we have a Judicial Council of California, which successfully leveraged Prism to execute complex S4HANA conversion alongside a full landscape migration to Microsoft Azure. So supporting a high distributed environment with fifty eight court, thousands of users, and large volumes of vendors and customers and HR data, the program required both technical and technical precision and strong coordination. So Prism enabled a structured and controlled approach covering system upgrades, also, secure data handling through scrambling and the refresh of nonproduction environments to ensure consistency and compliance. So the result was a future ready platform for judicial council of California with improved security, updated infrastructure, and strengthened collaboration between their teams. Next would be a leading UK transport group, first group, which used Prism to support a selective data transition as part of its move to SAP ECE of Rice. So rather than migrating an entire ECC landscape, first group defined a focused scope of business critical data objects to be extracted and then, transformed and loaded those into the new environment. So this approach ensured that only relevant high value data was carried forward, aligning the migration with business priorities. So this leveraged really well Prism. The team was able to precisely extract and transform, the selected data while coordinating seamlessly with the system, integrators and responsible for loading, those into S4HANA. And lastly on my list would be a customer, Powerlink. So an Australian energy provider that leveraged Prism to support its transition from ECC to s four HANA driven by the need to enhance user experience, unlock improved functionalities, and address long standing configuration and customization, challenges. So rather than treating the move as a pure technical upgrade, the program focused on stabilizing and, optimizing their existing environment while preparing for a more modern s four HANA platform. So this is a structured pilot led approach that enabled them to have a smooth go live within the plan timeline and the budget, demonstrating how Prism can reduce risk and improve predictability even in technical and complex upgrade scenario. So moving on with our, next slide. So when organizations ask, why choose Prism for s four HANA? The most compelling answer comes from those who have already used it. Across industries, customer experience consistently shows that Prism is not just a methodology. It is a proven way to deliver s four HANA, transformations with speed that is much faster, more efficient, and far less, risk at hand. These real world outcomes demonstrate, accelerate accelerated delivery, speeds through a software driven approach, so enabling your projects to complete significant significantly faster while maintaining high quality and repeatability. At the same time, customers highlight how Prism supports the broader s four HANA transformation wave, so handling your complex scenarios like mergers and acquisitions and selective data transitions with confidence while keeping cost under control, though, so automation and a focused data centric approach. So in its collaborative delivery model, ensure strong alignment, between teams, making both planning and execution, smoother. So, ultimately, customer testimonials reinforce that Prism doesn't just promise these benefits. It consistently delivers them in practice. Okay. So on to the next slide. Yeah. Before we move on the next, yeah. Well, here we are on the next slide. Before we process this next slide, I'd just like to ask the question again. Is SDT really a muddy field? Clearly, the answer is no. SDT is not a muddy, is not muddy middle ground. It's a precise controlled approach that gets you, or lets you move only what truly matters while leaving behind outdated or redundant data. Unlike greenfield, which requires a complete rebuild or brownfield, which carries over everything, SDP strikes a balance by combining innovation with continuity. So the result is clearer, faster, and more strategic path to s four HANA that minimizes risk while maximizing business, value. So are we ready, or are you ready to move your or, engage on your SAP s four HANA journey, but not yet sure where to start? So thinking about what would be, like, the first step of it. So before you commit time, budget, and resources, get a clear picture first of your system's readiness in minutes. So scan the code that you see on your screen. This is our free s four hundred readiness assessment that helps you identify gap, risks, and opportunities so you can plan smarter and avoid cost or costly surprises along the way. Just scan the QR code to unlock instant insights and take the first step toward a smoother, faster s four HANA journey. So, that's about it on the discussions that we have today for why STT really is not a muddy field. It doesn't give a justification or justice for STT to call it a muddy field. On to you, Joey. Yeah. Thank you, Jessala, for this very insightful session about SDT. Now we have received a couple of questions from the audience. Let us go through now. The first question is what kind of business benefit most from SDT? Yeah. That's a good question. So I'd say organizations with, like, a complex landscape, mergers, You can also put their carve outs or large volumes of legacy data benefit legacy data. These types of organizations benefit the most. So SDT with Prism is especially valuable when you want transformation without starting from scratch. Okay. Thank you for clarifying that. And then we have a second question. How do you ensure data consist consistency and integrity? Yeah. So Prism uses controlled transformation rules and reconciliation checks throughout the duration or phases of our migration. It ensures financial and transactional data will remain balanced and accurate before, during, and after migration or the move to S4HANA. So we have propriety tools, which I've showed earlier, that can also do validations for data sanity check. I see. Thank you for answering that question. We have another interesting question here. So what happened to our historical data after migration? Yeah. Also a good question. So you don't lose your historical data. In Prism, it enables you to bring only those history that you needed on your new system. So if you only need, like, ten years worth of data, last ten years, last seven, last five years, yeah, you can definitely do that with Prism, while also we can do archiving of what's going to be left behind. So this keeps your new system lean but still audit compliant. So we have Archive Central, which is a propriety solution to cater the need for archiving or any sort of archiving that you need for those that will be left behind on your ECC system. Thank you. And I think we have a webinar on archiving archive central solution in coming months. I will be sure to share with everyone in the in this webinar. So we have one more question. Can we choose which company codes or business unit to migrate? Yes. So the short answer for that is yes. So preseam allows you to do a very granular data selection. May it be for, let's say, sizes on company code, business unit, maybe also geography, or even specific data objects. So this means you can phase your transition and align it with business priorities instead of doing everything at once. Thank you so much. Now one last question just came in. It's pretty personal. It's based on your personal experience. What is the minimal downtime required for production in your experience? Minimal downtime, really, it depends. What we promise with Prism is that we will deliver the s four migration during a cutover in less than forty eight hours because what we want to achieve here is to do as minimal downtime as possible. And the longest that you can think of in a downtime is working it out during a weekend, which basically gives you forty eight hours. So the fastest that I've seen we've had would be just a few hours. The longest, to just give you a context, when we move over a billion or more than a billion records is less than twenty hours. So I would pretty much say that our downtime management for the migration approach to s four HANA is pretty much very acceptable for organizations. Thank you for sharing your insight, Jessila. So thank you for everyone, like, to take you off your time to join us today and for all your questions. So after the webinar, we'll be sharing a recording with you. And if anything comes in mind or if you have any further questions about Prism or about our preflight assessment, please just feel free to reach out to us at any time. And then another thing I would like to share is we also have an upcoming session on understanding your true FUE licensing position. You can scan the QR code here to register, and I hope to see you there then. Well and is there anything else from your end, Jessala? No. I hope this session gave you clarity on why SDT is really personally, I think it's the best approach out there for you guys, but, well, it depends on organizational needs. Feel free to drop us any questions via emails if you need to learn more on the approach of Prism for SDT. Yeah. Sure. Okay. Thank you, everyone. Thank you for attending, and we look forward to see you soon. Thank you. Thank you, everyone. Thank you. Bye. Bye.
Recorded: 23 April 2026
 

About this webinar

Many organisations approaching S/4HANA migration find themselves stuck between two familiar options: Greenfield or Brownfield. While a Hybrid approach, or a Selective Data Transition (SDT), is often described as complex, unclear, or even risky.

But is SDT truly a 'muddy field' – or is it simply misunderstood?

In this session, our Transformation consultant Jessela Remigio unpacks the realities behind S/4HANA migration approaches, and explore how a structured SDT methodology can provide clarity, control, and reduced risk.

Watch this webinar to find out:

  • The differences between Greenfield, Brownfield, and SDT
  • Why SDT is often perceived as complex, and where that perception comes from
  • Common migration risks organisations overlook
  • How structured methodology and tooling can reduce uncertainty
  • How to assess whether your current landscape is ready

Who should attend?

  • CIOs and IT Directors
  • SAP Program and Project Managers
  • Enterprise Architects
  • HR and Finance Transformation Leads
  • SAP Technical and Basis Teams

If you are evaluating S/4HANA migration options or questioning your current approach, this session is designed for you.

Jessela Remigio
SAP HCM Consultant

With expertise in SAP HCM and SuccessFactors, Jessela Remigio focuses on streamlining implementations, reporting, and system migrations. She leverages her experience from large-scale SAP projects to address payroll testing challenges, optimising payroll processes and ensuring seamless transitions across SAP HCM environments.

EPI-USE Labs needs the contact information you provide to us, using the form embedded in this video, to contact you about our products and services. You may unsubscribe from these communications at anytime. For information on how to unsubscribe, as well as our privacy practices and commitment to protecting your privacy, check out our Privacy Policy. If you would like to receive emails from us, such as invitations, access to webinars and latest SAP insights, please remember to tick the box.