SAP HANA Performance Optimization After Migration

Custom logic written for a row store must be rewritten to benefit from a column store, and SAP HANA Performance Optimization starts with that fact. It explains why so many teams finish a HANA migration, check the dashboards, and find the month-end close runs about as slowly as before. The platform changed. The code did not.

If you already run on HANA and see little gain, you're not alone. Most of the time the database is fine. The custom ABAP sitting on top of it still behaves like it's talking to a 2008 database. This post explains why, what to fix, and what you can do on ECC before you move. It also shows how 2iResourcing approaches the work.

Why does a HANA migration not speed up custom code?

A HANA migration moves your data and runtime onto a new in-memory, column-oriented database. It does not rewrite your custom programs. Code built for row-based databases keeps its old habits, so it carries the same slow patterns onto the faster platform and delivers little improvement.

Think about how the old model worked. On a row-store database, developers pulled records into application memory and processed them there, because the database was the scarce resource. They fetched rows one at a time, looped through them, and summed totals in ABAP. That was sensible then.

A column store reverses the logic. HANA scans and aggregates huge volumes inside the database, and it does so very fast. When your code drags data up to the application server to do the same work, you pay for the trip and waste the engine's strength.

So the migration is a platform event. Your code remains a separate asset with its own condition. Treat it that way, and you plan the work correctly.

What the migration does change

The infrastructure underneath improves. Standard SAP content, which SAP itself rewrote for HANA, often runs faster right away. Some batch jobs and standard reports shrink in runtime without any effort from you.

Custom Z programs, user exits, and heavily modified standard flows are a different story. Nobody touched them, so nothing about them improved. Your business still runs on them every day, and users still wait on them.

Why the gap surprises project sponsors

Business cases for HANA often promise faster reporting across the board. Sponsors then see standard transactions speed up and assume the rest will follow. When the custom month-end report still takes forty minutes, the project looks like a miss.

The miss isn't in the migration. It's in the scope. Nobody put custom code remediation into the plan, so nobody owned it. A clear scope conversation before cutover prevents that awkward review six months later.

Which anti-patterns hold custom code back?

Three anti-patterns cause most of the disappointment: database calls inside loops, full-table scans, and aggregation in ABAP instead of the database. Each one is cheap on a row store at small scale and costly on HANA at volume. Fixing them is the core of SAP HANA Performance Tuning.

Database calls inside loops

A developer loops through 50,000 sales orders and runs a SELECT for each customer inside the loop. That means 50,000 round trips between the application server and the database. Each trip is small, but together they stall the report.

The fix is a single set-based query that joins the data once and returns the result in one call. The database does the heavy lifting, and the loop disappears. Developers often call this the single most valuable change in a remediation project.

Full-table scans

A full-table scan reads every row of a table to find a few matches. Row stores punished this, so good developers added indexes and filtered carefully. Poorly written custom code still scans anyway, often because it selects with no WHERE clause or filters after fetching.

On HANA, scans of narrow columns are quick. Scans of wide tables with unneeded fields are not. Selecting only the columns you need changes the result sharply.

Aggregation in ABAP

Summing, grouping, and counting inside ABAP loops is the third offender. Code reads millions of rows, then totals them in an internal table. HANA can do the same sum inside the database in a fraction of the time.

Pushing that logic down is called code pushdown. In plain terms, code pushdown means moving calculations from the application layer into the database layer so the data never travels.

What can you fix on ECC before you migrate?

You can fix a good share of these problems on ECC today. Cleaning up loops, selecting only needed fields, and removing redundant queries all help on any database. Doing this first shrinks the work after cutover and lowers risk. For a broader view of how this fits into the move itself, see PwC's S/4HANA migration guidance.

Here is a practical order of work on ECC:

1. Pull usage data and rank custom programs by how often they run and how long they take.
2. Retire anything nobody has executed in the past year.
3. Scan the top programs for SELECT statements inside loops and rewrite them as joins or FOR ALL ENTRIES with care.
4. Replace SELECT * with explicit field lists.
5. Move simple totals out of internal tables and into the query.
6. Retest each change against production-sized data, not a small sandbox client.

Step two surprises most teams. In many long-running systems, a large share of custom objects never run at all. Deleting them costs nothing and shrinks the remediation scope.

Use the tools SAP gives you

SAP provides code inspection checks and a custom code migration worklist that flag HANA-relevant problems. Run them early. They won't fix anything on their own, but they give your developers a ranked list instead of a guess.

Pair the tool output with runtime traces from real business hours. A program that looks bad in static analysis but runs once a quarter matters less than a mediocre report that 300 users open every morning.

How do you tune custom code after you go live?

You tune after go-live by measuring first, then fixing the slowest and most frequent programs in order. Trace actual runtimes, find the expensive database calls, push logic down where it helps, and retest. This disciplined loop delivers real SAP HANA Performance Optimization instead of hopeful guesses.

