Mar 17, 2025 .

Do’s and Don’ts of an SAP HANA Technical Upgrade (Beyond the Basics)

A technical upgrade to SAP HANA is not just about migrating databases and running SUM tools. The real challenge is avoiding business disruptions, ensuring post-upgrade performance, and addressing hidden pitfalls that most consultants overlook.

Here’s a mix of functional and technical do’s and don’ts that go beyond the typical playbook.

Do’s – What Smart Consultants Focus On

1. Engage Business Users Early—Not Just IT Teams

Why It Matters: A technical upgrade might seem like an IT-only initiative, but process inefficiencies often surface post-upgrade.
DO involve key business users from finance, supply chain, and procurement early—they will flag missing configurations that IT might overlook.
DO simulate critical end-user scenarios (approvals, reporting, integrations) in the test environment before go-live.

Pro Tip: Test real-life cases, like “What happens if an approver rejects a PO?”—not just system transactions.

2. Clean Up Custom Code, but Don’t Blindly Delete

Why It Matters: SAP HANA handles standard code efficiently, but old custom programs might not work well.
DO analyze custom code using ABAP Test Cockpit—but also consult functional leads before decommissioning.
DO rewrite inefficient ABAP reports to leverage HANA views—but only where necessary.

Pro Tip: Removing unnecessary Z-programs might seem smart, but some custom reports exist because standard SAP reports were never enough for business users. Validate before removing.

3. Watch Out for Background Jobs That Could Break Post-Upgrade

Why It Matters: Some background jobs (batch processing, payment runs, MRP, settlements) might crash post-upgrade due to SQL query changes or performance bottlenecks.
DO check job runtime history before and after migration—some jobs will need fine-tuning.
DO validate scheduled job dependencies—especially interfaces with external systems (banking, third-party logistics, tax systems).

Pro Tip: Run a parallel background job test to compare runtime in ECC vs. HANA before final cutover.

4. Optimize Authorizations & Security—Before Go-Live, Not After

Why It Matters: Post-upgrade, some user roles and authorizations might change, causing unexpected business disruptions.
DO validate security roles before go-live—check T-codes, Fiori apps, and critical approval workflows.
DO use SUIM to track missing authorizations—especially in procurement, finance, and reporting.

Pro Tip: Post-upgrade security issues often surface when finance can’t approve payments, or warehouse users can’t issue stock. Fix before go-live.

5. Plan for Downtime—and Plan for Surprises

Why It Matters: Even with SUM with DMO, unexpected technical issues can extend downtime beyond what was planned.
DO perform a full dress rehearsal before the final cutover—ensure all stakeholders know their roles.
DO have a rollback plan—even if you never use it.

Pro Tip: If downtime exceeds the planned window, know which business processes can run manually (e.g., invoice processing) and which can’t (e.g., payroll processing).

Don’ts – Mistakes Even Experienced Consultants Make

1. Don’t Assume Standard SAP Will Work Out of the Box

Many assume that once on SAP HANA, all transactions will be faster. Reality? Some standard reports and queries will still be slow if not optimized.
DON’T rely only on automated tools—do a manual performance review for critical transactions like MIGO, VA01, and FBL1N.

Pro Tip: SAP HANA is fast, but bad process design will still create bottlenecks.

2. Don’t Forget Printing and Forms (They Break More Often Than You Think)

SAPscript, SmartForms, and Adobe Forms often break post-upgrade, causing chaos in logistics, invoices, and PO printing.
DON’T assume all forms will work—test key printouts well before go-live.

Pro Tip: Logistics teams panic when shipment labels don’t print. Test label printing on warehouse printers before final migration.

3. Don’t Migrate Without Aligning with External Vendors

Banks, tax authorities, and third-party logistics providers rely on SAP integration. A technical upgrade might break file formats, API calls, or security certificates.
DON’T assume interfaces will still work—notify external vendors in advance and test their connectivity post-upgrade.

Pro Tip: Missing even one bank file format update could mean vendor payments failing post-go-live.

4. Don’t Assume All Data Will Migrate Perfectly

Even with SAP HANA’s tools, some master data fields may not align perfectly—especially in finance (GL accounts, cost centers) and supply chain (BOMs, routings).
DON’T migrate without a reconciliation plan—perform data sanity checks on critical master data before go-live.

Pro Tip: Finance teams will flag missing data only when they can’t close books on Day 1. Preempt the issue with master data validation.

5. Don’t Underestimate User Training and Hypercare

IT teams often assume that if the system is live, business users will adapt immediately. But HANA introduces UI changes, performance variations, and process shifts.
DON’T launch without a hypercare period—keep functional leads available to handle user issues in the first 2 weeks.

Pro Tip: The biggest post-upgrade complaints aren’t technical but user-driven—slow T-codes, missing reports, or changed UI behavior.

Final Takeaway: A Technical Upgrade is Never Just Technical

A successful SAP HANA upgrade requires both technical and business alignment.
By considering both technical optimizations and business process continuity, you ensure a smooth transition—one that avoids downtime surprises, user confusion, and post-go-live escalations.

Would you like to refine or expand any sections? Let me know before I move on to the SAP HANA Functional Upgrade (Greenfield) blog!