Your SAP Is on HANA but Still Slow: Fixing Custom Code Anti-Patterns

Many teams complete a HANA migration expecting reports to run in seconds. Then the first Monday morning batch finishes at the same time it always did. The platform changed. The code did not. That gap, between hardware potential and actual runtime, is where most SAP performance problems live. It is usually a code problem, not a hardware problem.

Custom ABAP written for a row-store database does not automatically benefit from HANA's column-store architecture. The logic still runs as it was written, often years ago. Before ordering more infrastructure, look at what your code is doing to the database. Teams that have invested in SAP Skills to diagnose and rewrite these patterns have seen results that no hardware upgrade could match.

Why HANA Does Not Fix Bad Code on Its Own

HANA is a fast in-memory database engine that stores data in columns rather than rows. It allows aggregation and filtering of large datasets far faster than traditional relational databases. But a fast engine pulling a heavy load still moves slowly. The three anti-patterns that appear most often in custom code are database calls inside loops, full-table scans, and aggregation logic written in ABAP instead of pushed down to the database layer.

Each one shares the same root cause: the code was written for a world where the database was a passive store and ABAP did the thinking. HANA reverses that model. The database is now the fastest place to aggregate, filter, and sort. When code ignores this, it sends millions of rows to the application server, processes them there, and sends results back. Those round-trips harm performance regardless of the hardware.

SAP's own performance benchmarks show that poorly written custom code can eliminate 80 to 90 percent of the performance gains expected from a HANA migration, according to SAP's ABAP Performance Optimization Guide. The platform delivers its potential only when code is written to use it correctly.

Database Calls Inside Loops

A SELECT inside a LOOP is the most common anti-pattern in legacy ABAP. The program fetches a list of records, then queries the database once for each record to get related data. On a production report touching 200,000 orders, that means 200,000 individual database calls. HANA's speed does not help because the bottleneck is the number of round-trips, not the speed of each one.

The fix is a single JOIN or a FOR ALL ENTRIES statement that retrieves all related data in one call. It is one of the fastest wins available in a custom code review. A logistics company running nightly replenishment reports might cut a 45-minute batch job to under four minutes by collapsing nested SELECT statements into a single query with proper key filtering.

Full-Table Scans and Missing Index Use

The second anti-pattern is querying large tables without using the right key fields. When a WHERE clause does not match a table's primary key or a secondary index, the database reads every row to find matching ones. HANA's column-store architecture helps aggregation far more than unfiltered scans.

Review which fields appear in WHERE clauses and whether those fields are indexed. The fix is sometimes an index addition, but more often it is a query rewrite that filters on key fields earlier. For instance, a custom report on the VBAP sales order item table that filters only on material number might skip the sales document key. Adding the document key to the WHERE clause, or restructuring the query to use the primary key first, can reduce scan time by an order of magnitude.

How to Find the Code Worth Fixing First

Not all slow code costs the same. A report that runs in 90 seconds but executes once a month is a lower priority than a transaction that runs in 12 seconds but fires 4,000 times a day. The right metric is runtime multiplied by frequency. That product shows where system load is concentrated.

SAP's tools surface this data. The ABAP runtime analysis (transaction SAT), SQL trace (ST05), and workload monitor (SM66 and SM50) show which programs consume the most database time. Ranking by runtime times frequency typically produces a short list. In most systems, 10 to 20 programs account for the majority of custom code database load.

Aggregation in ABAP Instead of the Database

The third major anti-pattern is summing, grouping, or filtering in ABAP after pulling raw data from the database. A program might select every line item from a billing table, load it into an internal table, and loop through it to calculate totals by customer. On a system with five million billing documents, five million rows travel to the application server before a calculation happens.

HANA can perform that aggregation in the database layer in milliseconds. The rewrite uses a SELECT with GROUP BY and SUM pushed directly into the SQL statement. Only the summarised result set travels to the application server. Data volume crossing the interface drops from millions of rows to hundreds, potentially turning a two-minute report into a three-second one.

This pattern is especially common in finance and controlling reports. Custom code was built before HANA existed, so developers had no reason to think about push-down optimisation. SAP provides additional background in its SAP HANA overview, including how the platform is designed to process data in memory. Revisiting those programs with a HANA-aware developer is one of the highest-return activities in a post-migration tuning project.

The Role of Code Inspector and ABAP Test Cockpit

Manual code review does not scale. A large SAP system might have 50,000 or more custom objects. SAP provides two tools that automate the initial scan: Code Inspector (transaction SCI) and the ABAP Test Cockpit (ATC). ATC is the successor tool used in newer releases and in SAP S/4HANA Cloud environments.

ATC runs static checks against custom code and flags patterns known to perform poorly on HANA. These include SELECT * statements that retrieve all columns when only two are needed, implicit client handling that bypasses index use, and obsolete function modules with performance issues. The tool produces a prioritised list of findings with severity ratings and recommended fixes.

Running ATC before a migration gives you a baseline. Running it again after targeted rewrites shows progress. Teams working toward SAP S/4HANA Cloud readiness often use ATC output as a formal gate, requiring high-severity findings to be resolved before cutover sign-off. This turns code quality into a trackable project milestone.

What ATC Cannot Catch

Static analysis has limits. ATC finds structural problems in the code, but it cannot measure runtime behaviour under real data volumes. A query that looks clean might still perform badly because the underlying table has grown to 800 million rows. That problem only appears in runtime traces against production-scale data.

