By 2025, SAP will no longer support its existing ERP business suite, which is driving many organizations to consider the move to the next-generation SAP S/4HANA system. Yet these organizations are concerned about the effort, time, and cost that it will require to make the move. And the SAP users within these organizations have questions about the what, how, and why.
ASUG sat down to ask the authors of Migrating to SAP S/4HANA from SAP Press to share their insight about the migration process and what it will mean for SAP customers. Whether you’re ready for a system conversion (lift and shift), new implementation (greenfield), or landscape transformation (hybrid of brownfield and lift and shift), Frank Densborn (left) and Kim Mathäß (right) emphasized that preparation is key for a successful migration.
Sharon: Can you summarize the three typical migration scenarios?
Frank: The book discusses each migration scenario—system conversion, new implementation, and landscape transformation. And there are pre-checks to help you decide which scenario is best for your organization.
Let’s start with the system conversion, where you convert a single SAP ERP system into an SAP S/4HANA, on-premise system. This scenario is also known as the brownfield approach. With this approach, we think about bringing existing business processes to the new platform. Any custom code, system identification, and existing data you have will still be available after the implementation.
The next scenario is re-engineering your current system. This is a completely new implementation of SAP S/4HANA, also referred to as a greenfield implementation. So, that means you’re either coming from a non-SAP system or, if you’re from an existing SAP ERP system, you’ll be starting fresh. With this scenario, you can choose either an on-premise or cloud implementation.
And then we have the landscape transformation, which falls between the first two scenarios. This also requires re-engineering, but it’s much more customer-tailored, where various SAP ERP systems are integrated into a shared SAP S/4HANA system. You can perform a system consolidation, transfer an organizational unit, or transfer a specific application area. With this scenario, you also can choose either an on-premise or cloud implementation.
Sharon: What support tools and guidelines are available from SAP to help customers before, during, and after their implementation
Kim: SAP has lots of tools for lots of different use cases, sometimes even various tools for the same use case. We have dedicated tools for the three scenarios Frank just discussed.
One that I really like is the SAP Transformation Navigator. Although it is not directly related to any of the three scenarios, it gives you an idea of your current landscape and provides a framework for digital transformation. It analyzes each individual component, so you know what you have and what you need to do if you’re starting your path to SAP S/4HANA.
Once you have a clear vision of which scenario your organization will adopt, then the first technical tool you should use is the SAP Readiness Check. This tool scans your current system and tells you exactly what changes you need to make to go from an SAP ERP system to an SAP S/4HANA system.
Another useful tool is the SAP Software Update Manager, Database Migration Option (SUM/DMO). This tool has traditionally been used to bring ERP systems to ERP on HANA, but it has been enhanced to now do a system conversion to SAP S/4HANA. The enhancement is known as the SAP S/4HANA Migration Cockpit, which is used for new implementations and is available in the cloud and on-premise.
If you’re doing a landscape transformation, you can use the SAP Landscape Transformation tool, which maintains full data consistency and integrity within migrations and conversions.
Sharon: What should customers know about handling deployments in the cloud versus on-premise or in hybrid situations
Kim: For an on-premise deployment, you would download the software and run it on your computer. With a deployment on the cloud, you simply use your browser to access it. That’s the simple answer, but of course, there’s a lot more that goes into it. The Roadmap Viewer tool offers different implementation road maps with more detail.
With an on-premise deployment, you need to be aware of all the other lines of business and their processes and configurations. When we think of on-premise, we think of an empty system where you can pick and choose everything.
For a cloud deployment, however, we give you preconfigured business processes. It doesn’t mean you have to adopt these exactly, but they give you a jump-start into the implementation project. You can still change certain pieces of the configuration, but you don’t have to go through complete blueprinting, because most of what you’ll need is already there.
Sharon: How can customers run their implementations without disrupting daily business?
Frank: One of the reasons we wrote this book was to address customers’ concerns about project execution. We want to help our customers keep daily business disruptions as low as possible.
With that, I would say a disruption in processes is sometimes what our customers want. This type of disruption is not negative, it’s more like getting new business processes that include enhancements like artificial intelligence and machine learning.
In terms of disruption of daily work outside of the system, we know that customers need their system up and running 24/7 especially for manufacturing and production. When thinking about steps to take, I’d start by saying be prepared. Have a good project plan, have your processes in place, and test the migration itself.
If you’re doing a new implementation, do so with a sandbox system. If you’re doing a system conversion, have a shadow system that you use to keep the business disruption as low as possible.
Sharon: How much time and effort are required for training and testing when going through the implementation process? What tips do you have for training teams on the new system?
Kim: It depends. Let’s start with testing, because there are many variables. You should always have three tests starting with a technical one to see what kind of issues you’ll find. Next, you should have one good functional test. For both of these tests, you should allow two to four weeks of testing time. And then the third test is a dry-run test, where you have a real run through of a real copy of the production system.
For training, I would recommend openSAP. Compared with the traditional classroom-style training from SAP University, which is still available all over the world, openSAP courses are typically two- to four-week long, topic-focused online sessions.
They’re probably not ideal if you want to be an in-depth ABAP object-oriented developer. But if you want to know as a project manager for example, everything about a new implementation, the openSAP courses are very helpful.
Sharon: What should customers expect when it comes to setting up their user interfaces with SAP Fiori, as well as for other reports and analytics? How hard is it to make reporting and dashboards self-serve for the organization?
Frank: Our complete cloud SAP S/4HANA offering is consumable via the web, and it always includes SAP Fiori.
When you host a system using the on-premise version of SAP S/4HANA, you’ll need to set up a front-end server. The SAP Fiori screens, based on UI5, can run in any browser and on any device, and they’re scalable.
So, the big question is, do you need SAP Fiori? We highly recommend it for some on-premise scenarios. It’s basically something you must look at on the IT side. If you’re using SAP S/4HANA cloud, there is nothing you need to do because it’s already set up.
As for the end-user side of SAP Fiori, we’ve made it so that it is easily consumable. You won’t need to download a manual or undergo training. All the functions of SAP Fiori, including analytical reports and transactions in SAP S/4HANA, are very easy to use.
Sharon: What should customers plan for when they are including integrations between SAP S/4HANA and other systems including those for HR, sales and marketing, procurement, and accounting?
Kim: We tried to keep integration efforts to a minimum, so you don’t really need plan for anything. If you have modified APIs, you’ll need to look at those of course. Otherwise, the SAP interfaces are kept stable.
If you’re going for any of the new solutions, such as SAP SuccessFactors, that’s something you’ll have to integrate. But the good news is that we also have dedicated chapters on how this works in the book.
Most of the cloud products are already integrated out of the box, so you don’t need to plan for anything, unless you have a two-tier ERP and want to integrate it with on-premise. Then you’ll need to consider any modifications as well as how many satellite systems you have.
Sharon: What does the IT team need to do and what resources are available to manage cybersecurity during and after migration?
Frank: SAP has always treated the security of the systems that we are run, as well as the data that we store as a very important thing. In terms of the migration to SAP S/4HANA, the IT team doesn’t need to do anything other than use the tools that we offer. We have safeguards in place for the entire system, whether it’s on-prem or in the cloud.
Sharon: In your opinion, what does it take to have a successful migration?
Kim: The most important thing is preparation. No matter which scenario you choose, the more and the better you prepare, the easier it is. The simpler answer is to read our book.
Sharon: Can you summarize the book in one or two sentences?
Frank: This book serves everyone—our customers or partners in business, IT, or project management—to make their migration journey successful. Whether you have to, or because you want to start your journey to SAP S/4HANA, this book is a resource to learn about all of your options.
Migrating to SAP S/4HANA is available now from SAP Press. ASUG members, please log into your account for discount details. If you want to devote more time to SAP S/4HANA, you can also catch the on-demand webcast with the authors of the book, The Why and How of Migrating to SAP S/4HANA.