How ERP Preflight is organised

ERP Preflight is the deterministic safety layer before SAP change, migration and production. You do not choose between tools: you bring the artifacts of a change, a migration or an incident, and the platform runs the checks of every affected domain and answers with findings, evidence and a verdict.

The work is organised in three pillars — Prevent, Explain and Govern — and offered as three products. All of them share one platform: the upload pipeline, the evidence model, the findings workflow, reports, the audit trail, the API, the CLI and the MCP server.

Will this change or migration break production?

• Change Preflight — one gate before production for everything a change touches: transports and software collections, ABAP code and Clean Core, APIs, IDocs and change pointers, custom fields and extensions, output determination and forms, migration artifacts and authorizations (IAM). A Full Project Preflight routes every uploaded artifact to the checks whose input it matches; the Change simulation of a project answers what-if questions before anything is imported.
• Migration Preflight — what your ECC configuration (IMG/SPRO) and custom code become in S/4HANA Cloud, including obsolete transactions and fit-to-standard gaps.

In the application sidebar: Prevent — Projects, Analysis templates, Files & formats, System landscapes.

Something broke — what is the first cause, and what do we fix first?

• In a Full Project Preflight, findings of different checks that name the same SAP object are grouped under one root-cause candidate: the most upstream check wins (for example output determination before the form that was never printed).
• MFS BlackBox pinpoints the first causal divergence in warehouse telegram logs and the minimal telegram sequence that reproduces it; the analysis run shows the telegram timeline.
• Single-domain root-cause checks explain Fiori 403 errors and stuck workflows.
• Coming: SAP error logs reduced to the few primary causes, with the exact source rows and a fix order.

In the application sidebar: Explain — All findings, Knowledge graph, Knowledge.

May this change ship, and on which evidence?

• The Agent Gate evaluates change proposals — from AI coding agents or from people — against the change simulation and the latest findings of the affected objects, and records a human decision with separation of duties: whoever proposed a change cannot approve it. Agents reach it vendor-neutrally through the REST API and the MCP server.
• Every report carries a verdict (GO, CONDITIONAL GO, NO-GO) and references the same evidence as the findings; the CLI fails a CI pipeline on the severities you choose.
• The audit trail is a verifiable hash chain, and the Release Matrix shows which checks apply to which SAP release.

In the application sidebar: Govern — Agent Gate, Reports, Release Matrix, Integrations.

• ERP Preflight Change Gate (Prevent, Govern) — one verdict per change across transports, code, interfaces, extensions, forms, migration artifacts and authorizations. You provide transport lists, ABAP sources, API specifications, configuration and form exports.
• ERP Preflight Migration Intelligence (Prevent, Explain) — what ECC configuration, custom code and interfaces become in S/4HANA Cloud. You provide IMG/SPRO exports, custom code, ATC and readiness check results.
• ERP Preflight MFS BlackBox (Explain) — warehouse automation incidents explained from Material Flow System telegram logs. You provide the telegram logs.

Every product starts with zero SAP access: you upload exports you already have, and no system connection or installation is needed for the first result. When automation pays off, add a connector (read-only until you confirm a write permission) or the local agent, which collects and redacts exports inside your network. Which export each check reads: File formats per engine.

The checks are carried out by specialised, deterministic domain engines. You do not need to know them to use ERP Preflight — the preflight selects them from your artifacts, and analysis templates preselect them for common questions. They stay fully documented for transparency: the engine catalog lists every engine with its rules, accepted inputs and remediation texts, and the solution areas group them by the kind of change they check.

Same input, same result: every finding records the engine version, the rule version and the knowledge snapshot it was produced with, plus the SHA-256 hash of the analysed artifact.