Hybris Maintenance and Support: Building the AMS Model Right

The Hybris project went live; who takes care of it now?

The least-discussed truth of enterprise commerce: the project's first year is a small share of total cost of ownership — the system lives ten years, and the maintenance model determines the quality of those ten years. AMS (Application Management Services) is that maintenance in contracted, measurable, sustainable form. This article lays out the right AMS setup for Hybris: levels, SLA design, patch rhythm and the most critical split — separating the 'keep it running' budget from the 'move it forward' budget.

Support levels: who handles what?

The Hybris-specific crux sits at the L2-L3 boundary: cronjob/synchronization failures, ImpEx data corrections, Solr reindexing and backoffice configuration must be resolvable quickly at L2 — a model that escalates everything to L3 (engineering) is both expensive and slow. That is why the AMS team's platform depth is the most important 'hidden' quality in the contract.

SLA design: promises on symptoms, targets on causes

The principle from our observability article translates into contract language: SLAs attach to user-affecting symptoms — response and resolution targets for critical incidents (sales stopped), a high/medium/low priority ladder, and a tightened regime during campaign periods. Two design subtleties prevent disputes: priority definitions are written with examples ('payment errors above which rate are critical' — no room for interpretation) and resolution is separated from workaround (does a workaround stop the clock; how does the permanent-fix schedule run). The SLA dashboard must be the single screen both sides look at; a surprise in the month-end report is the symptom of a bad contract.

From incident management to problem management

The line separating mature AMS from mediocre AMS is repeated incidents: if the same cronjob fails weekly, responding to each failure is incident management; making it never fail again is problem management. The contract carries its counterpart: a recurrence-analysis rhythm (monthly problem review), mandatory root-cause work (written RCAs for critical incidents) and an incident-reduction target — good AMS should be incentivized to shrink its own ticket volume. Its infrastructural precondition is monitoring: on systems we take over, the first month usually goes to monitoring setup, because you cannot manage a system you cannot see.

The patch and version rhythm: maintenance's neglected half

In Hybris upkeep, 'if it works, don't touch it' turns into the compound interest we described in the health check article: every skipped patch and version enlarges the future upgrade. A proper AMS contract contains the maintenance rhythm: security patches applied within defined windows, platform updates (arriving regularly on CCv2) taken on schedule, continuous dependency scanning, and at least one 'upgrade rehearsal' per year. The cost of this rhythm is visible in the contract; the cost of its absence appears three years later in a 'mini rewrite' bill — the difference between the two is AMS's real return.

The improvement budget: keeping it alive is not enough

The healthiest AMS setup splits capacity in two: an operations share (incidents, requests, the maintenance rhythm) and an improvement share (performance work, technical-debt reduction, minor feature development). Keeping the improvement share fixed and protected is critical — otherwise urgent work devours every month and the system stands still. The practical mechanism: a monthly improvement list prioritized with the business, completed items reported with measured impact (p95 reduction, incident decrease). AMS then stops looking like a cost center and becomes a measurable value producer.

Transition: takeover discipline

AMS's riskiest moment is the takeover — whether from an internal team or a previous vendor. The disciplined plan: knowledge-transfer sessions (architecture, customization inventory, integration map — a health check output is a ready input here), an access/environment inventory, runbook handover and a shadow period (2-4 weeks where the old owner still responds while the new team rides along). The pattern to avoid is 'the documents are incomplete, we'll learn as we go': the learning cost is paid at incident time, and the user pays it.

Frequently asked questions

Internal team, AMS, or a blend?

A question of scale and continuity: carrying 24/7 on-call, holiday/attrition continuity and platform depth on internal headcount is expensive for most enterprises; business knowledge, though, is precious inside. The common healthy model is blended: business analysis and product ownership internal, operations and engineering depth in AMS.

How should AMS pricing be structured?

Pure per-ticket pricing punishes quality (fewer incidents = less revenue); pure fixed fee loads volume risk on one side. The balanced setup: base capacity (fixed) + a volume band + the improvement share — with an incentive tied to the incident-reduction target.

How should campaign periods appear in the contract?

As a separate regime: tightened SLAs, pre-planned team reinforcement, freeze windows and the pre-campaign readiness checklist (the runbook from our flash sale article) as a contract annex.

Is a version upgrade within AMS scope or a separate project?

Minor updates and patches are in scope; major version upgrades are planned as separately budgeted mini-projects — but the upgrade rehearsal and preparation are part of the AMS rhythm, which keeps that project small and predictable.

AMS setup checklist

1. Level boundaries (L1/L2/L3) and ownerships written

2. SLAs with example-based priority definitions; dashboard open to both sides

3. Problem-management rhythm and RCA obligation in the contract

4. Patch/version rhythm and annual upgrade rehearsal defined

5. Improvement share protected; impact reporting measured

6. Takeover plan: knowledge transfer + shadow period + runbooks

7. Campaign regime as a separate annex in the contract

SSH Yazılım provides SLA-backed AMS for SAP Commerce (Hybris) systems, covering takeover, maintenance and continuous improvement. Let us secure your system's next ten years together.