Erp Sap Standards

SAP ERP standards (business, platform and licence decision)

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

SAP as a company-level decision, not as a language: the maintenance calendar that forces your hand, the four real ways out of that calendar, the deployment model and the split of responsibility it brings, licensing and the annual audit, integration with the rest of the landscape, master data governance and programme-level environment governance.

Triggers: end of maintenance for ECC / Business Suite 7, extended maintenance, customer-specific maintenance, brownfield / greenfield / selective data transition, third-party support (Rimini Street, Spinnaker), RISE with SAP, GROW with SAP, SAP Cloud ERP Private / SAP Cloud ERP, transition option, compatibility packs, named users, indirect access, digital access, DAAP, USMM, SLAW2/LAW, STAR, annual licence declaration, audit notice, Diageo, IDoc, BAPI, RFC, OData, Event Mesh, MDG, SAP Activate, Solution Manager, Cloud ALM.

The axis of this skill: in SAP, the invoice is not generated by the code, it is generated by the contract. An SAP project is decided by three variables —maintenance end date, deployment model and licence metric— and all three are outside the technical team's control. The operational consequence that orders this whole document: any architecture decision that changes how or who creates documents in the ERP is a cost decision, and must go through whoever manages the contract before it is built. A flawless technical middleware layer can double the invoice.

Not applicable: see abap-sap-standards (critical boundary and owner of the code: classic ABAP and ABAP Cloud, ADT/Eclipse, SE38/SE80/SE24/SE11, CDS view entities, AMDP, RAP, SEGW, BAdI and enhancements, packages and transport requests SE09/SE10/STMS, abapGit, ATC, ABAP Unit, SNOTE, the clean core as extensibility doctrine and the technical conversion to S/4HANA. Arbitration rule in one line: if the answer is written in a repository object, it is theirs; if it is signed in a contract or declared in a measurement, it belongs here), migration-projects-standards (execution of the cutover: rehearsal, window, data reconciliation, coexistence, rollback and switch-off of the source), legacy-modernization-standards (the strategy umbrella for the legacy system and the "R"s), ibm-i-rpg-standards, mainframe-zos-cobol-standards and the other legacy platform skills (the system you are coming from in a first-time implementation, §3.8: where its business logic lives, how its data is extracted and what can be switched off. Here the destination and its contract; there the source and its technique — and the criteria for whether leaving that platform is worth it belong to legacy-modernization-standards, not to the illusion that SAP solves it), enterprise-architecture-standards (the application inventory, the TIME model and how the ERP fits into the portfolio), project-management-standards (programme management: commitment, estimation, RAID, stakeholders), itsm-itil-standards (the ERP as a service, SLA and change process), oracle-dba-standards / sqlserver-dba-standards (the database under an SAP AnyDB: tuning, backup, HA), data-platform-standards and analytics-bi-standards (analytics outside the ERP), data-governance-quality-standards (data ownership, catalogue and quality dimensions; here only master data as a constraint on the conversion), api-design-standards (the contract of the integration API), identity-access-management-standards (SSO, federation and the joiner-mover-leaver lifecycle; here only the account as a unit of licence), grc-compliance-standards (control framework and regulatory audit evidence; here the licence audit, which is not the same thing and is not run by the same people), opensource-licensing-standards (declared reciprocal: there the licences of free software —SPDX, copyleft, CI gates, SBOM—; here proprietary commercial licences, where the risk is not the obligation to publish source but retroactive settlement. They share no method: one is automated in the PR, the other is negotiated in a room), finops-standards (cloud cost per economic unit), privacy-engineering-standards (personal data inside the ERP), appsec-standards (threat methodology).

2. Default decisions

Verify on the web before committing to it (§8): SAP's calendar, product names and licence metrics move, and prices are not published.

3. Structure and conventions

3.1 The clock, and the four ways out

Verified data (Aug 2026, sources in §8). None of it is quoted from memory in a steering committee: it is re-verified against SAP the day it is presented.