ATC and runtime analysis tools work best together. Use ATC to find structural anti-patterns at scale, then use SAT and ST05 to profile high-frequency programs against real data. The combination provides both breadth and depth: you catch structural problems and measure what is actually slow.

Building a Sustainable Code Quality Process

One-time tuning projects have a short shelf life. New custom code gets written every quarter. Without a process to catch anti-patterns before production, the same problems return. Teams that maintain good HANA performance treat code quality as an ongoing discipline.

A practical approach has three components. First, ATC checks run automatically in the transport system and block custom objects with high-severity findings from reaching production. Second, developers receive training on HANA-specific ABAP patterns and write push-down logic from the start. Third, a quarterly performance review examines the top 20 programs by database load and flags regressions.

This approach is also important for organisations running SAP HANA Cloud Solutions. Cloud environments surface performance problems faster. There is no option to throw hardware at a slow query on a managed cloud platform, so the code has to be right.

When to Bring in External Expertise

Not every organisation has HANA-aware ABAP developers on staff. Many companies completed their HANA migration with a project team that has since moved on. The knowledge of which programs were rewritten, deferred, or never reviewed often leaves with that team.

Bringing in an external specialist for a focused code review can be faster and more cost-effective than rebuilding that knowledge internally. A specialist with HANA performance experience can run the ATC scan and profile top programs, producing a prioritised remediation plan in two to three weeks. The internal team can then use that plan as a roadmap for the rewrites.

Good SAP Support from a partner who understands both the technical and business context makes a real difference. The best external reviewers explain the business impact of each finding in terms project sponsors can act on, making it easier to secure a remediation budget.

Connecting Code Quality to Your Broader SAP Strategy

Performance tuning is not an isolated technical exercise. It connects directly to the business case for your SAP investment. If your system is slow, users work around it. They export data to spreadsheets, build shadow processes, and stop trusting the system as a source of truth. That erosion of trust is harder to fix than the code itself.

Organisations planning a move to SAP S/4HANA Cloud should treat custom code remediation as a prerequisite. The cloud platform enforces stricter code quality standards and surfaces performance problems more visibly. Code that limped along on-premise may fail ATC checks or hit resource limits in the cloud environment.

The same logic applies to teams exploring SAP Business AI capabilities. AI-driven analytics and embedded machine learning features depend on clean, fast data access. If underlying queries are inefficient, the AI layer cannot compensate. Getting the code right is the foundation for every other capability.

For organisations working with a SAP system integrator USA, the code quality conversation should happen early in project scoping. A partner who asks about your custom code volume and ATC findings before proposing a timeline understands where the real project risk sits.

Frequently Asked Questions

Q. Why does my SAP system run slowly after migrating to HANA?

A. The most common reason is custom ABAP code that was written for a row-store database. It has not been updated to use HANA's column-store strengths. Anti-patterns like SELECT statements inside loops, full-table scans, and ABAP-side aggregation all cause the same performance problems on HANA that they caused before the migration. Rewriting those patterns to push work down to the database layer is the most effective fix.

Q. What is the ABAP Test Cockpit and how does it help?

A. The ABAP Test Cockpit (ATC) is SAP's static code analysis tool that checks custom ABAP objects against a set of performance and quality rules. It flags patterns known to perform poorly on HANA, such as SELECT * statements and missing client specifications. Each finding receives a severity rating. Teams use ATC output to prioritise which programs to rewrite before a migration or before moving to SAP S/4HANA Cloud.

Q. How do I know which custom programs to fix first?

A. Multiply the average runtime of each program by how often it runs per day. The programs with the highest combined load are the ones worth fixing first, regardless of how slow any single execution feels. SAP's workload monitor (SM66 and SM50) and the SQL trace (ST05) give you the data to build that ranking quickly.

Q. Can a SAP partner help with custom code performance tuning?

A. Yes, and for many organisations it is the fastest path to results. 2iSolutions works with clients to run ATC scans and profile high-frequency programs. We produce a prioritised remediation plan that the internal team can act on. A focused external review typically takes two to three weeks and produces a clear list of fixes ranked by business impact.

Q. Does moving to SAP HANA Cloud Solutions require custom code changes?

A. It almost always does. Cloud environments enforce stricter code quality standards than on-premise systems. They surface performance problems more visibly because there is no option to add hardware to compensate. Running ATC checks and resolving high-severity findings before migration is the standard approach for teams moving to managed cloud platforms.

What Good Performance Actually Means for Your SAP Investment

Slow SAP systems do not just frustrate users. They erode confidence in the data, push work into spreadsheets, and quietly undermine the business case for the platform. When a finance close takes three hours because the consolidation report is slow, or when a warehouse team stops using the system because the goods receipt transaction times out, the problem is visible at the business level. The root cause is technical.

Custom code remediation is the work that closes the gap between what HANA can do and what your system actually delivers. It is not glamorous, and it rarely gets a project launch announcement. But the results are concrete: faster batch jobs, shorter report runtimes, lower database load, and users who trust the system enough to use it the way it was designed to be used.

2iSolutions brings the technical depth and the business context to make that work count. Whether you are preparing for a cloud migration, troubleshooting a post-migration performance problem, or building a sustainable code quality process for the long term, the starting point is always the same. Understand what your custom code is actually doing, and fix the patterns that are working against you.