Every workaround is a customization

⟦VISUAL-SET post=every-workaround-is-a-customization count=6 status=brief⟧

• Design lock for this hero pass. Kit is not empty. Do not invent a second kit.
• style: abstract pack — geometric, hairline, almost no chrome. Cover more abstract than inline diagrams. Same hairline weight, corner radius and shadow as the refs. Refs: Figma Marketing node 6452-2879 and Ulys’s 2×2 abstract frames.
• palette: ground #f8f8fa, hairline #e5e7eb, blue #6366f1, violet #8b5cf6, glow rgba(99, 102, 241, 0.2)
• output: SVG, 16:9, viewBox 0 0 1600 900, opaque ground, no transparency
• variants: this pass = hero only. c1–c5 stay inline and are drawn in a later pass.
• tool: Cursor + .agents/skills/visual-asset/SKILL.md on branch feature/visual-asset-skill-7811
• editorial — no baked text in any file. FR reuses the same SVG. Numbers and dates live in the caption, never in the image.
• editorial — vocabulary lock, EN, same as the post. workaround is the class, never a shape. The three shapes are spreadsheet (c1), custom screen (c2), detour (c3). Detour applies to c3 only — never to c1 or c2. Counted = compiled, appears in the migration audit: c2 only. Uncounted = the spreadsheet and the floor detour. Never use the French contournement anywhere.
• editorial — no account names in this draft. Sources point to the AUDIENCE tab by description, never by customer name. Resolve the row in the sheet, not here.

⟦/VISUAL-SET⟧

⟦VISUAL id=hero⟧

• type: hero · ratio: 16:9
• done_when: a reader who skips the article sees two kinds of specific — one fused into the core, one resting on top of it
• must_show: two stacks side by side, cover-abstract. Left: the specific fused into the core, core silhouette irregular. Right: the same core clean, the specific as a separate slab resting ON TOP — not attached, not wrapping.
• must_not_show: the three workaround shapes · any wrapper or shell around the core · window-dot or browser chrome · ERP screenshot · labels · numbers · logos · any baked word
• text_in_image: none
• caption: none
• gtm_note (not for the image agent): argument — specific in the core is a migration line item, specific above it is not. The cover carries c5’s thesis, not c1–c3 stacked; previewing the three shapes in one 16:9 is what produced the single window and the bump on the first pass. This is the cover variant of c5.

⟦/VISUAL⟧

Nobody approves a workaround. That is the entire point of one.

A workaround appears the moment the distance between what the system requires and what the work requires grows wider than a person's patience. Someone opens a spreadsheet beside the screen. Someone asks a consultant for one more field. Someone quietly stops using the control that was supposed to prevent the problem in the first place.

None of it goes through architecture review. All of it shows up in your migration scope.

Three shapes, and only one of them is visible

The spreadsheet beside the screen. Price checks, load calculations, the list of what goes with what. Free to build, absent from every system inventory, and — for some part of your operating knowledge — the only place it exists at all.

⟦VISUAL id=c1⟧

• type: inline · ratio: 4:3
• done_when: the two are obviously the same size, and one of them looks like it does not exist
• must_show: a fully rendered application window and, beside it, a spreadsheet of identical size drawn in outline only — equal dimensions, opposite weight
• must_not_show: readable data · cell contents · branding · ERP screenshot · any baked word
• text_in_image: none
• caption: none
• gtm_note (not for the image agent): anchor — under “The spreadsheet beside the screen”. Argument: the spreadsheet is not small, it is absent from every inventory. This is an uncounted shape — it is not a customization and the audit will never price it. Source: AUDIENCE — two distributor rows, one describing “~3 systems plus Excel files”. Resolve in the sheet.

⟦/VISUAL⟧

The screen someone built for you. At one distributor, the delivery dispatch board is a hand-built matrix inside the ERP, commissioned from an outside consultant years ago. It works. It is also close to impossible to modify or export, and every version upgrade has to account for it. That is a workaround that hardened into an asset nobody wanted to own.

⟦VISUAL id=c2⟧

• type: inline · ratio: 4:3
• done_when: the reaction is “that cannot come out any more”, never “that was badly built”
• must_show: a grid cast into the surface around it — same material, no seam, no handle. Something poured rather than assembled.
• must_not_show: crack · breakage · consultant caricature · any suggestion of poor workmanship · a detour path of any kind · any baked word
• text_in_image: none
• caption: none
• gtm_note (not for the image agent): anchor — under the dispatch matrix paragraph. Argument: this is a hardened custom screen, not a detour. It works, and that is exactly why it will not come out. This is the only counted shape — it is what the migration audit compiles and prices. Never describe it as a detour. Source: AUDIENCE — distributor row describing an in-house dispatch matrix built inside Business Central by an outside consultant, low flexibility. Resolve in the sheet.

⟦/VISUAL⟧

