Hello Reader,

Let's be real — if you're reading this, things probably haven't gone according to plan. Your SUM run is stuck somewhere in the Execution phase, your client wants answers, and the clock is ticking.
You're not alone. This is one of the most common and stressful situations a BASIS administrator can face.

This guide will walk you through everything you need to know — not just the commands, but the logic behind them — so you can make confident decisions under pressure.

Moreover, this would be a Quick Answers to What You're Probably Googling Right Now:

• Can I reset SUM right now?
• What happens if I just restore the database?
• What if I've already deleted the SUM directory?

What Does a SUM Reset Actually Do?

A SUM reset is designed to bring the system back to a state where the upgrade can be restarted.

Depending on the phase and scenario, SUM can:

• Reverse upgrade activities
• Remove upgrade artifacts
• Clean up the shadow instance
• Restore upgrade consistency

A reset is different from:

• Stopping SUM
• Deleting the SUM directory
• Restoring only the database

When Should You Consider a SUM Reset?

A SUM reset is typically considered in the following situations:

1. Upgrade Stuck in Execution Phase
   You have spent considerable time analysing logs and retrying phases, but the upgrade is still blocked.
2. Downtime Window Is Running Out
   Business requirements may force you to abandon the upgrade and return the system to service.
3. Upgrade State Has Become Inconsistent
   Repeated failures, corrupted upgrade metadata, or unexpected SUM behaviour may require a complete restart.
4. Customer Requests Rollback
   Sometimes the safest option is to stop the upgrade and plan another attempt later.

When Is a Reset Actually Possible?

This is one of the most important things to understand before you do anything. SUM's ability to reset depends on two conditions:

Condition	Can You Reset?	Notes
Cleanup has NOT been run	Yes	This is the normal rollback path
Cleanup HAS been run (after success)	No	You must use a pre-upgrade system backup
You chose Reset, reset completed	Cleanup is now mandatory	You must run cleanup after a successful reset
SUM directory was deleted manually	Partially	Re-extract SAR file, then follow the stuck-phase procedure

Important: Never run the Cleanup option from SUM's More menu unless you are 100% sure you won't need to roll back. Once cleanup runs, the only way back is a full system restore from a backup taken before the upgrade began.

 

Why Restoring the Database Is Not Enough

One of the most overlooked aspects of SAP upgrades is the shadow instance.

During an upgrade, SUM creates a shadow system that consumes:

• CPU
• Memory
• Disk
• SAP resources

If you only restore the database:

✓ Database returns to its previous state

X Shadow instance may still exist

X Upgrade artifacts may remain

X Future upgrades may encounter issues

This is why a proper SUM reset is often necessary after restoring the database.

 

Best Practice Before Entering Execution Phase

Before any major upgrade activity begins, make sure you have:

Full Database Backup

This is your primary recovery mechanism.

Backup of the SUM Directory

I strongly recommend taking a backup of the complete SUM directory at the end of preprocessing.

If a rollback becomes necessary later, this backup can save a significant amount of time.

 

How to Reset SUM Correctly

Scenario 1: SUM Reset Option Is Available

This is the easiest situation.

From the SUM UI: More → Reset

Allow SUM to complete the reset process.

After completion:

• Upgrade changes are reversed
• Shadow instance is removed
• Upgrade state is cleaned up

Scenario 2: Upgrade Is Already Deep Into Execution

If rollback is required:

Step 1: Restore and recover the database.

Step 2: Restore the backed-up SUM directory.

Step 3: Start SUM using the restored backup.

Step 4: Execute the reset.

This ensures both the database and SUM state are returned to a consistent condition.

Manual Reset Procedure

In certain situations, you may need to perform a manual reset preparation.

Navigate to:

SUM/abap/bin

Execute:

SAPup reset prepare

Afterward:

1. Stop all SAPup processes at OS level.
2. Delete the SUM directory.
3. Extract a fresh SUM package if needed.
4. Start again from the beginning.

Common Mistake #1: Deleting the SUM Directory

Many administrators believe that deleting the SUM folder automatically resets the upgrade.

It does not.

SUM stores upgrade information inside the SAP system database.

When a new SUM package is extracted, it often reads the existing upgrade state and returns to the same phase.

Always perform a proper reset procedure rather than simply deleting SUM.

Common Mistake #2: Running Cleanup Too Early

After an update, SUM provides:

More → Cleanup

Be careful.

Once Cleanup has been executed:

• Reset is no longer available
• Rollback capability is removed

At that point, database restoration may be the only recovery option.

 

What If SUM Keeps Dropping Back into the Same Phase?

This happens when the Execution phase ran far enough to make changes to the system's upgrade versioning tables (UVERS), but not far enough to complete cleanly. Even after you clear the SUM directory and re-extract the SAR file, SUM reads those database tables and drops straight back into the last active phase.

This is not a bug. SUM is doing exactly what it's designed to do — resuming where it left off. The problem is that the state it's resuming from is inconsistent.

Ex: SAP Note 1790486 covers the scenario where SAP_ABA (or another software component) is in an undefined upgrade state that is not safe to proceed with.

In emergency situations, SAP may recommend running report RSUPGRES:

Important considerations:

• Execute with DDIC
• Use client 000
• Run in background
• Do not cancel the job manually

The report is intended to repair upgrade status inconsistencies and should be used carefully.

Note: RSUPGRES is a powerful and potentially destructive tool. Use it only as a last resort and follow every instruction. Do not improvise.

Afterward, many administrators also execute:

/$SYNC

and

/$TAB

to refresh buffers and synchronize system status.

 

A Word on Cleanup — Don't Confuse It with Reset

SUM has two end-of-process options that BASIS admins sometimes confuse:

Option	When It Appears	What It Does	Can You Reset After?
Reset	During the update process	Rolls back the upgrade, dissolves the shadow instance	Yes — but cleanup becomes mandatory afterward
Cleanup	After a successful update OR after a Reset	Removes SUM working files and state	No — reset is no longer possible after this

Note: Cleanup is a one-way door. Once you walk through it, you cannot come back without a full system restore. Always think twice before clicking it.

 

Key Takeaways

Most BASIS admins who've gone through a reset once develop a pre-Execution checklist they follow religiously. Here's what that looks like:

Before every upgrade:

✓ Take a full database backup

✓ Take a backup of the SUM directory

✓ Understand your rollback strategy

When an upgrade fails:

✓ Determine whether a SUM reset is still possible

✓ Do not immediately delete the SUM directory

✓ Consider the shadow instance impact

✓ Restore both the database and SUM state when necessary

Always remember that a successful rollback is not just about restoring the database. A complete recovery requires restoring upgrade consistency and ensuring the shadow instance is properly removed.

 

Have you run into a reset scenario that isn't covered here?

Drop it in the comments.