• SAP Business Suite 7 / SAP ERP 6.0 (ECC): mainstream until end of 2027 for the three latest enhancement packages (EhP 6-8). With EhP 1-5 maintenance ended on 31 Dec 2025: an ECC on EhP5 today is already out, and that rarely appears on the vendor's slide.
• Optional extended maintenance 2028-2030: three years, with a surcharge of two percentage points on the maintenance base, and reduced scope compared to mainstream. It requires a contractual addendum: it does not activate by itself.
• Whoever does not contract it falls into customer-specific maintenance: same price, significantly smaller scope. It is the worst economic quadrant of the calendar and it is reached through inaction. Putting that in writing in front of the committee is half the decision made.
• S/4HANA does not take you off the clock, it changes your clock: innovation commitment until end of 2040 (announcement of 4 Feb 2020) = there will always be at least one release under maintenance, not your release will live until 2040. From release 2023 onwards: biennial cadence (2023 → 2025 → 2027 planned) and 7 years of mainstream per release (previously 5) → 2023 until Dec 2030, 2025 until end of 2032.
• SAP ERP, private edition, transition option (announced Feb 2025): it is not an extension of maintenance. It is a cloud subscription centred on ECC, purchasable from 2028 and usable from 2031 to end of 2033, which requires having moved the systems to private edition before the end of 2030 and having a RISE contract. SAP explicitly states that it does not include the full scope of Business Suite 7. Operational translation: the 2033 door closes in 2030, and anyone who sees it as "we have until 2033" has already lost the window.

The four ways out, with the criteria that separate them (it is not a preference; it is a function of the state of the ECC — if there is no source ECC, none of the four applies: that is §3.8):

On the fourth: it exists and it is legitimate, but it is not free of risk. The Oracle-Rimini Street litigation is the precedent you have to read in full before signing, not the headline: the Ninth Circuit (case 23-16038, 16 Dec 2024) vacated substantial parts of the judgment and the injunction of Rimini II —including the derivative work criterion applied by the district court— and remanded the matter; in the earlier contempt block the charges were affirmed and the amount of the sanction was vacated for recalculation. The correct reading for a buyer: the question is not settled and the third-party support provider has been litigating for over a decade. Demand intellectual property indemnity in the contract, and plan what you do if your provider loses.

Famous figure that must NOT be quoted without qualification: the "55-75 % of ERP projects fail". It is folklore with a real core: it is attributed to Gartner and to Panorama Consulting with circular citation; Panorama's own data across several years gives far lower figures (in the order of 22-26 % hard failure) and its sample is self-selected among rescue candidates. There is also a prediction from Gartner (>70 % of recent ERP initiatives will not fully meet their business objectives by 2027) that gets recycled as if it were a historical measurement: it is not. What is defensible is more boring and more useful: most overrun schedule or budget to some degree and a significant minority do not deliver the promised value. If someone uses the 75 % to justify a spend, ask them for the methodology (§8 of project-management-standards on the CHAOS Report: same pattern).

3.2 Deployment: the question is not where it runs, it is who answers

On-premise, managed private cloud (RISE), public cloud (GROW) and self-hosting on a hyperscaler are not four points on a scale of modernity: they are four different splits of responsibility. Before choosing, this table is filled in with the contract in hand — and if a cell is left empty, that is the 03:00 incident nobody will attend:

Points that decide and are almost never in the proposal:

• RISE is "one offer, one contract": the commercial simplicity is real and so is the risk — it bundles products (ERP, platform, Signavio, Business Network) and at renewal you renegotiate the block, not the piece. Demand the price breakdown by component before signing, even if the invoice is a single one; without it you cannot reduce scope at renewal.
• GROW is public cloud only and only a subset of the processes available in private. The honest criterion: if your competitive differentiator lives in an ERP process, public forces you to move it out or to give it up. Both are business decisions, not technical ones.
• Naming trap (Aug 2026): SAP renamed the family —S/4HANA Cloud private edition → SAP Cloud ERP Private, public edition → SAP Cloud ERP— and reused "SAP Business Suite" as the umbrella for the cloud offering, which is not the Business Suite 7 that is expiring. In any document, always write the full version and edition.
• Compatibility packs: a temporary right of use for ECC functions inside S/4HANA. On-premise they expired and under RISE they run longer (note 2269324; verify the current dates in §8). What matters here: it is a right of use, not a technical block — the transaction still starts after it expires. That is exactly what shows up in the next measurement.