The control everyone routes around. Stock reservations that exist in the system and are not respected by operations — the goods ship anyway. Load weights recorded in the data with no alert when an order passes the limit, so an advisor builds to 98,000 lbs against a 52,000 lb ceiling and starts the whole order over.

⟦VISUAL id=c3⟧

• type: inline · ratio: 4:3
• done_when: the detour reads as the norm, not the exception
• must_show: a solid threshold, and a detour path visibly more travelled than the official passage
• must_not_show: the real limit figures · any figure at all · truck · pallet · literal warehouse iconography · any baked word
• text_in_image: none
• caption: none
• gtm_note (not for the image agent): anchor — under the load-weight paragraph. Argument: the rule exists and the floor goes around it; both are true at once. This is the one brief where detour is the correct noun. Uncounted: nothing gets migrated because nothing was ever built — it is a standard control being ignored, not a customization. Source: AUDIENCE — distributor row describing a load ceiling recorded with no alert, and stock reservations not respected. Resolve in the sheet.

⟦/VISUAL⟧

The system holds the rule. The floor goes around it. Both facts are true at once, and only one of them is in the documentation.

Why this stops being free

Workarounds have always been cheap, because nobody counted them. That changes on a specific date.

• 31 December 2027 — SAP ends mainstream maintenance for ECC.
• Roughly 70% of Business Suite 7 / ECC customers have not yet migrated, according to Gartner.
• 18 to 36 months — the typical duration of an S/4HANA migration.

⟦VISUAL id=c4⟧

• type: inline · ratio: 16:9
• done_when: the overshoot is visible without reading a single figure
• must_show: a timeline ending in a hard stop, and a migration bar starting from today that visibly runs past that stop
• must_not_show: countdown · red · alarm iconography · any figure on any axis · any baked word. The arithmetic must read calm, not alarmist.
• text_in_image: none
• caption (ships with the image, reused verbatim in FR): “SAP ends mainstream maintenance for ECC on 31 December 2027. A typical S/4HANA migration runs 18 to 36 months.”
• gtm_note (not for the image agent): anchor — under the three-date list. Argument: for most organisations still on ECC the comfortable window has already closed. Source: RECHERCHE — ECC end of mainstream maintenance 2027 · Gartner ~70% · 18–36 months.

⟦/VISUAL⟧

Run that against a calendar. For most organisations still on ECC, the comfortable window has already closed — and the scoping exercise that starts every migration is the first time anyone counts what the frontline built.

Clean core turns your workarounds into a line item

The doctrine of S/4HANA is clean core: keep the standard standard, push the specific out of the middle. As engineering, it is correct. As a budget event, it means every customization you carry has to be justified, re-platformed, or abandoned.

The audit before a migration is the first time most organisations see their workarounds priced.

And the compiled ones are what get priced — the custom screens, the extra fields, the bolted-on logic. The spreadsheets stay invisible, which is a different problem: they are not in the scope, and they are not in the new system either.

Here is the uncomfortable part. The workarounds exist because the work needed them. Removing them without replacing what they did does not clean the core. It moves the problem back onto the person at the counter — the same person who invented the workaround in the first place, and who will now invent a new one.

The distinction worth making before the audit

There are two kinds of specific, and they have very different costs.

Specific inside the system of record. Custom fields, modified screens, added logic. Every one becomes a scoped item in your migration, and a regression test in every upgrade after it.

Specific in a layer above it. Changes weekly without touching the core. Survives the migration because it was never inside it. The ERP stays standard — genuinely standard, not aspirationally.

⟦VISUAL id=c5⟧

• type: inline · ratio: 16:9
• done_when: nobody can mistake the upper layer for a wrapper. This is the load-bearing visual of the post and the one that deserves the most time.
• must_show: two stacks side by side. Left: the specific embedded in the core, making its silhouette irregular. Right: the same core clean, the specific resting in a separate layer above it, unattached.
• must_not_show: ⛔ the layer drawn as an envelope or a shell around the core — that reads as middleware, which is exactly what we are not. It RESTS ON TOP; it surrounds nothing. Also: labels · numbers · logos · any baked word.
• text_in_image: none
• caption: none
• gtm_note (not for the image agent): anchor — under the two definitions of specific. Argument: specific inside the core becomes a migration cost, specific above it does not. The hero is the cover variant of this same idea, so the two must resolve to the same shape language. Source: positioning.md “execution layer” anchor · CLM-FL-037 “works alongside SAP without modifying it”.

⟦/VISUAL⟧

Your product equivalences, your customers' ordering habits, your pricing exceptions, the four questions a junior advisor has to ask before an order is safe to place — none of that belongs in the ERP, and it never did. A system of record is exceptionally good at recording that an order exists. It was never designed to know that this particular customer orders in linear feet, or that this item was superseded last year.

Before the migration scopes them for you, it is worth knowing what your frontline has actually built. Every spreadsheet open beside an ERP screen is a specification somebody wrote for free.