Release-assurance graph for SAP manufacturers to predict what custom ERP changes will break before cutover windows.

1. SAP is strategically validating AI-operable modernization tooling instead of treating it as a fringe add-on.
2. Named industrial customers have already shown order-of-magnitude speed and cost gains, so transformation sponsors can buy against ROI instead of experimentation.
3. Reverse-engineering undocumented customizations is still a manual precondition to modernization, creating a clear pain point for automation.
4. The problem is spreading beyond SAP into Oracle, Salesforce, MES, and WMS, opening a large cross-stack platform category rather than a single-app tool.

Catalyst. Conduct's funding, SAP's strategic participation, and named customer ROI show that enterprises now budget for AI-operable modernization tooling because opaque customization has become the rate limiter on already-funded transformation programs.

Build a system that ingests ERP custom objects, configuration diffs, integration maps, and prior project artifacts to construct a living graph of how business processes depend on software changes. For each requested change, the product would simulate downstream impact, flag missing owners, and generate a cutover packet containing regression tests, sequence of operations, and rollback checkpoints. The first product would stay read-only, fitting into existing transformation governance rather than replacing the SI. Over time it can learn from completed projects to benchmark risky patterns, estimate delivery effort, and become the default control plane for enterprise change execution.

What's different. This is not a generic migration copilot and not a consulting-heavy code generator. The product is a change-assurance layer that turns hidden ERP dependencies into a reusable graph and packages each rollout into an evidence-backed blast-radius decision. That makes it valuable to both the enterprise sponsor and the SI, while creating defensibility through the accumulated graph, historical cutover outcomes, and cross-system process knowledge.

Jobs to be done

flowchart LR
  Buyer[SAP transformation director] --> Pain[Undocumented customizations block cutover]
  Pain --> Product[Change assurance graph]
  Product --> Outcome[Faster safer plant-by-plant modernization]

Executive takeaways

• The pain is real and budgeted: only 57% of ECC customers are projected to complete their S/4HANA transformations by the end of 2027, while current survey data still shows 29% actively in migration and 44% struggling with customizations. [12][13][14]
• The competitive field is crowded but fragmented: Tricentis and Basis focus on test and change control, smartShift on custom code, and SNP on migration and data transformation, leaving room for a vendor-neutral blast-radius graph that starts before testing and transport. [17][18][19][24][25][27][29]
• Channel leverage is attractive because SAP and its ecosystem are already selling AI-assisted modernization through partners such as Palantir, Accenture, Deloitte, and UiPath, which lowers the educational burden for a new category entrant. [10][30]
• Governance matters as much as speed: buyers in regulated or critical sectors will ask for secure read-only deployment, audit logs, human oversight, and cyber-risk controls under SAP ALM, NIST AI RMF, NIS2, and the EU AI Act. [9][31][32][33]

Market definition

A read-only change-assurance layer for SAP-centric industrial transformation programs that maps custom code, configuration, tests, and adjacent MES or WMS dependencies into a reusable graph before each rollout. [1][2][17][24]

Customer and buyer

Primary users are SAP transformation directors, release leads, and enterprise architects inside large multi-site manufacturers; the economic buyer is typically the VP Enterprise Applications, CIO, or program sponsor accountable for a fixed S/4HANA timeline and cutover risk. [3][12][15][16]

Buying triggers

• A fixed go-live date collides with the 2027 or 2030 maintenance clock and makes backlog risk visible to the steering committee. [5][6][13][14]
• Discovery work reveals that customizations and clean-core gaps are larger than expected, making manual fit-gap and remediation planning too slow. [11][12][20][21][22]
• A plant rollout, carve-out, or template deployment needs defensible test scope and change sequencing across SAP plus adjacent systems. [17][18][24][25][27]
• Security, quality, or regulated-environment stakeholders ask for traceable AI assistance and documented human oversight before production use. [9][31][32][33]

Willingness to pay

Program budgets are justified through avoided delay and rework rather than seat count: Conduct reports 10x faster design cycles and 50% to 80% cost savings, smartShift markets 253% ROI for code migration, and UiPath’s internal SAP program cites 10% faster delivery plus 60% automated test coverage. That supports a six-figure annual spend inside a live S/4 program even without public list pricing from incumbents. [1][21][30] [1][21][30]