Many teams skip measurement and start rewriting whatever annoys them most. That wastes budget. The program everyone complains about is not always the one burning the most system time.

A repeatable tuning cycle

1. Capture a baseline: runtime, memory use, and database time for each target program.
2. Identify the top offenders by total impact, meaning runtime multiplied by frequency.
3. Rewrite the worst patterns, starting with loops and full-column selects.
4. Move heavy calculations into the database using the pushdown techniques HANA supports.
5. Rerun the baseline and record the gain.

Record every result. A simple before and after table builds the evidence you need to justify the next round of work. It also shows finance leaders where the money went.

Know when to stop

Some programs gain little from further work. If a job runs overnight and finishes before anyone needs it, leave it alone. Effort belongs where users feel the delay, such as dialog transactions and reports used during close.

Which reports and processes deliver the biggest returns?

The biggest returns come from high-volume financial reports, reconciliation jobs, and anything that aggregates large tables. These workloads read a lot of data and total it, which is exactly what HANA does best. Focused SAP report optimization on these first produces results users notice quickly.

Look at the candidates by business impact:

• Month-end and quarter-end close reports in finance
• Open item and aging reports that scan large accounting tables
• Inventory valuation runs in materials management
• Pricing and billing jobs with heavy condition logic
• Custom dashboards that pull from several tables at once

A finance team that waits two hours for an aging report will notice when it drops to minutes. That change builds goodwill for the whole program. It also frees analysts to work on analysis rather than watching progress bars.

Pair code fixes with a readiness check

Before you invest, run a SAP readiness assessment. It maps which custom objects matter, which carry risk, and which you can retire. The result gives you a defensible plan rather than a long wish list.

Teams that skip this step often tune the wrong programs. They spend weeks on a report that three people use, while the close process keeps dragging.

Who should own the remediation work?

Ownership should sit with a team that understands both ABAP and HANA, plus the business process behind each program. Pure developers miss business context. Pure functional leads miss technical cause. You need both in the same room, with a clear owner for each program.

Many internal teams carry this load on top of daily support. They're good, but they're stretched. Specialist capacity for a defined window often works better than slowing every other project.

An experienced SAP Service Provider can supply that capacity, bring a tested method, and train your team as the work proceeds. When 2iResourcing places SAP developers on remediation projects, the aim is a clean handover, so your staff can keep the code healthy afterward.

What to look for in a specialist

Request proof of real HANA remediation work, not just migration experience. Also find out how they measure gains and how they document changes. Then confirm who will do the work, because the person in the pitch is not always the person on your project.

For consultants, the opportunity is clear. Developers who can read an execution plan, rewrite a loop, and explain the gain to a finance director are in short supply. Those skills command strong rates across the market.

Where does broader strategy fit in?

Code remediation works best inside a wider plan for how your systems serve the business. A fast database matters less if reporting remains fragmented across tools. Many organizations tie this work into a Digital Transformation Framework so each fix supports a clear business goal.

Analytics follows naturally. Once data returns quickly, teams can build better dashboards on top of it. Some firms extend this with SAP Analytics Cloud for Tech teams and finance users who want live reporting without exports.

Mature organizations treat this as an ongoing discipline. They measure, fix, and re-measure with each release. That habit is what Enterprise Digital Excellence looks like in practice: systems that keep improving after the project team leaves.

Frequently Asked Questions

Q. Why is my system not faster after moving to HANA?

A. The migration moves the platform, not your custom code. Programs written for row-based databases still pull data into ABAP and loop through it, so they gain little until developers rewrite them.

Q. What is code pushdown in SAP HANA?

A. Code pushdown means moving calculations from the ABAP application layer into the database layer. The data stays in HANA, so you avoid slow transfers and use the in-memory engine as designed.

Q. Can I fix custom code before migrating from ECC?

A. Yes. Removing unused programs, replacing SELECT * with field lists, and fixing queries inside loops all help on ECC. They also reduce the remediation work after cutover.

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

A. Rank programs by runtime multiplied by how often they run. Combine SAP's custom code checks with real production traces so you target the programs users actually feel.

Q. Can 2iResourcing help with HANA remediation staffing?

A. Yes. 2iResourcing places SAP developers and consultants with HANA remediation experience for defined project windows. That gives your team extra capacity without slowing other work.

What a post-migration code review gives you

A HANA migration gives you a faster engine. Your custom code decides whether you actually use it. Loops, scans, and ABAP aggregation drag the old model onto the new platform, and only deliberate rewriting removes them.

The path is practical. Measure first, retire what nobody uses, rewrite the worst patterns, and push heavy calculations into the database. Repeat the cycle with each release, and the gains hold.