The SAP Commerce Upgrade Program: Discovery, Planning, Execution, Closing

A SAP Commerce upgrade fails as a program before it fails as code. The team dives into the technical work (which the effort-analysis and execution guides cover well) without first deciding what kind of upgrade this is, what success means, or how much of the accumulated customization is worth carrying forward. Months later the project is over budget because it quietly became a re-implementation nobody scoped. This guide is the program-management wrapper around the technical work: the four phases, the decisions each one forces, and the governance that keeps an upgrade from sprawling into an accidental replatform. It pairs with the effort-analysis guide (the detailed technical estimate) and the execution guide (the engineering); this is the frame that holds those together.

First, Decide Which Upgrade This Is#

Before estimating anything, discovery lands the project on one of three types, because the type determines everything downstream:

• Like-for-like (technical upgrade): move to a supported version, change as little else as possible. The goal is supportability; the scope discipline is ruthless "no new features." The cheapest and most predictable.
• Extended (technical upgrade): a technical upgrade that also adopts some new platform capabilities or pays down specific debt, without a full functional rethink. Middle ground.
• Functional upgrade: a technical upgrade plus new business capabilities, treated as a full-cycle project with its own discovery of new features, business cases, and enhancements. The most expensive and the one most prone to scope creep, because "while we're in there" is a powerful and dangerous phrase.

A short discovery questionnaire drives the choice. Five questions that discriminate well:

1. Does the data model need redesigning?
2. What is the level of technical debt in the code?
3. How much of the code is customization versus out-of-the-box?
4. What new SAP Commerce features or enhancements are needed?
5. What compliance and security requirements apply?

Answer these honestly and the type is usually obvious. The mistake is skipping the question and letting the project become a functional upgrade by accretion, with a like-for-like budget.

The Estimation Ladder#

Estimation happens twice, deliberately:

• Rough Order of Magnitude (ROM) in discovery: a T-shirt size (S/M/L) with an effort range per size, tied to the chosen upgrade type. This is enough to decide go/no-go and secure funding, and no more; a precise estimate before analysis is false precision.
• Detailed estimate in planning: the effort-analysis guide's technical method (pure-versus-customized diffs, layer-by-layer assessment) produces the real number that the plan is built on.

Keeping these separate protects you from two failures: committing to a ROM as if it were a plan, and delaying the go-decision waiting for detail you can only get by starting.

Discovery and the Inputs You Need#

Discovery is short and produces the type, the ROM, and the go-decision. To do it, the team needs the raw materials from the current solution, and gathering these is itself a small project in some organizations:

• The source code.
• A copy of the media directory.
• A database dump.

With those, the technical assessment can begin. Without them, discovery is guesswork, and it is remarkable how often "we'll get you the database next week" becomes the first schedule slip.

Planning: Where the Real Governance Lives#

Planning is the phase that decides whether the upgrade stays an upgrade. It has three governance jobs beyond producing a plan.

Initiation: agree the frame. Kick off with the customer and align on the classic six questions: the why (business goals), the what (scope and prioritization, security versus features), the how (approach and methodology), the when (milestones and resources), the cost (team, infrastructure, licensing), and the risks (business, project, technical). Critically, establish up front that an upgrade is driven primarily to control time, quality, and cost, and that scope is the variable that absorbs change. A team that has not agreed scope is negotiable will fight every trade-off mid-project.

The customization reckoning. This is the philosophical heart of a healthy upgrade, and it deserves to be a stated goal, not an afterthought:

• Reducing customizations reduces total cost of ownership over time; every customization carried forward is carried forward forever.
• Push for minimum viable product and maximum out-of-the-box use for faster delivery.
• Challenge every customization: is it now on the platform roadmap? The cost of waiting for a shipped feature is often lower than the cost of maintaining a custom one across this and every future upgrade.
• Zero tolerance for modifications that expand the original project scope.
• For functional upgrades, run a real discovery of new capabilities, business cases, and enhancements, with a proposal covering budget, scope, and resources.

An upgrade is the rare, sanctioned opportunity to delete debt. A team that treats it as "move everything forward unchanged" wastes that opportunity and pays for it at the next upgrade too.

Team and problem list. Build the team for the phases (planning, execution, closing) rather than one static roster, using the staffing guide for larger efforts and remembering one person can wear several hats if you plan it. And convene the whole team (business analysts, developers, support, PM, consultants) to write a problem list: every existing issue in the platform, the data, and the surrounding processes. This surfaces the real drivers, prevents the upgrade from solving only the technical team's pet problems, and feeds the scope decisions.

Define KPIs and what success looks like from the start, so closing has something to report against.

Execution: Deliver the Plan#

Execution is where most of the time goes, and it is the technical work the effort-analysis and execution guides detail: upgrade engineering, thorough testing (the migration-testing guide for data-heavy cases), and deployment. The program-level job here is holding the scope line established in planning (every "while we're in there" gets checked against the agreed frame) and managing the contingency deliberately rather than burning it silently. The output is a tested, upgraded codebase ready for the go-live discipline (the go-live readiness guide).

Closing: Turn It Back Into Business as Usual#

Upgrades are often declared done at deployment and left to dissolve, which wastes the learning and strands the operations team. Closing has two real deliverables:

• Reporting: results against the KPIs defined in planning. Did the upgrade achieve its stated goals (supportability, the specific features, the debt reduction)? This is also where the honest retrospective lives, blamelessly, so the next upgrade is cheaper.
• Final hand-off to BAU: the business-as-usual and application-management teams take over with the documentation, the runbook updates, and the knowledge to operate the upgraded solution. An upgrade that lands in production but never truly hands off leaves the project team as permanent life support, which is a failure disguised as a success.

The Program Checklist#

• Upgrade type explicitly chosen (like-for-like / extended / functional) via discovery, not by drift
• ROM estimate for the go-decision; detailed estimate for the plan; the two kept distinct
• Source code, media, and database dump gathered before assessment begins
• Initiation aligned on why/what/how/when/cost/risks, with scope agreed as the negotiable variable
• Every customization challenged against the roadmap; MVP and OOTB pushed; debt-reduction a stated goal
• Problem list built by the whole team; KPIs and success defined up front
• Scope line held through execution; contingency managed deliberately
• Closing reports against KPIs; genuine hand-off to BAU with documentation and runbooks

The technical guides tell you how to upgrade the code; this framework tells you how to run the project so the code work happens once, at the scope you chose, and leaves the solution cheaper to own than it was before. An upgrade managed as a program is an investment; an upgrade managed as a code exercise is a bill that arrives twice.