Why Rise with SAP Looked Like the Right Call
I've been through several ERP migrations in my career, but Rise with SAP was the first one where I genuinely believed the transition model was structurally different from what came before it. Not because of the marketing — there was plenty of that — but because the underlying premise addressed a real problem. Legacy S/4HANA on-premise customers were spending a disproportionate share of their IT budgets on infrastructure management, basis operations, and keeping the lights on rather than on capability advancement. Rise's managed cloud model promised to shift that burden to SAP, freeing IT to focus on business value rather than hardware and OS patches.
That premise holds up. The execution, however, is considerably more complicated than the premise suggests. This post is about the execution — specifically, the things that surprised us, the mistakes that cost time and money, and the lessons that I wish I had known at the start rather than discovered partway through. If you're evaluating Rise or early in your migration planning, this is the post I would have wanted to read before we began.
The Contract Phase: What We Didn't Read Carefully Enough
The Rise with SAP contract is more complex than a standard SaaS subscription. It bundles infrastructure, support, licensing, and transformation services in a way that gives SAP significant control over the scope and pace of your migration — and that creates terms that look favorable in a summary but have meaningful implications in the details.
The RISE Scope Includes More Than You Think — and Excludes More Than You Think
Rise covers the S/4HANA Cloud Private Edition license, the underlying infrastructure, BASIS operations, and certain support services. What it does not cover, and what many customers discover too late, is the full cost of the migration itself. System conversion work, data migration tooling, third-party integration re-wiring, custom code remediation, testing infrastructure, and consulting partner fees are all outside the Rise contract. For a typical mid-market customer, those costs can equal or exceed the Rise contract value over the first three years.
I don't say this to discourage the move. The economics still work for most organizations. I say it because the budgeting process often anchors on the Rise contract value and treats everything else as "implementation costs to be estimated later" — and later, the estimates come in significantly higher than expected because the scope of remediation work wasn't well understood at contracting time.
The Transformation Package Terms
Rise includes various SAP Business Transformation Services credits and commitments that sound valuable but have expiration dates, scope limitations, and utilization conditions that aren't always front-of-mind during contract negotiations. Customers who don't plan to use these services within the contractually defined windows sometimes discover they've effectively paid for capacity they couldn't utilize. Engage your legal and procurement teams to understand these terms before signature, not after the contract is live and the clock is running.
Exit Terms and Data Portability
The conversation about what happens if you need to exit Rise — either to a different vendor or back to on-premise — belongs in the contracting phase, not when you're actually contemplating a change. Data portability, export format commitments, and transition assistance terms all vary and are negotiable at signature. After signature, you have whatever the contract says. This isn't unique to SAP, but the scale and complexity of an S/4HANA footprint makes data portability a more significant consideration than with most SaaS products.
Data Migration: The Gap Between DMO Documentation and DMO Reality
The SAP Database Migration Option (DMO) is the primary technical mechanism for migrating from a legacy ECC or S/4HANA on-premise system to the Rise cloud environment. It's well-documented, reasonably mature, and capable of handling complex migrations. It's also significantly more demanding than the documentation suggests when your system has accumulated fifteen years of customizations, non-standard configurations, and organic complexity.
Data Volume and Migration Duration
DMO migration duration scales non-linearly with data volume, and older systems accumulate data at rates that aren't always visible until you run the initial size assessment. One system I was involved with had accumulated 4.2 TB of database content over fourteen years, but the team had estimated migration duration based on the 1.8 TB figure from a two-year-old sizing document. The actual migration ran 40% longer than planned, which cascaded into go-live timeline pressure that affected testing coverage.
Run a fresh, comprehensive sizing assessment within 90 days of your planned migration start. System sizes grow faster than most IT teams track, and stale estimates create go-live risk downstream.
Data Archiving Is Not Optional Preparation — It's Critical Path
Every TB of data you migrate to Rise is data you'll pay to store in the cloud environment long-term, and more importantly, every TB increases your migration duration and risk window. Organizations that invest in ILM (Information Lifecycle Management) archiving work before migration — archiving historical data that meets legal retention requirements but doesn't need to be in the live system — consistently have shorter, lower-risk migrations than those that migrate everything.
The challenge is that archiving preparation takes time and organizational will. Finance doesn't want to archive historical transaction data. Legal is uncertain about what can and cannot be archived. Department heads want "all their data" in the new system. Getting alignment on an archiving strategy requires executive sponsorship and clear communication about the migration risk and cost implications of not archiving — and that conversation needs to happen 6–9 months before migration starts, not in the week before the migration window.
The Data Quality Reality Check
DMO migrates what's in your source system — including every orphaned record, inconsistent configuration, and data quality exception that has accumulated since your original go-live. SAP's Software Update Manager will flag migration errors, but many data quality issues only surface when users try to execute business processes in the new system that depend on clean data. The time to discover that 15% of your vendor master records have incomplete bank data is not during cutover, with business stakeholders watching a dashboard counting down to go-live.
Plan and execute a formal data quality assessment and remediation phase — minimum 3 months — before migration. Prioritize the data domains that your most critical business processes depend on: customer master, vendor master, material master, chart of accounts, and open items. Don't attempt to remediate everything — triage ruthlessly and document what known data quality issues exist and will migrate with the system, so that business teams can address them post-go-live rather than treating them as migration surprises.
The Customization Removal Problem
Rise with SAP Cloud Private Edition supports a narrower extensibility model than on-premise S/4HANA, and SAP's strategic direction is explicitly toward Clean Core — the principle that direct modifications to SAP standard code should be eliminated in favor of approved extension mechanisms. For organizations migrating from legacy ECC systems, this creates a fundamental tension: years of custom ABAP code, user exits, and BADi implementations that have become load-bearing parts of business processes now need to be either replaced with standard functionality, re-implemented as Cloud-compliant extensions, or eliminated.
The Scope Discovery Shock
Most organizations underestimate their custom code volume until they run the ABAP Test Cockpit (ATC) clean core analysis against their production system. The first time you see a report showing 4,000 custom objects with 847 critical findings and 2,300 warnings, it's a significant moment. The question "how did we get here?" has a simple answer: organic growth over many years, with each customization solving a real business problem at the time without any systemic view of the cumulative technical debt being created.
The analysis is the easy part. The hard part is the business conversation about what to do with each significant customization. Some can be replaced by standard S/4HANA functionality that didn't exist when the customization was built. Some represent genuine business requirements that need to be preserved through ABAP Cloud or BTP extensions. Some are used by one person three times a year and can simply be decommissioned. Sorting 4,000 objects into these categories requires both technical analysis and business stakeholder engagement — and business stakeholders rarely greet "we need to remove functionality" with enthusiasm.
Managing the Business Stakeholder Conversation
The most difficult conversations in a Rise migration are typically not technical. They're the conversations where you have to tell a department head that the custom report their team has been using for seven years to manage their monthly close will not migrate to the new system because it makes direct database reads that are incompatible with the Cloud architecture — and the standard Fiori equivalent doesn't have the exact columns they've been relying on.
The approach that works is to lead with business outcomes rather than technical constraints. "This report needs to change because of technical requirements" generates resistance. "Here's what the standard S/4HANA Analytics capability gives you, here's what's different from what you have today, and here's what we've built on BTP to close the gap" gives stakeholders something to evaluate rather than something to object to. The gap analysis between current custom functionality and standard replacement functionality is the most important artifact in the customization removal process — and it needs to be produced early enough that stakeholders have real input into the remediation approach, not just a notification that a decision has already been made.
Testing: The Phase That Gets Compressed and Why That's Dangerous
In almost every ERP migration I've seen or been involved with, the testing phase gets compressed. It happens for predictable reasons: data migration takes longer than expected, custom code remediation takes longer than expected, integration re-wiring takes longer than expected — and the go-live date doesn't move because it's contractually committed or tied to a fiscal period boundary. The slack comes out of testing.
What Got Missed in Testing and What It Cost
When testing gets compressed, the first things to go are edge cases, period-end processes, and integration scenarios. These are exactly the processes that are most likely to fail in production and most costly when they do. A payroll process that hasn't been tested in the migrated environment can fail at month-end, affecting every employee's paycheck. An accounts payable integration that works in simple scenarios but fails on specific document types might process correctly for 95% of vendor invoices but block the 5% that have non-standard terms — and those 5% might be the ones your CFO's office is watching.
The specific issues we encountered that traced back to insufficient testing included: an output determination configuration that worked correctly in QA but failed in production for customer invoices above a certain value threshold — discovered when a large customer called to ask why they hadn't received their invoice two weeks after the billing run; and a plant-to-plant transfer process that worked in isolated testing but failed in integrated testing because a condition type in pricing hadn't been correctly migrated — discovered three weeks post-go-live during an inter-company reconciliation.
Building a Test Strategy That Resists Compression
The way to protect testing from timeline compression is to build a test strategy that makes the consequences of skipping explicit. Create a test coverage matrix that maps each business process to test scenarios, and explicitly risk-rate each process — what's the financial or operational impact if this process fails in production? Processes that are both critical and complex get tested first and tested completely. Processes that are less critical or that have manual fallback procedures can tolerate abbreviated testing if the timeline requires it.
This doesn't solve the timeline compression problem, but it changes the conversation from "we're skipping testing because we're behind" to "we've made a conscious, documented decision to accept elevated risk on these specific processes" — which is a conversation that project sponsors and business owners need to have explicitly rather than it happening implicitly when the testing team runs out of time.
Automated Regression Testing Investment
One investment that pays back significantly in Rise migrations — and in ongoing operations afterward — is automated regression testing using tools like SAP Cloud ALM's test automation or third-party solutions like Tricentis or Worksoft. Automated tests can run against each new transport release in the migration environment and catch regressions early, rather than discovering them during planned manual testing phases. The initial investment in scripting automated tests is substantial, but for a complex S/4HANA landscape, the long-term value of having a regression suite that runs nightly is substantial.
Go-Live Readiness: The Checklist You Actually Need
Go-live checklists in SAP projects tend to be either too broad (generic project management checkboxes that don't address technical specifics) or too technical (long ABAP transport lists that don't connect to business readiness). Here's the go-live checklist framework that I think actually reflects what matters.
Technical Readiness
- All planned transports promoted to production and verified
- All open high and medium priority issues in backlog reviewed and disposition documented (fix before go-live, fix in hypercare, accept as known issue, or defer to later release)
- Interface monitoring active and baseline established for all integrations
- Batch job schedule configured and initial runs validated
- Output management confirmed for all critical document types (customer invoices, POs, delivery notes)
- Cutover data loads completed and reconciled (open items, open orders, cost center plan data)
- Security role assignments validated for all user categories with explicit sign-off from business process owners
Business Process Readiness
- All critical path processes executed successfully in User Acceptance Testing with business sign-off documented
- Period-end processes rehearsed in migrated environment by business users (not just IT)
- Manual workaround procedures documented for known issues going live with the system
- Business cutover activities completed (legacy system freeze, open transaction closure, reconciliation sign-off)
Support Readiness
- Hypercare team staffed and schedule confirmed (do not rely on the implementation team being available indefinitely post-go-live)
- Escalation path defined and communicated — who gets called when, and at what severity threshold
- SAP support ticket process reviewed and key contacts established
- Known issue register active and visible to support team
User Training: The Most Consistently Underestimated Investment
I will say this as directly as I can: user training in SAP Rise migrations is consistently underfunded, and the organizations that underinvest in training consistently have worse post-go-live outcomes than those that invest appropriately. This is not a controversial position — it's supported by essentially every large-scale ERP implementation post-mortem study that has been published. And yet every project budget I've seen treats training as a line item to be optimized rather than a capability to be built.
The specific failure mode I see most often is confusing training material creation with training delivery. The project produces 40 eLearning modules and a library of process documentation, declares the training program complete, and moves on. Employees watch the modules, click through the assessments, achieve whatever completion percentage satisfies the project governance committee, and then arrive on day one of go-live with no practical ability to execute their processes in the new system because watching a recording of someone clicking through a transaction is not the same as doing it yourself.
What Effective Training Actually Looks Like
Effective training for an S/4HANA migration includes hands-on practice in a training system with realistic data, process-specific job aids that people can reference during live system use, role-specific curriculum that covers only what each user group actually does (not everything the system can do), and follow-up support during the first 30–60 days of production use when users encounter situations that their training didn't cover.
It also requires that training be delivered close enough to go-live that users don't forget what they learned, but far enough in advance that the training system is stable and representative of what they'll see on day one. The timing window that usually works is 3–4 weeks before go-live for intensive training delivery, with refresher reference materials available in the system from day one.
The Super User Network
The single highest-ROI training investment in most SAP implementations is the super user network: a group of 20–30 percent of end users in each functional area who receive deeper training, have early access to the system, and serve as the first line of support for their colleagues after go-live. Super users answer 80% of the "how do I do this?" questions that would otherwise route to the formal support structure, significantly reducing the support ticket volume and accelerating the productivity recovery curve.
Super users need to be identified early — at least three months before go-live — because they need the time investment to develop genuinely deep system knowledge. They're typically high performers who are already busy, and getting their manager's commitment to provide them with adequate time for training requires executive-level messaging about why this matters for the organization's success.
Things That Took Longer Than Expected
Rather than abstract warnings about scope risk, here's a concrete list of areas where actual Rise migrations consistently run over their initial timeline estimates:
- Integration re-wiring: Integrations that were "simple" on-premise become more complex when network topology, authentication models, and data format requirements change in the cloud environment. Budget 30–50% more time than your initial integration inventory suggests.
- Security role redesign: Most legacy SAP systems have security roles that were built organically over years and have role conflicts, excessive authorizations, and structural issues that need to be resolved before migrating. This work consistently takes longer than estimated because it requires business sign-off on every change to production authorization assignments.
- Printing and output management: Output management — managing how documents like invoices, POs, and shipping labels are generated and delivered — is a technically specialized area that is disproportionately likely to cause post-go-live incidents. It consistently gets less attention than it deserves during migration planning and testing.
- Legacy report replacement: Custom reports that users rely on daily need working replacements before go-live, and building those replacements in Fiori Analytics or SAP Analytics Cloud takes longer than building them in SE38 ABAP. The Fiori development toolchain is different, the data models are different, and the availability of developers with the right skills is more constrained.
The Post-Rise Operating Model: What Changed
The Rise migration changes not just the technology but the operating model for IT and for the relationship between IT and SAP. Understanding these changes before you commit helps you prepare the organization appropriately.
BASIS and Infrastructure
The infrastructure and BASIS operations that consumed significant IT staff capacity on-premise are now SAP's responsibility. This is a genuine benefit. The adjustment is that some things that IT could previously resolve directly — a hung process, a system performance issue, a transport management question — now require opening a support ticket and waiting for SAP to respond. Building effective SAP support ticket management processes, and managing the relationship with your SAP Technical Account Manager, becomes more important in the Rise operating model than it was on-premise.
Release Management
Rise operates on a managed release cadence — SAP delivers updates and patches on a schedule that you influence but don't control. This means your internal release management process needs to adapt: testing and validation of SAP-delivered changes becomes a recurring operational obligation rather than a sporadic project activity. Organizations that establish a mature Cloud ALM-based test management process post-go-live fare significantly better with the ongoing release cadence than those that treat testing as a project-phase-only activity.
Extension Model Discipline
On-premise, the temptation to solve problems with direct system modifications was always present and frequently yielded to. In Rise Private Edition, the Clean Core extension model creates structural barriers to the worst practices — but it also requires discipline about which extension approach is appropriate for each requirement. BTP extensions, ABAP Cloud in the embedded steampunk environment, and key user extensibility through Fiori Launchpad each have appropriate use cases and wrong use cases. Building internal competency in making these architectural decisions consistently is an ongoing requirement, not a one-time training event.
Migration Approach Comparison: Risks by Strategy
| Migration Approach | Timeline | Key Risks | Best For |
|---|---|---|---|
| Greenfield (new implementation) | 18–30 months | High scope risk; parallel operation cost; change management complexity | Orgs with heavily customized legacy systems or fundamental process redesign needs |
| Brownfield (system conversion via DMO) | 12–20 months | Data quality issues migrate with system; custom code volume; deferred process improvement | Orgs that need to preserve existing processes and data, with manageable custom code volume |
| Selective data transition (bluefield) | 18–28 months | High complexity; requires specialized tools and expertise; data mapping effort | Orgs that need selective process redesign while preserving specific data assets |
| Phased by business unit | 24–36 months total | Integration complexity during parallel operation; prolonged dual-system maintenance | Large orgs that cannot execute a single big-bang go-live; organizations with distinct business units |
| Two-tier ERP (corporate S/4 + subsidiary standalone) | 12–18 months per tier | Integration governance; reporting consolidation; inconsistent master data | Multinationals with subsidiaries that have genuinely distinct process needs |
What I Would Do Differently
Looking back across the experience, four things stand out as investments that would have paid back significantly if made earlier and more deliberately:
First, I would have run the full ABAP Test Cockpit clean core analysis eighteen months before the planned go-live and used the results to drive a business conversation about customization remediation options — not three months before go-live when the options were limited to "fix it now at high cost" or "migrate it and deal with it later."
Second, I would have started the data quality assessment and archiving initiative twelve months earlier than we did. The compressed timeline for data remediation directly increased migration risk, and the cost of addressing data quality issues post-go-live was substantially higher than it would have been pre-migration.
Third, I would have invested more heavily in the super user network and less in the eLearning library. The eLearning content had 90% completion rates and delivered modest practical capability. The super users in the departments where we invested in them were the single most effective support mechanism in the first 90 days post-go-live.
Fourth, I would have negotiated harder on the contract terms around scope and timeline flexibility before signature. The incentive to close the deal quickly is real, and the cost of revisiting terms after signature is high. Take the time to understand what you're agreeing to before you agree to it.
Key Takeaways
- The Rise contract bundles infrastructure and licensing but excludes migration execution costs, which can equal or exceed the contract value for mid-market organizations — budget comprehensively before committing.
- Data migration duration scales non-linearly with data volume: run a fresh sizing assessment within 90 days of migration start, and invest in archiving preparation as a critical-path activity, not an optional optimization.
- Custom code remediation scope is almost always larger than initial estimates; run ABAP Test Cockpit analysis early and use the results to drive business conversations about process decisions, not just technical ones.
- Testing phases get compressed when upstream work runs over schedule — protect testing by creating explicit risk-rated coverage matrices that make the consequences of compression visible to project sponsors before they approve timeline trades.
- User training is the most consistently underestimated investment in SAP migrations; effective training requires hands-on practice in a realistic environment, well-timed delivery, and a super user network that supports colleagues during the first 60 days post-go-live.
- The Rise operating model requires adapting internal processes for SAP-managed release cadence, support ticket management, and extension architecture discipline — these are ongoing organizational capabilities, not one-time transition tasks.
Managing SAP at scale? I built tools for this — Check it out →
댓글
댓글 쓰기