Category dynamics

Growth signal ≈23.0% annualized increase in partially or fully live S/4HANA adoption (39% end-2024 to 59% in 2026, calc)

Validation signals

• Conduct reports 10x faster design cycles and 50% to 80% cost savings with named industrial customers, showing this pain already carries budget.
• Conduct’s S/4HANA migration page claims more than 80% faster manual system analysis and up to 30% lower large-project costs.
• Minol says 80% to 90% of core processes live in proprietary SAP objects and that some tasks fell from a full day to a single hour after adoption.
• Precisely’s 2026 survey still finds 29% actively in migration and 44% blocked by customizations, while UiPath’s Customer Zero program achieved 93% clean core and 60% automated test coverage.

Regulatory & technical constraints

• Sensitive ERP estates, especially in regulated sectors, will require read-only deployment boundaries, auditability, and sometimes local delivery or personnel constraints.
• The product must coexist with SAP Solution Manager and Cloud ALM rather than force an ALM rip-and-replace during a live transformation program.
• Prediction quality depends on ingesting accurate custom-code, process, and test metadata; undocumented legacy logic remains hard to classify automatically.

Buyers can already combine SAP ALM, Tricentis or Basis change intelligence, smartShift-style code remediation, SNP migration factories, and SI workshops. The whitespace is a vendor-neutral layer that starts earlier than testing or transport by turning undocumented SAP plus plant-system dependencies into a reusable blast-radius graph for each rollout. [7][17][19][24][27]

Why incumbents do not win by default

• SAP-native ALM. SAP already owns the requirements-to-deploy spine via Solution Manager, Focused Build, and Cloud ALM, but those tools do not by default explain custom business logic across plant-specific systems in business-user language before change work starts.
• QA and change intelligence suites. Tricentis and Basis quantify impact and streamline testing or transport, but they begin after enough technical structure already exists to define impacted scope.
• Custom code remediation specialists. smartShift makes custom-code conversion faster and cleaner, yet its center of gravity is code transformation and clean-core readiness rather than ongoing blast-radius decisions across owners, integrations, and rollout packets.
• Migration data platforms. SNP is built for large migration and data-transformation programs, but that strength can make it heavier than a read-only assurance wedge aimed at one process corridor before each rollout.
• System integrators and internal teams. Many enterprises can still pay architects and SIs to build dependency spreadsheets and run workshops, so the startup must sell time-to-confidence, not generic automation.

ERP Change Assurance Graph is a read-only release-assurance layer for large manufacturers running SAP ECC-to-S/4HANA transformations across multiple plants. The first user is the SAP transformation director or release lead who must approve cutovers despite undocumented custom code, local plant variants, and MES or WMS dependencies that are still reconstructed through workshops and spreadsheets. The beachhead is one critical process corridor such as warehouse-to-plant fulfillment or order-to-cash inside a funded rollout with a fixed go-live window, because that creates a visible buying trigger, a narrow deployment scope, and measurable proof in days saved and defects avoided. The product wedges in before testing and transport tooling by mapping blast radius, missing owners, regression scope, and cutover sequence from read-only artifacts rather than replacing SAP ALM or the SI. Research supports the pain, buyer urgency, and ecosystem timing through SAP maintenance deadlines, continuing migration backlog, named customer ROI from category leaders, and a crowded but fragmented competitor set. The company should deliberately avoid broad cross-ERP ambitions, autonomous code generation, and heavy write-back workflows until the single-corridor assurance motion converts into annual production. The biggest disconfirming risks are that buyers see existing QA and ALM tools as good enough, SIs resist a product that compresses discovery hours, or secure read-only deployment still takes too long during live programs. Public incumbent pricing is not available in the research, so exact ACV and packaging must be validated through paid pilots rather than assumed from category narratives.

Problem

• Multi-site manufacturers still approve SAP cutovers without a trustworthy view of which custom objects, local variants, and adjacent plant systems will break when a process changes.
• Reverse-engineering those dependencies through workshops, spreadsheets, and SI interviews adds weeks of delay to already-funded S/4HANA programs and increases defect, rollback, and budget risk.