3.3 Licensing: the heart of it

Two metrics coexist and add up: people and documents.

(a) Named users. Each account is classified into a type (Professional, Limited Professional, Functional, Self-Service/Productivity, Developer, Test/Platform according to the contractual price list) and the classification is set by the highest task the user is able to execute, not the one they execute habitually. Hard rules:

• Maximum rule: a user who does 95 % basic tasks and a single Professional-level one is licensed as Professional. It is not negotiated with a spreadsheet: it is prevented with the role.
• Account created = account counted. The vendor user who left the project in 2019 and is still active gets billed. Locking is not always enough: check the criteria in the price list in force.
• Design corollary, and it is the only structural lever: licence control is implemented in the authorisation role, such that a low-type user is technically incapable of executing a high-type transaction. Everything else is reclassifying after they measure you.
• The technical integration account is an account. Its type and its treatment are agreed in writing; they are not assumed.

(b) Digital access (indirect access): why you get billed for an order created by another system. When an external system —portal, CRM, RPA, IoT, a middleware— creates documents in SAP without a licensed person behind it, SAP does not charge for the person: it charges for the document. Nine types are counted (sales, invoice, purchase, service and maintenance, manufacturing, quality management, time management, material, financial), some per document and others per line, with material and financial weighted at 0.2 (five lines = one document). Only the initial creation counts: reading and updating afterwards does not charge again, and the chaining of documents derived from the same external event is not billed N times. It is sold in annual blocks. (This list and its weights come from licensing consultancies that agree with each other; SAP does not publish it openly without login — declared gap in §8: the definition that governs in a dispute is the one in your contract and the notes cited in it.)

The precedent you must know, verified: SAP UK Ltd v Diageo Great Britain Ltd [2017] EWHC 189 (TCC), 16 Feb 2017, Mrs Justice O'Farrell (TCC, case HT-2015-000340). Diageo built two systems on Salesforce —Gen2 (sales force) and Connect (customer portal)— that talked to mySAP ERP through SAP PI, which Diageo was already paying for by message volume. The court held that this interaction constituted use/access to the software: the contractual definition of Named User covered access "directly or indirectly (e.g. via the Internet or by means of a third party device or system)", and the Connect customers did not fit into any existing user category. SAP prevailed for over 54.5 million pounds in licences and additional maintenance. The correct readings, and there are three:

1. Paying for the middleware does not buy the right of access to the ERP. They are two distinct licences.
2. The ruling depends on the specific clauses of that contract, it focused on use by people and did not resolve many automated scenarios: it is not a universal rule, it is a warning.
3. The digital access model was born afterwards, precisely to replace the user-based claim with an accountable metric. The existence of a metric does not remove the risk: it makes it measurable.

The architecture criterion that follows, and it is the most important in this document: before designing an integration that writes into SAP, the annual volume of documents per type is estimated and valued against the block price. A redesign that groups, deduplicates or moves document creation out of the ERP is cheap on the whiteboard and extremely expensive afterwards. And conversion to the document model does not always pay off: staying on named users can be cheaper depending on the profile. The comparison is made with your own numbers, not with the salesperson's slide. If an adoption programme with credit (DAAP) is in force, it is evaluated — but verify its validity and conditions, do not assume them.

3.4 The annual audit: a plannable event, not a surprise

With a support contract in force, the annual measurement is a contractual obligation, not an SAP initiative. That you experience it as a surprise is a failure of your own process.

Mandatory sequence, and the order matters:

