Do AMRs Still Need a Warehouse Control System with SAP EWM?
Start With the Software You Already Own
AMRs do not automatically require a separate warehouse control system when SAP EWM is already in place. They require the necessary execution functions, supported connections and accountable operational ownership. Keep an existing WCS when it still performs valuable work; remove it only after proving where every required function will run and how inventory confirmations will remain correct.
That distinction matters when a warehouse adds autonomous mobile robots to an established automation estate. The current WCS may coordinate conveyors, retain equipment-specific rules or provide the maintenance team's incident history. A new robot connection can bypass part of that application without making the whole application redundant.
For this decision, consider the WCS as the site's equipment-execution application, whose actual responsibilities must be inspected. A warehouse execution system may cover overlapping or broader scheduling work. Product labels do not establish whether either application is necessary, and an architecture drawing should not become a shopping list of mandatory software layers.
Start with three inventories: functions used today, functions required by the AMR project, and services already licensed and supported. Mark each proposed change as retained, transferred, newly introduced or retired. This exposes whether the proposal genuinely removes complexity or merely relocates it into an adapter, custom development or an operational workaround.
What SAP's Physical AI Proof of Concept Establishes
On October 27, 2026, SAP described a Physical AI proof of concept at Intel's Chengdu site. Warehouse transport tasks generated in SAP were translated into robot missions, with execution outcomes returned to business systems. The example connects SAP EWM with physical material movement; it is not evidence that every warehouse can remove its current control software.
Intel's account describes requests originating in EWM, robots transporting material, and task status and completion returning to EWM. It assigns enterprise context and workflows to SAP and local robotics capabilities to Intel-powered edge technology. Neither account supplies a universal compatibility list or a production support commitment for a particular buyer's configuration.
SAP's reference architecture, updated October 26, positions Physical AI as complementary to traditional AMRs and assigns physical movement and hardware responsibilities to partners. It identifies availability through an Industry AI offering. Buyers therefore need the scope, supported combinations, deployment conditions and commercial terms of the actual offer, rather than interpreting a reference architecture as a ready-to-install connector for every robot.
The useful purchasing question is specific: which part of our existing warehouse execution will this offer replace, and which part remains? Ask for that answer against your installed SAP release, current equipment and required business process. A successful demonstration is a reason to investigate that boundary, not a retirement authorization for the WCS.
Ask Which Functions Would Move If You Removed the WCS
Arrange a working session around one real transport process and its current configuration. Follow its software dependencies, including small jobs that rarely appear in presentations: location translations, operator corrections, retry records, scheduled exports and support access. A function can be business-critical even when it produces no attractive dashboard.
The following worksheet is an original decision aid, not a prescribed SAP architecture. Complete the current and proposed ownership columns with actual application names and accountable teams. An empty proposed owner is an unresolved removal dependency.
| Function to account for | Evidence from the current installation | Required decision before WCS removal |
|---|---|---|
| Transport request translation | How an EWM task becomes an executable request, including load and location identifiers | Name the supported replacement and who maintains its mappings |
| Dependencies between equipment | Which requests wait for a conveyor, buffer, machine or other process to become available | Assign each dependency rule to a retained or replacement component |
| Robot execution connection | Fleet product, supported versions, command ownership and status handling | Document the approved integration route and prevent competing command paths |
| Business completion and reconciliation | How physical results update the relevant EWM task and handling-unit record | Assign durable correlation, duplicate handling and reconciliation ownership |
| Operational visibility and correction | Actual screens, logs, permissions and procedures used by operators and support | Provide usable replacements before retiring the existing tools |
| Lifecycle support | Release dependencies, configuration backups, monitoring and service coverage | Name who tests upgrades and restores the complete process after a change |
Separate functions that disappear from functions that move. If the old WCS stored location mappings and the new connector stores the same mappings, that maintenance work continues. If a new service handles reconciliation, its license, monitoring and support belong in the replacement scope.
Conversely, do not preserve obsolete functions merely because they exist. A retired conveyor branch may leave unused routing rules and an unnecessary interface behind. Require evidence that a function is still used, then decide whether retaining its present implementation is worthwhile.
Our multi-vendor AMR interoperability guide examines the technical compatibility questions. Here, the narrower decision is whether the proposed software change leaves an essential function unassigned or introduces two applications that both believe they own it.
Compare Three Software Decisions for an SAP EWM Site
Compare alternatives against the same required process and service level. Otherwise, a lean proposal can appear cheaper because it omits retained equipment, reporting or support that another proposal includes. The three choices below describe purchasing decisions, not three universally valid connection diagrams.
| Decision | Conditions that can justify it | What the proposal must establish |
|---|---|---|
| Retain the existing WCS and extend the robot connection | The application still serves important equipment and its interface and support path remain viable | Added robot scope, end-to-end confirmation ownership, upgrade compatibility and the cost of retained dependencies |
| Retain applicable EWM MFS functions and add the required robot integration | The site already uses or has validated MFS for suitable fixed automation, with separately supported robot execution | Exactly which functions need no separate WCS, which connectors and fleet services remain, and what migration is required |
| Add or retain a cross-equipment execution application | Identified coordination requirements remain uncovered across robots, fixed equipment or process areas | Named decisions and dependencies it owns, the work it removes elsewhere, and a measurable operational benefit |
Retaining the WCS can be the practical first stage when the AMR project affects a small portion of a larger operation. Limit the extension to the required robot process and expose its interface clearly. Retention should still include a review of support life and upgrade costs; keeping software indefinitely without that review simply postpones the decision.
The second choice is attractive only when the required functionality is genuinely covered. Existing MFS use for fixed automation does not establish a supported connection to the selected mobile fleet. Demand a configuration-specific description of the robot integration and any services it needs before removing another application.
The third choice needs a concrete justification. For example, a process may need to coordinate a pallet's release from storage with a robot delivery and a downstream production window. Ask which current component cannot perform the required coordination and why. Calling the proposed product warehouse orchestration does not by itself demonstrate a missing function.
A mixed decision may be appropriate: preserve the WCS for one equipment area while using a different approved connection for a new robot process. Define the boundary and the business completion path explicitly. Partial retirement can reduce scope, but it may leave most recurring charges intact.
Keep the MFS Decision Separate From Robot Fleet Management
SAP's MFS learning documentation explains that suitable automatic-warehouse scenarios can connect EWM to the control level without an additional warehouse control unit. PLCs retain real-time equipment control, and third-party arrangements can also be retained. This is an established material-flow capability; it is different from the recent Physical AI proof of concept.
Do not turn that example into a claim that MFS supplies the selected AMR's navigation or robot fleet management. The mobile system still needs an approved execution arrangement. Ask bidders to show what already works in the installed environment, what requires configuration, and what is new integration development.
Similarly, a robot connector should not silently take ownership of fixed equipment that remains under another controller. Mark which business transactions enter each path and where their results return. The project should have one agreed interpretation of completion even when separate technologies execute different legs.
A proposal labeled SAP warehouse robotics integration should identify the exact service, version and supported deployment approach. Distinguish current documentation from historical diagrams. Ask which interfaces are supported for the intended go-live date, who maintains them, and whether a future SAP or fleet-software update changes the agreed support boundary.
Price the Whole Migration, Including Retained Interfaces
Use future costs that change between the options. Historical WCS purchase costs are already incurred; they should not be charged again to the retention option. Equally, an existing subscription is not an avoidable cost if the proposed migration leaves another production area dependent on it.
Consider an original hypothetical five-year software comparison, using illustrative dollars rather than supplier prices. Retaining the WCS and adding the required robot integration costs $95,000 upfront and $48,000 annually: $335,000 over five years. Removing the WCS and implementing all replacement functions costs $170,000 upfront and $30,000 annually: $320,000.
The apparent five-year advantage is only $15,000. That amount is the allowance for any omitted migration costs before the replacement becomes more expensive on this simple basis. If an additional $25,000 cutover and parallel-operation package is required, and was not included elsewhere, the replacement totals $345,000, exceeding retention by $10,000.
This comparison excludes discounting, tax, downtime and robot purchases, and assumes recurring charges apply for five full years. It is not an ROI forecast. The lower annual figure must cover the receiving applications, integration maintenance and support for all transferred functions. Any option-specific infrastructure or hardware also needs a separate cost line.
Ask when old charges actually stop. Notice periods, minimum commitments and shared-site licenses can delay savings beyond the technical cutover. Price historical-log access, archive exports and required support overlap. Warehouse control software is retired commercially only when its remaining obligations and dependencies have been resolved.
Prove Inventory Confirmation Survives a Cutover
Before removing a software component, test whether the replacement preserves the relationship between physical movement and the business record. The critical outcome is that the same completed movement cannot accidentally create a second transport or a second effective inventory confirmation when information is delayed or repeated.
Use an original hypothetical transaction: an EWM warehouse task requests movement of handling unit HU-472 from a receiving location to a production buffer. The robot completes the delivery. The integration service records the result, but communication fails before the business acknowledgment is available. After restart, the service sees an uncertain request.
Ask the proposed implementation to resolve that specific uncertainty. It must correlate the original task, handling unit and robot execution, inspect the authoritative transaction state, and avoid issuing another physical move simply because an acknowledgment is missing. Duplicate completion delivery should not create a second effective business posting.
This is a business-effect requirement, not a claim that messages arrive exactly once. Messages may be repeated; the receiving logic must recognize previously processed results or reconcile uncertainty under the agreed process. Assign who owns the durable record and who can authorize a correction when automated reconciliation cannot establish the truth.
During migration, run the new path in observation or another approved non-commanding mode first. Comparing results can reveal mapping differences without allowing two systems to dispatch the same work. At cutover, identify outstanding tasks and decide which path finishes each one. Do not move unresolved work into the new route merely because a maintenance window is ending.
Include three targeted challenges: a delayed completion, a repeated completion and a restart with a task in progress. Inspect the resulting EWM records and physical handling-unit location. A successful test must preserve the intended business effect and leave uncertain work visible to an authorized person.
Rollback also needs a transaction boundary. Restoring yesterday's configuration does not undo a pallet move completed today. Define which new requests can return to the previous path, how active work is reconciled, and when the old application becomes eligible for permanent shutdown. This is the evidence that supports removal, rather than a demonstration that an empty robot can accept a mission.
Turn the Preferred Architecture Into a Contract
The selected proposal should identify software that stays, software that is added, and software that can be decommissioned only after named conditions are met. Include licenses, integration components, data retention and operational tools. A general statement that WMS integration is included does not explain those boundaries.
For every transferred function, record the receiving product, configuration owner, acceptance evidence and support owner. Confirm who coordinates incidents that cross SAP, integration services and robot software. Our warehouse automation integrator guide covers selecting that delivery team; the SAP-specific requirement here is a contract aligned with the actual retained and retired applications.
Separate a feasibility engagement from a production commitment. If a capability still needs project-specific development, define the deliverable and the decision gate before committing to decommissioning. For an Industry AI offer, obtain a written description of included services and the conditions under which the proposed configuration will be supported.
Require a complete exit package for the retired component: exported configuration, accessible transaction history, resolved open tasks, updated operating procedures and confirmed cancellation dates. For retained components, require an upgrade plan that covers the new connections. A smaller application diagram offers limited value if operations loses visibility or becomes dependent on an unsupported customization.
The purchase decision can then be precise: retain the WCS because specified functions remain valuable, remove it because validated replacements cover them, or introduce an execution application because an identified coordination requirement is otherwise unmet. Each outcome is defensible when its functions, costs and inventory consequences are explicit.
Focused FAQ
Does SAP EWM make a separate warehouse control system unnecessary?
Sometimes. The decision depends on the configured equipment and execution functions. Existing WCS responsibilities may be covered elsewhere, but they must be assigned and validated before removal. The number of AMRs alone does not determine the answer.
Can EWM MFS replace the fleet manager for our AMRs?
Do not assume so. An applicable MFS installation and a supported mobile-robot execution arrangement are separate questions. Require evidence for the selected fleet and process rather than extending a fixed-automation example to robot navigation and fleet operation.
Does the Intel demonstration prove that our robots can connect without integration work?
No. It demonstrates a particular proof of concept linking SAP tasks and physical execution. Your proposal still needs supported versions, process mappings, deployment conditions and acceptance evidence. The announcement does not establish universal compatibility or eliminate project work.
Should we buy a warehouse execution system as well as a WCS?
Only when the proposed application covers necessary work that is otherwise missing or materially improves the existing arrangement. Identify its decisions, dependencies and operational outcome. Overlapping product names are not evidence that two separate purchases are required.
What is the strongest reason to keep the existing WCS during an AMR rollout?
It still performs required, supported functions that the robot project has not replaced. Retention can limit migration risk while a new process is introduced. Define its continuing role and review date so a temporary arrangement does not become an unexplained permanent dependency.
What must be proved before the old WCS is switched off?
Required functions must have working replacements, outstanding tasks must be reconciled, and repeated or delayed results must not duplicate the physical or inventory effect. Operations also needs usable monitoring, support and rollback procedures, with historical records and cancellation obligations addressed.
Evidence note: This analysis uses the SAP announcement, Intel account, SAP reference architecture and SAP MFS documentation. The reported proof of concept does not guarantee compatibility or performance for an arbitrary deployment. The decision worksheets are original editorial analysis; the transaction scenario and cost figures are hypothetical.
