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.

Check the removal date against current SAP guidance before you build a business case on it, because this one has moved before. What is not in dispute: the Accelerator UI AddOns and template extensions were deprecated in the 2205 release of May 2022, and SAP ships no new features on them. The removal timing has been restated more than once since, so confirm it in the SAP Help deprecation notes for your target version rather than quoting a date from any guide, this one included. The OCC template extensions were deprecated in the same 2205 release and carry their own schedule, so a storefront depending on those has a second date to check.

This changes the argument rather than ending it. "Migrate before the platform deletes it" is no longer available, so the case for moving has to rest on what the debt actually costs you per year, which is exactly what the method below measures. Deprecated code does not get new features, and every year on it is a year of paying to maintain a frontend SAP has stopped investing in.

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.

Step 1 is two commands, and getting them exactly right is what makes the diff readable:

# pristine storefront from the accelerator template, on the version you are actually running
ant modulegen \
  -Dinput.module=accelerator \
  -Dinput.name=baseline \
  -Dinput.package=com.acme.baseline \
  -Dinput.template=develop

# then install the SAME addons the project has, in the same order
ant addoninstall \
  -Daddonnames="smarteditaddon,b2bacceleratoraddon" \
  -DaddonStorefront.yacceleratorstorefront="baselinestorefront"

# diff source trees only; exclude served/compiled output
diff -qr baselinestorefront/web acmestorefront/web | grep -v '/webroot/_ui/'

Two things there catch people out. Install the same addons. Skip that and every addon-supplied view under views/addons/ shows up as a false positive, and a report with four thousand findings gets read by nobody. Order matters too, because when two addons override the same view the last install wins, so a baseline built in a different order differs from production for reasons that have nothing to do with your code.

The _ui exclusion is the other half. That folder holds served and compiled assets, including CSS generated from LESS, so leaving it in buries the twenty decisions you care about under a few thousand generated files. Diff the sources; the build output is derived from them by definition.

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. They are also five different folders, and knowing which folder answers which question is what turns a two-week archaeology exercise into a two-day one. In a generated yacceleratorstorefront (under modules/base-accelerator/ on current releases, bin/ext-template/ on older ones):

Anything still sitting under a desktop path rather than responsive is a legacy split-theme leftover, and finding one answers the split-theme question in about a minute rather than by asking who remembers. A populated desktop tree in a project that believes it is fully responsive is dead weight at best and a second customization tree at worst.

The bottom three rows are the mirror rule, and it is worth stating as a rule because it makes addon debt readable. An addon keeps its files under <addon_name>/acceleratoraddon/web/webroot/..., and the build copies each one into the matching storefront folder with addons/<addon_name> spliced into the path. So the storefront tree tells you, by directory name alone, which addon owns every copied file. Nothing in views/addons/ is a mystery. Everything customized outside it is.

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.

The severity of that trap depends entirely on how the change was made, and the diff has to grade it, not just find it. There are three grades, and they cost very different amounts:

1. Overridden through an addon. The addon keeps its own copy under <addon_name>/acceleratoraddon/web/webroot/WEB-INF/views/responsive/, and the build copies it into the storefront under views/addons/<addon_name>/responsive/. The shipped file is never touched, so the platform's new version arrives cleanly and the override sits beside it as a reviewable delta owned by a named addon. This is the cheap grade, and the directory name tells you the owner without asking anyone.
2. Edited in place in the storefront extension. The shipped file is gone, replaced by the project's version. The diff finds it, but there is no delta to review: you get "these 400 lines differ" and somebody has to reconstruct intent from the result. This is the detect-and-reapply grade, and it is where estimates die.
3. Edited in place in a generated file. Worse than grade 2, because storefront extensions are generated from a template and a regenerating build can quietly undo the edit. Over a few years that produces files matching neither the shipped version nor any single intention, and the git history is the only witness.

Grade every finding before estimating. Two projects with an identical count of "modified components" differ by a large factor if one used addons and the other did not, and the count alone hides that completely.

One collision to check while you are in there: when several addons override the same view, only one copy ends up in the storefront, and which one depends on install order rather than on anything anybody chose. If the estate carries more than a handful of addons, list the overridden views and look for duplicates. A view claimed twice is a latent behavior change waiting for the next change in addoninstall ordering, and it is far cheaper to find now than during the migration.

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.

Knowing the file roles turns this row from a guess into a count. The CSS is generated from two trees, _ui-src/responsive/themes/<theme>/less/ and _ui-src/shared/less/, and inside a theme the shipped files divide the work: style.less references the LESS in the ybase library, which in turn references Bootstrap; theme-variables.less holds the storefront's colour variables and values; variables.less imports generatedVariables.less (the generated global variables) and variableMapping.less (the mapping from variable names to LESS-appropriate names).

That division is the audit. A project that expressed its branding by editing theme-variables.less has done the cheap, intended thing, and those values port to any target because they are colours rather than code. A project that instead overrode ybase rules wholesale has written a parallel stylesheet, and none of it survives a composable migration, where styles are component-scoped. Count the two separately. They are not the same debt, and a file count that mixes them tells you nothing.

Addons follow their own convention here, which is worth checking because it is easy to miss: an addon that supports responsive pages carries <addon_name>.less in acceleratoraddon/web/webroot/WEB-INF/_ui-src/responsive/less/, and those get pulled in through the ybase addons.less registry. Addon styling that lives anywhere else was hand-placed and is a finding.

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 spending heavily on code that receives no further investment.

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
• Overrides graded: addon override versus in-place edit, and any view claimed by two addons listed
• views/addons/ and the desktop tree both inspected, not assumed empty
• Controllers: custom controllers, platform dependencies, and reuse-blocking entanglements identified
• Stylesheets: plain-CSS-vs-LESS status recorded; partials counted by reachability from style.less, not by file count
• 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
• Deprecation status re-checked at SAP rather than assumed: confirm the current removal date for both the Accelerator UI and the OCC template extensions
• Debt total mapped to the storefront decision (modernize accelerator vs migrate to composable) on annual carrying cost, not on a removal date

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.