1. Calendar: the annual declaration is in the corporate calendar with a named owner, just like a financial close. It is prepared weeks ahead, not on the notice.
2. Measure internally first: USMM in every productive system (user classification + engine measurement), consolidation with LAW / SLAW2 to deduplicate the same human across several systems, and the digital access estimate with SAP's tool (STAR / current note).
3. Verify the price list the measurement uses: if USMM measures against a list that is not the one in your contract (ERP vs. S/4HANA vs. Private Cloud), the result means nothing.
4. Remediate before submitting: reclassify downwards what real usage does not support, close dead accounts, and fix the role so the reclassification does not undo itself the following month.
5. Submit only the cleaned-up result. What is submitted is a declaration; what is not cleaned up becomes the starting point of the negotiation against you.
6. Grey metrics: there are engines that do not self-declare and require entering a count by hand. Omitting them is not prudence, it is an under-declaration with your signature on it.
7. When an audit notice arrives: acknowledge receipt, fix the scope against the contract —which systems, which period, which metrics—, measure internally and only then hand over. No access or scripts outside scope are granted, and nothing is answered in the heat of the moment.

Triggers that bring an audit forward (plan accordingly): a renewal, a conversion to S/4HANA, a merger or acquisition, and any large new integration. That the integration project and the renewal fall in the same quarter is no coincidence: it is the pattern.

Consultancy figures about "20-40 % overcounting" in the first measurement: they circulate widely, they are published by companies that sell audit defence and they bring no methodology or sample. Use them as a reason to measure yourself, never as a figure in a report.

3.5 Integration: do not couple the landscape to the ERP

Available mechanisms and when to use them: IDoc (asynchronous business document, standard and auditable — still the sensible option in B2B and logistics), BAPI/RFC (synchronous, coupled; the one that generates the most debt), OData (service exposure for external consumption), Event Mesh / messaging (event publication, the only one that truly decouples). Criteria:

• The ERP is a system of record, not a bus. Everything hung off it inline inherits its maintenance window and the clock of §3.1. Forbidden by default: synchronous point-to-point RFC from a customer-facing application.
• Every integration declares its licence impact (§3.3) in the same design document, with estimated annual volume per document type. Without that line, the design is not approved.
• Idempotency and reprocessing in everything asynchronous: a resent IDoc cannot create a second document — it is functional correctness and licence savings.
• A technical account per integration, with minimum permissions and traceable to an owner. One account shared by six interfaces makes it impossible to attribute consumption and responsibility.

3.6 Master data: what decides whether the conversion runs aground

Master data (material, customer, vendor, chart of accounts, cost centre) is where projects die, and its symptom arrives late. Rules:

• Every master object has a named business owner before starting, not a "data team".
• Cleansing is done at source and before the cutover, with measured quality rules and a date: "we will clean during the migration" is how you lose the schedule. How that data is extracted and reconciled is decided by the source's skill: if it is an IBM i, ibm-i-rpg-standards §3.5 sets the mechanism (journals and receivers) and the traps that break a load silently —packed fields, numeric dates with an implicit century window, multi-member files from which SQL reads only the first one and looks correct, CCSID 65535—. None of those are visible from the SAP side until the data is already loaded.
• Business partner: the unification of customer/vendor in S/4HANA is a conversion requirement and is a data project with its own owner, not a technical step.
• What is not migrated is declared: history that stays in a queryable archive, with its retention period and its legal basis (cross-reference privacy-engineering-standards).

3.7 Environments and transports at programme level

Here, not the mechanics of the transport (that belongs to abap-sap-standards), but the governance:

• Minimum landscape DEV → QAS → PRD with a single promotion path and no change born in PRD.
• Transport freeze declared around the cutover and around each close, with an owner who lifts it and with an end date published from day one — the criterion belongs to migration-projects-standards §7 and applies equally here: a freeze without an end date stops being a control measure and becomes a paralysis nobody dares to end. Not to be confused with the freeze of a legacy system (legacy-modernization-standards), which is another thing: there you freeze so as never to touch it again, and it demands isolation, a patching window and a dated exit plan.
• Coexistence: during a conversion there are two live landscapes. It is defined in writing where corrective maintenance is done and how it is replicated to the other. Without that rule, a regulatory fix gets lost in production.
• Production data in non-productive environments: by default no, or anonymised. A copy of PRD in a sandbox is a breach, and moreover it gets measured in the user classification.

