Untangling a Legacy Accelerator Storefront: The Customization Archaeology Before Any Storefront Decision

Every storefront decision (upgrade the accelerator, migrate to composable, or nurse the current build another year) rests on one number nobody has: how deeply has your accelerator been customized, and how much of that customization fights the platform rather than extending it? The storefront strategy guide frames the decision and the accelerator-to-composable guide covers the target build, but both assume you know your starting point. Usually you do not, because accelerator customization accretes invisibly over years, and the JSP that looks like a small tweak turns out to have a rewritten out-of-the-box controller underneath it. This guide is the archaeology: the method for measuring accelerator debt, layer by layer, so the storefront decision is made on evidence instead of optimism.

The urgency is real: the accelerator is deprecated, with the announced removal on the 2027 timeline, so this assessment is not academic. Whether your path is "modernize the accelerator to buy time" or "migrate to composable now", the effort estimate for either depends entirely on the debt this method reveals.

The Core Technique: Pure Versus Customized#

The single most useful move, borrowed from the upgrade effort-analysis method, is a diff against a clean baseline:

1. Generate a pure accelerator from your source version. This is the out-of-the-box storefront as SAP shipped it for the platform version you are actually on. It is your "before customization" reference.
2. Diff your project storefront against it. Every difference is customization: intentional features, accidental drift, and modified out-of-the-box components all surface. This is the debt inventory, and it is almost always larger than the team remembers.
3. Generate a pure target storefront (a clean responsive accelerator on your target version, or a fresh composable storefront if that is the destination) and diff the two pure versions against each other. This isolates what the platform changed independently of you, so you can separate "SAP moved this" from "we changed this", which are very different migration costs.

The output is a map: your customizations, categorized as reusable-as-is, needs-rework, or fights-the-platform-and-must-be-rethought. That map is the estimate. Skipping it and estimating from memory is how storefront projects miss by a factor of two.

The Historical Complication: Split Themes#

An extra layer of difficulty hides in older estates: the pre-responsive accelerator served entirely separate pages, stylesheets, and scripts for mobile and desktop, and every feature change had to be mirrored in both channels. The responsive accelerator replaced this with one source of truth (a single JSP, one LESS/CSS file, one JavaScript file, with Bootstrap and CSS media queries handling device differences). If your estate is old enough to still carry split-theme customizations, the migration is not just moving code forward; it is collapsing two parallel customization trees into one, and every mobile-specific hack has to be reconciled with its desktop twin. Estates that already run the responsive accelerator skip this pain; estates that do not should budget for it explicitly, because it is invisible until someone opens the mobile theme folder.

The Layer-by-Layer Risk Map#

Storefront customization lives in five layers, each with its own migration hazard. Assess each separately, because they fail differently.

JSPs, tags, and fragments. The rule of thumb that saves estimates: for every custom JSP and tag file, assume rework, not copy-paste. Out-of-the-box stylesheets and component markup changed across versions, so a custom JSP that rendered correctly on the source version can break subtly on the target. And the sharpest trap: modified out-of-the-box components. If the team altered shipped components in place (common, and rarely documented), every such change must be detected (the diff finds them) and manually reapplied, because you cannot simply take the new out-of-the-box version. Untouched out-of-the-box reuse migrates cheaply; in-place modification is expensive precisely because it hid the cost.

Controllers. Storefront migration reaches the controllers, and heavily customized controllers that extend or reuse platform controllers are where "not trivial" becomes "not possible without a rewrite." Platform controller code changed across versions; custom controllers built on top of it inherit those changes as breakage. The assessment must identify every custom controller, its dependencies on platform controllers, and its influence on component behavior (controllers commonly steer JSP/tag rendering). Some custom controllers are so entangled with old accelerator code that they rule out reusing the new code, which is a red flag pointing toward "rethink", not "port."

Stylesheets. Since platform 6.1 the accelerator uses LESS rather than plain CSS. Estates still on plain CSS should port to LESS as part of modernization (it aligns with platform standards and eases all future work), but under time pressure the old CSS can be made to work in the correct folder structure as a stopgap. The strategic note: every stylesheet left as legacy plain CSS is a small debt that compounds at the next migration, so pay it down when you have the chance.

JavaScript. Base library versions moved (jQuery being the usual culprit), so every piece of custom JavaScript needs review against the target's libraries. Two specific hazards: scripts embedded inside JSP files (which cannot be minified by the build and should be extracted to real files as part of the work), and modifications to out-of-the-box JavaScript (the same detect-and-reapply problem as JSPs). Custom JavaScript is easy to underestimate because it is scattered; the diff is what finds all of it.

CMS components and navigation. Usually the most complicated and costly layer, because many components were reworked, deprecated, or deleted across versions, affecting both the storefront rendering and the SmartEdit editing experience. Navigation is the frequent flashpoint: its whole structure was reworked, so projects with custom navigation logic face real effort, while projects that cleanly reused out-of-the-box navigation get off lightly. Assess which CMS components your pages use, which of those changed or vanished in the target, and how much custom component logic exists.

From Assessment to Decision#

The layer map feeds directly into the storefront strategy decision:

• Low debt (mostly clean out-of-the-box reuse, responsive already, LESS already, little custom controller logic): both paths are cheaper. Modernizing the accelerator to a current version buys time affordably, and the eventual composable migration is also less daunting.
• High debt (split themes, in-place-modified out-of-the-box components, heavily entangled controllers, extensive custom CMS logic): the accelerator upgrade is itself a major project, which changes the math. If you are going to spend heavily untangling the accelerator anyway, that budget may be better spent migrating to composable directly, where you rebuild on a supported, non-deprecated foundation rather than modernizing a storefront with a 2027 expiry.

The insight the assessment delivers: high accelerator debt is an argument for composable, not against it. Teams often reason "we are too customized to migrate", when the customization debt is precisely what makes staying expensive. The diff turns that gut feeling into a number both paths can be estimated against.

The Assessment Checklist#

• Pure accelerator generated for the source version; project storefront diffed against it; customizations inventoried
• Pure-to-pure diff (source vs target) run to separate platform changes from project changes
• Split-theme legacy identified and its collapse-into-responsive cost budgeted, if applicable
• JSPs/tags: custom files listed, in-place OOTB modifications flagged as detect-and-reapply
• Controllers: custom controllers, platform dependencies, and reuse-blocking entanglements identified
• Stylesheets: plain-CSS-vs-LESS status recorded; port planned or stopgap accepted knowingly
• JavaScript: custom JS reviewed against target libraries; embedded-in-JSP scripts flagged for extraction
• CMS components and navigation: changed/deprecated components mapped; custom navigation logic quantified
• Debt total mapped to the storefront decision (modernize accelerator vs migrate to composable) with the 2027 deadline in view

You cannot decide a storefront's future by looking at its front page; the debt is in the layers underneath, and it is the debt, not the pixels, that determines what modernization or migration actually costs. Run the archaeology first, and the storefront decision stops being a debate and becomes arithmetic.