"We have no capacity for that this year." That one sentence from IT stops automation projects the operations side has long since settled on - and it almost always lands before anyone has costed the work properly. An AMR retrofit takes 10 to 15 IT development days spread over roughly four weeks. For fixed-installation automation, a comparable figure can often only be established after signing. This article explains why, who carries which part of the effort, and how to put both into a number an approval round accepts.
IT decides even without starting the project
A warehouse automation project in a mid-size firm rarely has fewer than six stakeholders at the table: site or logistics management, the managing director, the CFO, procurement, and IT. The project is almost always started by the operational side, which feels the labor shortage and the peaks every day. It gets approved only if none of those roles uses its veto.
In practice, the IT lead holds exactly that veto. A project that excites logistics and unsettles IT does not clear approval, and the objection never has to be spelled out. Capacity in a mid-size firm is genuinely scarce: the same small team runs the ERP, the WMS, the shipping systems, and daily operations in parallel, with the IT lead often doubling as the systems owner. Every day a project consumes is missing from a calendar that is already fully booked.
That is why IT's deciding question is rarely "is this technically sound?" but "how deeply does this reach into my landscape, and how many developer-days does it cost me?" Answer that badly and you get no yes, however convincing the business case is for everyone else.
Why the number is often unavailable before the decision
The common assumption is that vendors talk the IT effort down. Often something else is going on: they find it hard to evidence at decision time, because the basis for it is confidential.
The specification arrives after the signature
For cube-based grid systems, the interface documentation is usually not freely available. It is common for a vendor to release the specification only under a non-disclosure agreement, with the developer documentation behind a login. For the internal IT team that means: at exactly the point where it is asked for an effort estimate, it frequently lacks the basis to check one. It then depends on the vendor's figure instead of being able to do the math.
Shuttle and mini-load AS/RS sit one layer lower, at control level. There, telegram structures are defined per warehouse, interface type, and device type, and a realistic test generally requires warehouse downtime. Neither is something a mid-size IT department scopes from a standing start.
The connector market is the real evidence
In the German-speaking market alone, several software houses sell the connection to a cube grid as a product of its own - at a fixed price, with the explicit promise that it removes time-consuming software development. A product market rarely grows up around an interface that takes two weeks to build. One German software house publicly describes its own connection as a year-long project for its largest development team, deliberately built without middleware - a single case, but a documented one.
None of this is a criticism of the technology. Cube and shuttle systems solve density and throughput problems a retrofit does not solve, and buyers with those problems are right to choose them. It is a statement about predictability: the IT effort of those architectures is harder to pin down before the decision, which is why it tends to show up in the approval round as a risk rather than as a costed line item.
Checkability as a selection criterion
For vendor selection, then, the figure someone quotes matters less than what you can verify about it up front.
| Check before signing | Fixed-installation automation | AMR retrofit |
|---|---|---|
| Interface specification | Frequently only after signing, under NDA | Documented, available up front |
| Own test possible | Mostly at project start, often via the integrator's emulation | Sandbox with an identical interface contract |
| Who builds the connection | Integrator or a purchased connector | Your own IT team against a documented API |
| Form of the effort statement | Predominantly project runtime in months | Development days on the customer side |
The columns describe the common pattern, not every individual case; some integrators work very transparently from the start. That is precisely why all four are worth asking in any vendor conversation, long before price comes up. A vendor who hands over the specification early makes its effort estimate verifiable.
Where the logic ends up - the cost driver no quote itemizes
The second block has little to do with programming and a lot to do with ownership. It decides whether you end up with one more system in the house that somebody has to look after.
In cube-based systems, the control software that ships with the grid is typically not a full warehouse management system. Bin contents are then maintained and backed up in the customer's WMS, and every movement is triggered by an upstream system. Depending on the interface level chosen, grouping, bin preparation, and optimization logic can move there as well. A connection turns into an extension of your own system in that case, with everything that implies in maintenance over the years.
In an AMR retrofit, the WMS stays the leading system. The orchestration layer translates its orders into robot logistics and reports every pick back; no second inventory ledger appears that has to be kept in sync with the first. Which interface patterns apply and how the connection runs technically is covered in the article on WMS integration. For the effort question only the consequence counts: what does not move into your own system does not have to be maintained there.
Who provides what
An effort block on its own says nothing about who carries it. For IT planning that split is the decisive part, because only your own share loads your own team.
What the vendor handles
The bulk of the preparatory work sits on the vendor side: the documented API specification, a mapping template for the data fields, prepared test scenarios, a sandbox that behaves identically, and hypercare support in the first weeks after go-live. On top of that the orchestration software itself. At NEO that is NEO:os, working as a layer between the existing WMS and the robot fleet, not as a second, competing warehouse management system. How the NEO platform fits together - software, robot fleet, and picking station - is on the platform page.
What your team provides
The customer share is clearly bounded, but a good part of it is development work. Your team builds the client against the documented interface, maps the data fields of your own WMS onto the order and confirmation format, and implements error handling and recovery. Alongside that sit the items that are not programming: WMS access and a named contact, clarification of article-master questions, sign-off on the test cases, and the internal IT security review. That last item is regularly underestimated. When external software connects to the WMS, security wants to examine authentication and data access, and in many companies that approval process has its own lead time. It belongs at the start of the project, not at the end, otherwise a one-day review becomes the bottleneck days before go-live.
In total, the customer share for an AMR retrofit comes to 10 to 15 IT development days across roughly four weeks of calendar time. The gap between those two numbers is what matters for planning: the developer-days are the actual work, the four weeks are the window it falls into, with waiting time, approval loops, and test runs in between. Read the four weeks as one person fully occupied and you overestimate the effort by more than double.
What a retrofit does not require
Equally important is the list of things that never come up. An AMR retrofit requires no WMS replacement, no material flow controller to maintain, no PLC connection, and no customizing of the existing systems. Those are exactly the items that make up the bulk of IT effort in conventional automation projects, and a major driver of the 12 to 36 months such systems need to reach go-live.
Gross versus net
So far only the gross figure is on the table: the project effort for the rollout. An honest assessment is missing the other side of the ledger, and that side is skipped in almost every estimate.
Manual picking is not free for IT. Spreadsheet workarounds someone maintains and repairs. Inventory corrections when the WMS and reality drift apart. Scanner support, carrier interfaces, recurring one-off reports for peak planning. That load appears in no project plan because it is already there, but it consumes capacity continuously.
After go-live, part of that standing work drops away, because automation keeps inventory in real time and closes off error sources. The 10 to 15 days are therefore project load, not standing load. Carry only the gross figure into the approval round and you argue against yourself. The defensible number is the net effort: project days minus the capacity the status quo already consumes today.
What remains after go-live
In most quotes the effort discussion ends at go-live. The ongoing share is what decides whether the calculation still holds three years later.
Where a dedicated control or middleware layer sits between WMS and equipment, licensing, support, and upgrade contracts run for the life of the system. Both sides are version-coupled in that setup: a WMS release can pull adjustments through the intermediate layer, and the other way round. Later extensions - an additional station, a new order type, another site - usually run as a change request with the integrator, because the knowledge about the interface lives there and not in your house.
With a hosted orchestration layer and a versioned interface, that block largely disappears. Updates run server-side, and the connection set up once carries the expansion from one station to several without new integration work. For IT that is the difference between a project that closes and a system that stays on the maintenance roster permanently.
How IT carries the number into the approval round
The numbers are settled. Now they need a format a leadership team approves inside one meeting.
Developer-days, not months, not FTE
Effort quoted in months sounds like a person tied up and invites a quick no. The same effort as "15 developer-days across four weeks, deliverable alongside daily operations" is a resourcing decision a COO can make without shutting IT down. The unit is not cosmetic; it is the difference between an approvable number and a blocked one. FTE figures do not work here, because they imply a full-time assignment that does not exist.
The workshop before the approval
The defensible number is not produced at a desk but in a joint session between internal IT and the vendor's technical team, and it belongs before the approval, not after. Three things get settled there: the interface specification, the internal effort in developer-days, and a timeline with milestones. The result is a one-page document the IT lead can carry into the approval round. Not an estimate, a jointly owned effort commitment.
Vendors who publish their specification anyway can offer that session early. Where documentation only becomes available after signing, the workshop moves behind the decision, and clarity on effort moves with it.
The fallback when even four weeks do not fit
Sometimes IT is booked out even for four weeks. The project is not dead then, it starts smaller. A pilot can run without full WMS integration, using manual order handover or a simple file-based connection. The operational side gathers real data, and full integration follows once IT capacity frees up. The effort is not avoided, but it is decoupled.
The honest read
Two things belong in a defensible assessment that vendor material rarely includes.
First, 10 to 15 development days are not a unique selling point. For connecting a modern robotics API, an order of magnitude of two to four engineer-weeks is the market norm, and other AMR vendors sit in the same range. The difference is not the value of the number but whether it can be verified before signing, and whether a second inventory ledger ends up in your house afterwards.
Second, the strongest point for IT is structural: in an AMR retrofit the shelving stays as it is. If the integration fails on go-live day, the team keeps picking manually while the fault is fixed. The safety net is the existing manual process, not a contingency plan that has to be built first - how that fallback runs in detail is in the risk catalog of the article on WMS integration. After a conversion to a fixed architecture, that route back does not exist.
That this calculation holds particularly well for thin IT resources in mid-size firms is no accident. It is built for that starting position. On a pay-per-pick basis, commercial risk shifts to the vendor as well, who supplies robots, station, and software.
Next step: make the IT effort concrete for your warehouse
The market overview "Lagerautomatisierung 2026" compares the architectures with their integration, timeline, and risk profiles - including the IT dimension that matters for sign-off: download the whitepaper (in German).
If you want to enter the approval round with a defensible effort estimate for your own WMS, we settle interfaces, data flows, and a realistic timeline in one free session: See NEO in action. The broader resource library collects the deeper comparisons.