Solution

• Ingest SAP custom code, configuration diffs, interface inventories, regression artifacts, and prior cutover documents to build a read-only graph of change dependencies for one process corridor.
• For each requested change, generate a blast-radius view, proposed regression pack, missing-owner list, cutover sequence, and rollback checkpoints that can be reviewed inside existing program governance.

Why we win

• The wedge starts earlier than testing, transport, or code-remediation products by solving the pre-test question executives actually ask: what breaks if this plant workflow changes now.
• Defensibility compounds from enterprise-specific dependency graphs, historical rollout outcomes, and cross-system process mappings that are hard for generic copilots or new entrants to recreate quickly.

Milestones

flowchart LR
  Wedge[Single corridor rollout wedge] --> MVP[Read-only assurance graph MVP]
  MVP --> Proof[Approved cutover packet and faster discovery]
  Proof --> Expansion[Multi-plant and adjacent-system expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• Transformation sponsors fund pre-test blast-radius assurance as a standalone budget line instead of treating it as SI discovery overhead.
• One corridor can be modeled from read-only artifacts and copies in under 14 days for the first customer.
• Pilot outputs are trusted enough to be used in a real cutover approval, regression-scope decision, or steering-committee review.
• SI partners accept the product as delivery acceleration and do not block access to customer workflows or data.
• Expansion from one corridor to multiple plants or adjacent systems raises ACV enough to support venture-scale account economics.

Open diligence questions

• In the last two S/4 rollouts, where exactly did undocumented customizations delay cutover approval?
• Which buyer actually owns budget for pre-test assurance when QA, ALM, and SI contracts are already in place?
• What artifacts can a design partner provide read-only in week one without a long security exception process?
• How often do Tricentis, Basis, smartShift, SNP, or SAP ALM already satisfy the blast-radius question well enough for buyers?
• Will leading SIs co-sell this as acceleration, or view it as margin compression on fit-gap and discovery work?

Model sanity

• Revenue engine. Base-case revenue comes from 20 active transformation programs by Q4Y3 at about $250K ACV, with expansion modules doing more of the work than seat growth.
• Must go right. The company has to deliver the first corridor from read-only artifacts in under 14 days so paid pilots convert before SI or security friction resets the sales cycle.
• Model breaks if. The biggest cash risk is the sales cycle stretching toward 12 months, because that sensitivity hurts both year-three revenue and ending cash more than any other single variable.
• Next-round proof. A credible next round is supported once six annual production programs and two SI-sourced expansions prove repeatable ACV, deployment speed, and governance acceptance.

Scenarios

Sensitivity

flowchart LR
  Leads[Targeted S/4 programs] --> Pilots[Paid corridor pilots]
  Pilots --> Programs[Annual covered programs]
  Programs --> Revenue[Program ACV + expansions]
  Revenue --> GrossProfit[Gross profit after delivery costs]
  GrossProfit --> Cash[Ending cash after payroll and opex]

Flags: Revenue concentration remains high because 20 enterprise programs still means a small set of large manufacturing rollouts drive most year-three revenue. · The model assumes SI-assisted distribution starts to matter in year 2; if partners resist the product, CAC and the sales cycle likely drift toward the downside case. · Year 1 and Year 2 gross margin stay below the long-run target because security review, artifact normalization, and customer-specific deployment work remain meaningfully services-influenced.

• Services trap. Each ERP landscape is unique, so the product could degrade into expensive custom project work instead of repeatable software. Mitigation: Start with one process corridor, standardize read-only connectors and outputs, and let partners handle bespoke remediation work.
• Incumbent squeeze. SAP, large SIs, or adjacent ALM vendors may bundle similar modernization features into broader transformation contracts. Mitigation: Stay cross-system, focus on independent blast-radius evidence across ERP plus MES and WMS, and build partner distribution before incumbents close the gap.
• Access friction. Enterprises may hesitate to connect sensitive ERP estates to a new product during high-pressure transformation programs. Mitigation: Launch with read-only ingestion from copies and existing project artifacts, offer tight deployment boundaries, and prove value in a single rollout before broader integration.