A little more than two years ago, the CTO of my holding company requested help. The holding company wanted to migrate their ERP from an old Oracle 9C database running proprietary code written in Oracle Reports, to SAP S/4 RISE. The corporate finance division was adamant on the project. The written code for accounting was flimsy at best, with almost no provision for integrating individual companies into a consolidated report.

As soon as my team heard the news, they started to complain. But they had very valid reasons. When the first round of SAP consultants interviewed us, the SAP executives asked us the first question that made me truly understand the scope of things: "What are your pain points with your actual system?" And the answer was simple: "None."

We truly had no problem with Oracle. Through the years, we had grown the code base to contemplate every single business scenario. Our Oracle 9C database was getting a little slow, but when IT migrated to 11C as a stop measure, the gain in speed was noticeable — so fast that it catered to our every need with room to spare. Many of our GTM programs were made in-house with a mix of JavaScript, PHP, and MariaDB. Our business is mature, so the growth in data year over year was modest. All our outside applications tied into our Oracle database, performed above expectations, and our MVC architecture had unparalleled control of our complicated segmentation and go-to-market cycles.

Without any pain points to address, with a team that loved developing its own custom solutions, and a complicated business model with unique go-to-market conditions, moving to a closed ERP system with standard solutions and little hope for custom modules under SAP's clean core policy seemed a big mistake. And it turned out to be more painful as we moved forward.

Being Forced to Change

The holding company asked me to support and lead the SAP S/4 RISE migration. That included being one of the project sponsors and motivating my team through the change. The first lesson: SAP is time intensive. I suffered alongside my team, moving away from our core mission of winning the marketplace towards becoming ERP consultants and executioners.

Consulting companies will tell you that a SAP implementation is a business process, not a developer process. SAP consultants, for the most part, are in the bottom rung of the ladder. You are forced as a manager to dedicate your best people to migration teams for two or more years. In my case, being a smaller company, that meant stretching my people's time and endurance beyond expectations.

Consulting companies will force on you four key processes that will consume time and prove frustrating: business process documentation, data migration, unit testing, and integral testing. Our consultants provided little coaching, complained constantly that none of these processes were deep enough, and — most incredibly — had little to no use of AI tools to accelerate the work. Even SAP's Cloud ALM application, used for migration and testing, is nothing more than a glorified worksheet with no special capacities despite its ambitious title.

Needless to say, the business suffered. I found myself alienated from account plans, marketing, and sales — focused on helping my team navigate testing phases and accelerating the process with Claude. By the end of it, we had developed our own XML files to document test changes and evolution, and a SKILLS.MD file we could use later to facilitate assembling tests.

The Fallacy of the SAP Best Standard

SAP and SAP consultants will insist on the golden SAP Best Standard — a set of rules forcing companies to use the SAP-provided tools without any customization. Our consultant initially opened his speech with SAP being a philosophy of business.

The cold truth is that we had a process. We had a very strict go-to-market cycle with intricate product assortments, segmentation, and future order processing, and we saw no reason to adapt to SAP standards. If you have no clean and clear process and your data is all over the place, I can understand why the SAP clean core would benefit a company. But we had a process pipeline clearly set in our workflow, and intricate data structures that never quite adapted well into the SAP standard. With the new ERP we were forced into a business model that loosely resembled ours, without any of the advantages of our more strict controls, monitoring, and surgical marketplace development.

The Four Dangerous Pitfalls

From my recent experience, I could clearly identify four areas of dangerous pitfalls in a common, two-year project cycle:

  1. Business Process Documenting
  2. Data Migration
  3. Unit Testing
  4. Integral Testing

Business Process Documenting

Business process documenting is the analysis and careful description of your business flow, broken down into segments. If someone were to analyze your business, reading these documents would be the most exact, complete, and objective source of content.

BPDs (Business Process Documents) are done in a special format, and in our case we used Signavio, a SAP tool that facilitates process documentation and charting. I started early in the process, even before contracting our consulting team, knowing well that this is a dry, time-consuming chore that loses focus fast. My teams started with very exact, detailed descriptions of processes and data, and then — as they got bored or relaxed — the content quantity and quality started to thin down.

This brings me to my first two lessons. Consultants should be responsible for making sure that BPDs include actual TO-BE process workflows, not just AS-IS descriptions. They should be accountable for knowledge transfer. And if consultants are not helping with BPDs, they are already failing you.

Data Migration