3.8 First-time implementation: arriving at SAP from a non-SAP legacy

All of §3.1 is indexed by the state of an ECC. The scenario of an organisation arriving at SAP from an AS/400 with RPG, a Dynamics, a niche ERP or an in-house development has no ECC: there is nothing to convert, no data with SAP structure, and nobody inside who knows how to read it. It is the most frequent "first time" case and it needs its own criteria.

Why it is not the greenfield of §3.1. That one is reimplementing SAP from SAP: processes already exist in SAP, tables with SAP semantics and people who understand them. Here none of the three exists, and that changes three things:

• There is no baseline and no automatic diagnosis. SAP Readiness Check collects its information inside an ABAP system of SAP ERP (simplification items, Z code, CVI, integration analysis): with no source SAP system there is nothing to collect. You are left without the starting point that SAP's material takes for granted — and also without USMM/LAW for sizing (§3.4). Verify §8.
• The risk shifts from how do I convert to how do I decide what to do. In a brownfield the scope is set by the existing system; here it is set by a discussion, and a discussion has no natural end. Rule: scope is closed by date and by signature, not by consensus.
• It is the only time in the system's life when clean core comes for free. You are not dragging SAP debt because you have not created it yet. That advantage is spent in the first months or it is never spent.

The dominant decision: standard versus own process.

• The legacy encodes decades of particular process, and most of it is not deliberate: it is what the RPG programmer could do in 1998 with 1998 tools. Confusing "this is how we do it" with "this is how we differentiate" is the central error of the domain.
• The method is SAP Activate's fit-to-standard, in the Explore phase (SAP verbatim: "Conduct fit-to-standard workshops and confirm the solution design"). Its value is destroyed the moment the workshop is used as requirements gathering for bespoke development: then it is not fit-to-standard, it is a functional analysis under another name.
• The burden of proof falls on the deviation, never on the standard. Whoever asks to depart demonstrates the competitive differentiator with numbers; nobody has to justify adopting the standard.
• Who decides: a business process owner with authority to say no to their own area. If the decision is taken by IT, or by a committee with no power over the areas, the default result is always the deviation.
• The warning that underpins everything else: every deviation from the standard is paid at every upgrade, for ever — and in GROW / public Cloud ERP the upgrade is not yours to decide (§3.2), so the payment falls on someone else's date. The extensibility doctrine that avoids it (clean core) belongs to abap-sap-standards; the governance consequence —committee, register with reason and date, review at each upgrade— is already in §7 and is not repeated here. SAP itself declares it part of its method: "SAP Activate builds on SAP's strong foundation of fit-to-standard and clean core principles" (verbatim, §8).
• Replicating the legacy screen is forbidden. "Make it look like what we had" is a change management requirement disguised as a functional requirement, and it is paid as bespoke development and as an upgrade mortgage. The correct answer is training, not code.

Deployment: big bang versus phased.

• You do not go phased by module within the same company code, except in a very justified case: splitting FI from MM/SD in the same unit creates the worst possible interface, the accounting entry one, and moreover forces you to reconcile two live sets of books.
• Even big bang coexists: the legacy stays switched on in read-only mode. Coexistence is not a property of the phased approach, it is a property of all of them, and it is governed the same way:
  • It is declared in writing where corrective maintenance is done and how it is replicated to the other system (same criterion as §3.7). Without that rule a regulatory fix gets lost.
  • A legal change during coexistence is implemented twice, or it is explicitly decided not to implement it in the one that is dying. What you cannot do is not decide it.
  • Every coexistence interface is born with a switch-off date and an owner who switches it off, in the same document that approves it. Without a date it is not approved: the temporary interface without a switch-off date always ends up permanent, and it ends up being the reason the legacy is never switched off.
  • Never two writing systems for the same master object. During coexistence each object has exactly one system that writes and another that consumes. Double writing guarantees divergence, and divergence is discovered at reconciliation, late.
  • Coexistence is sized in months with a date, not "until we are ready". The longer the phase, the cheaper each individual cutover and the more expensive the sum.