Our IT division prepared for data migration at least half a year before the project began. At the end, it turned out to be a disaster. Thinking through the post-mortem, I detected several flaws from the SAP ACTIVATE project framework. My team asked multiple times for SAP data models only to be told that came later. When later arrived, people were late to prepare for the copious amount of data they didn't have but SAP needed.

Much of what you have is useless or carries a different format in SAP — so you won't migrate as much as transform. Much has to be added by more than one team and tabulated into multiple worksheets, with mnemonic field names that reminded me of mainframes and COBOL. And much will be missing or wrong by the time you start unit testing. In SAP, everything is linked to everything in a way that makes the simplest task a monolithic undertaking.

My major learnings:

  1. BPDs are not to be used for data structures. Break the rule and include your full data structures. This is tedious, dry work, but do it because it will save you headaches later.
  2. Demand data models as soon as you start the project, and ignore your consultant if they tell you that phase comes later.
  3. Have consultants explain what data models are used in the actual process, how they map to future SAP best-standard practices, and what data is missing.

Do not move to unit testing until consultants explain both future process and future data models. Testing is stressful enough as it is, and having to fix data sources on the fly will only make it worse.

Unit Testing

The purpose of unit testing is to validate individual SAP components and guarantee they work perfectly in isolation. Examples include creating a Business Partner (BP in SAP lingo) or creating an invoice. The logic is sound: validate a single component in isolation to quickly detect problems and make corrections.

The holistic, end-to-end process gets validated in the next round of integral testing. Theoretical dictates unit tests put in a batch should equal an integral test — but that was never the case with my consultant team. We lost too much time recreating integral tests where none of the unit tests were reusable. That taught me a valuable lesson on how to create object-oriented unit tests that should be reused further down the line.

Good unit tests are the cause and effect of the following factors:

  1. Clearly understanding how the new system works and mapping the whole workflow visually. Consultants should explain and document TO-BE workflows as soon as the BPD phase ends. If this is not done, you will map the past, because that is exactly what the business team knows.
  2. Use 100% of your data, not 20%. Our consulting team suggested 20% of data for testing. Don't. Storage and ETL flows are cheap, fast, and easy nowadays. In SAP, one incorrect data piece will throw a perfectly well-planned unit test for days. You should be testing process and system integrity, not manually adding a ZIP code of an account you will never mail anything to.
  3. Work with business teams and consultants to isolate individual steps that will make good cases for unit testing.
  4. Force your consulting team to map and plan in advance for integral testing. I don't understand why a gap between unit test scripts and integral test scripts was ever acceptable.

Integral Testing

If you follow my recommendations above, you should arrive at the integral testing phase in great shape. With complete data structures and proven individual components, your attention should be totally focused on validating end-to-end system integrity. Integral testing should simulate your business workflow one final time before disconnecting the old system and turning on SAP S/4 RISE.

Such was not the case in our project. People arrived at this point still hunting down data, unable to execute tests because the 80% of account data migrated did not match with the 80% of product data, and too many missing data mistakes made test execution a hassle. Additionally, too many people still had no idea how the new system worked, lost staring at a cryptic and poorly designed SAP FIORI screen.

After integral testing, a go/no-go decision should be fairly easy to make. If you get to this point finding surprises — things that no longer work, missing integrations, system latency — you will have to go back to a previous point, or worse, patch on the go and launch an incomplete ERP hoping for the best.

A Word of Caution on Integrations

Our system had many integrations. SAP had to connect with our proprietary GTM and B2B platforms, our Manhattan WMS in the distribution center, and SAP Business One in one of our affiliates. Integrations were always late, to the point we scripted and began the integral test phase, only to stop when tests could not be completed because an integration was not working.

Integrations should be done before unit testing begins and evaluated in unit tests. Testing phases are about evaluation, not development. Getting to integral testing while still coding integrations means losing focus entirely.

Net Takeaway

SAP projects are so commonly painful that it has become an industry meme. SAP is only interested in pushing their monolithic ERP, collecting fees on FUEs, and enforcing a golden standard that may or may not fit your business. Consultants are interested in offloading work onto your business team, minimizing their own hours, and billing multiple projects simultaneously.

The SAP ACTIVATE methodology is a starting point, but a biased one — developed by and for SAP and consultants, not business teams. We need a methodology that truly helps users move from legacy to SAP best-standard, guarantees data migration integrity, and makes key users knowledgeable of the ERP before testing begins.

Until such a thing comes to fruition, I hope this article helps you avoid the pitfalls and pain. Your business team will thank you for it.