• The cutover itself —rehearsal, window, freeze, reconciliation, balancing, rollback and switch-off of the source— belongs to migration-projects-standards. Do not redefine it here.

Master data: what sinks these implementations.

• Why it is worse here than in a conversion: in brownfield the data already has SAP structure. Here the AS/400 material has no material type, no article group, no alternative units, no plant and storage location views: SAP's mandatory fields simply do not exist in the source and have to be invented with business criteria, by rule or record by record. That is not a mapping, it is a data project with its own owner, deadline and budget.
• Hard rule: cleanse at source and before loading. Loading dirty and cleaning inside contaminates the new system on day one, and from then on the load error can no longer be told apart from the operational error — which is exactly what destroys the user's trust in the new system.
• The honest nuance: the source is usually a system whose owner no longer wants to invest in it. Nobody is going to pay for development on the AS/400 that gets switched off in fourteen months. Practical consequence: the cleansing is executed outside, in a staging area (extraction → measured quality rules → correction with a business owner → load), but the correction has to go back to the source while the source is still the system of record; if it does not go back, the next extraction reintroduces the dirt and the work is repeated in full. If going back is impossible, the extraction is frozen with a date and everything after that date is corrected in both places, with that duplication declared as a cost, not discovered.
• What is not loaded is declared: history in a queryable archive, with retention and legal basis (§3.6 and privacy-engineering-standards).
• The standard route from a non-SAP source is the SAP S/4HANA migration cockpit (the Migrate Your Data app, with staging tables). SAP describes it as not intended as a frequent load interface nor for mass modification: do not turn it into your coexistence interface (verify §8).
• Project governance metric: the percentage of records that pass the quality rules on the real extract, measured weekly from the first month. If that curve does not rise, the project is not advancing even if the configuration is — and it is the only indicator that detects it in time.

Real cost and sizing with no SAP history.

• There is no baseline: with no USMM and no LAW consolidation (§3.4), everything comes from a business estimate about a system nobody has used, and that estimate is optimistic by construction.
• Users: the count is not deduced from the legacy. An operator with a five-option menu in the AS/400 can end up in a high type because of a single transaction. The mapping is done by task, not by head, and it is closed with the role design (§3.3, maximum rule). In a cloud subscription the usual aggregate metric is the FUE (Full Use Equivalent), with ratios per usage type set in the Cloud Supplement: the specific ratios, and whether your edition is still on FUE or on another metric, are read from the contract, not from a blog (declared gap in §8).
• What gets oversized systematically: infrastructure and capacity. It is the easy thing to measure, the easy thing to adjust and —in managed cloud— not even yours to decide. Too much attention is paid to it.
• What is discovered late, which is the expensive part:
  1. The implementation weighs more than the licence: services, integration and change management. A business case built on the subscription price is badly built.
  2. Interfaces: nobody counts them at the beginning. The legacy interface inventory — including the flat files over FTP that have no owner— is done before estimating, not during Realize.
  3. Digital access (§3.3): every interface that writes into SAP has a per-document cost. Here there is no SAP historical volume to compare against, but there is document volume in the legacy and it can be counted: count it, it is the only hard data available.
  4. Localisation: if you operate in a country with no local version delivered by SAP, legal responsibility passes to you. SAP verbatim: "The customer or corresponding partner is responsible for the development and maintenance of complete customer local version." It is checked country by country and before signing (§8) — the number of supported countries differs between SAP's own sources.
  5. Training and the productivity drop in the months following go-live. It is budgeted or it is suffered; there is no third option.
• The estimate is presented as a range with written assumptions, and the three assumptions that move the number the most —number of interfaces, number of approved deviations and annual document volume— are reviewed at every Q-gate. The programme and its estimation belong to project-management-standards.

When SAP is not the answer.

This catalogue tells the truth when a technology is dead; here it is time to tell it about the inadequacy of a choice. Signs that the project fails before it starts — if two of them hold, you stop and rethink, and that is written down before kicking off so nobody argues about it afterwards:

• There are no process owners with authority, or the sponsor is IT instead of general or financial management. Without authority to impose the standard on an area, every decision in this subsection resolves in favour of the deviation.
• The mandate is "make it do what the AS/400 does". The result is a bespoke SAP with the cost of SAP and the capabilities of the legacy: the worst of both worlds, and the dominant anti-pattern of §7.
• Nobody from the business is released full time. Key staff "in spare moments, on top of their job" is the most common and least reported cause of delay.
• The company's differentiator lives in a process the ERP would have to absorb (singular manufacturing, own pricing, a service model that does not fit). Criterion: that stays outside the ERP, in an integrated system of its own. If it cannot stay outside, the standard ERP is not your answer.
• Size and capability, which are not revenue: is there an IT function capable of operating the system after go-live, and does the operating budget —not the project one— sustain the recurring subscription plus the partner? An organisation that can only pay for the project is buying a system it will not be able to maintain.
• Sector: if the core process is better covered by a specialised vertical, the generalist ERP competes at a disadvantage on its own ground. ERP for finance and procurement + a vertical for the core usually fits better than forcing the core inside the ERP.
• The deadline is set by an external event (end of hardware support, end of a contract) and the scope is still open. That combination always produces the same cut, and in this order: testing, then data quality.
• Honesty about the figures: there is no ERP project failure rate published with a methodology you can cite in the committee (§3.1, §7). These signals are criteria, not statistics: present them as criteria and do not dress them up as a percentage.

Boundaries of this subsection (cite them, do not duplicate them): migration-projects-standards (the cutover: rehearsal, window, reconciliation, balancing, rollback and switch-off of the source), project-management-standards (the programme: commitment, estimation, RAID, stakeholders, change management), legacy-modernization-standards (the choice of "R" —here repurchase— and the fate of the source system: freeze, archive or switch off, with a date), ibm-i-rpg-standards when the source is an AS/400 / IBM i (data extraction, DB2 for i and the state of the starting system), enterprise-architecture-standards (build-vs-buy and the fit in the portfolio: the "SAP or not" decision starts there, not here), data-governance-quality-standards (data ownership and quality dimensions; here only cleansing as a constraint on the cutover).

4. Quality and verification

Increasing cost, and the order is the one that sustains a programme:

1. Inventory of interfaces and of Z objects with an owner and real measured usage: what nobody uses is not migrated. It is the biggest available saving and the one nobody makes.
2. End-to-end business process regression, not transaction-level: order→delivery→invoice→ collection. Automated where possible; the case catalogue is signed off by the business, not by IT.
3. Accounting and inventory reconciliation against the source, with tolerance defined before the cutover. It is the abort criterion, and it belongs to migration-projects-standards: do not redefine it here.
4. Load testing with real volume on the close and peak processes, not with the test data set.
5. Full cutover rehearsal, timed, including the rollback.
6. Licence measurement on the converted system before go-live: discovering the mismatch in production is discovering it late and with no negotiating room.

5. Stack security

• Segregation of duties (SoD) as a role design requirement, not as a later audit finding. Conflicts are detected during role construction; remediating them after go-live costs orders of magnitude more.
• The ERP is not exposed to the Internet. External access goes through an integration layer with its own authentication and its own rate control. User interface and administrative services, never.
• Standard accounts and default passwords: changed and verified as part of system onboarding, in every client, including the ones that "are not used".
• Security notes: monthly cadence with an owner and an SLA per criticality. Triage follows vulnerability-management-standards; the technical application, abap-sap-standards.
• Encryption in transit on all connections, including internal RFC ones between systems in the landscape. "It is on the internal network" is not a control (zero-trust, networking-standards).
• Logging of access to personal data and audit logging with defined retention and outside the reach of an administrator of the system itself.
• Risk specific to RISE/GROW: the vendor has privileged access to your ERP. **Demand in writin

…(truncated)