A growth target that ruled out adding people
DAB Pumps makes more than two million motor-driven water pumps a year, sells into 150 countries, and reported 415 million euros in turnover. Its constraint was not revenue growth, it was headcount: the company wanted to keep growing internationally without adding people in proportion to that growth, which meant every manual workaround built up over years of expansion had become a direct obstacle to the strategy rather than a tolerable cost of doing business. On-premises ERP systems, local customizations, fragmented processes, and spreadsheet patches had accumulated the way they do at any manufacturer that grew faster than its systems could absorb, and the legacy platform was also approaching end of life, forcing the decision regardless of appetite, timing, or how comfortable anyone inside the organization felt about the disruption that was coming either way.
That combination, a hard business constraint plus a forced technology deadline, is a more honest starting point for an ERP program than most. It meant DAB could not frame the project as a nice-to-have modernization. It had to work, and it had to work in a way that changed how logistics, finance, and production planning actually operated, not just which screens employees clicked through.
Redesign before migration, not during it
DAB's implementation partner Altea IN and the company itself did something that gets skipped more often than it should: before touching the cloud, DAB redesigned its core processes first. It built a single logistics structure and a common chart of accounts to replace the local variations that had grown up site by site over years of independent plant-level decisions, reducing reliance on bespoke customizations and creating a template DAB could reuse for every later rollout rather than reinventing the approach at each new location.
This ordering is the opposite of how a lot of ERP migrations actually run, where the cloud platform goes in first and process harmonization gets promised for a later phase that often never arrives, because once the new system is live there is no forcing function left to drive the harder organizational work. DAB removed that risk by doing the harmonization while it still had leverage to insist on it across every site, before any plant had a working system of its own to defend as the status quo worth protecting.
The transaction-elimination number is the tell, not the headline
Infor's claim, more than two million internal transactions eliminated through the move to single-logistics transfer orders, is vendor-reported and the article does not independently verify it. The mechanism behind the number is worth taking seriously regardless of whether the exact figure holds up under scrutiny: when each site tracked inventory movement separately, a single physical transfer between locations could generate multiple redundant system transactions, each one a point where data could drift out of sync with what was actually happening on the warehouse floor.
Collapsing that into single-logistics transfer orders is a structural fix to how the data model works, not simply a reporting cleanup layered on top of the old process. It is also the kind of improvement that will not show up in a quarterly earnings call or a flashy vendor case study headline. It shows up in whether planners trust the numbers they are looking at day to day, and in whether a bottleneck at one plant becomes visible to the other five before it cascades into a much larger supply problem.
Centralized planning changes who can see a problem first
With centralized material requirements planning running on AWS and Infor OS, DAB can now run planning simultaneously across plants instead of waiting on data that used to be delayed by location and time-zone differences between sites spread across different continents. That is a meaningful operational shift for a company running six production plants and global subsidiaries, because the lag between a demand signal appearing in one region and a production adjustment happening in another is exactly where manufacturing networks lose money, quietly and continuously, without anyone pinpointing the cause.
The rollout itself was staged deliberately: Italy, Hungary, and France first in January 2026, five of six plants plus global subsidiaries by October 2026, with Asia-Pacific and other markets still ahead on the roadmap. That pace, roughly nine months to cover most of the network, is a reasonable benchmark for CIOs sizing their own multi-site cloud ERP timelines against a manufacturing footprint of comparable scale and geographic spread.
AI is the next phase, deliberately, not the current one
DAB's next planned step is Infor Velocity Suite, adding AI, optical character recognition, and automated workflows to logistics and fulfillment across the network. Notably, that is explicitly described as the next phase, not something bundled into the current rollout alongside the cloud migration itself. The company is choosing to prove out clean, centralized data and process standardization first, then layer automation on top of a foundation it has already validated in production across five plants.
That sequencing argument keeps showing up across the better digital-transformation stories this quarter, and it is worth taking as a pattern rather than a coincidence limited to one Italian pump manufacturer. AI recommendations inherit whatever quality the underlying data already has, for better or worse. DAB's bet is that the Velocity Suite rollout will be faster and more reliable precisely because the data foundation work already happened first, rather than trying to fix both problems inside the same project at the same time.
What this means for the roadmap
For a reader managing a multi-site manufacturing footprint, DAB's case is a useful stress test for any transformation business case built primarily around headcount avoidance as the stated goal. The honest question worth asking internally is whether your organization has done the process redesign work, the chart-of-accounts harmonization, the logistics-structure unification, before or alongside the technology migration, rather than deferring it to a later phase that experience across most ERP programs suggests rarely gets funded once the new system is already live and the pressure to move on has returned.
The specific transaction-reduction figure deserves healthy skepticism since it comes from the vendor rather than an independent audit. The sequencing does not need the same skepticism, because the underlying logic holds regardless of whose ERP sits beneath it: fix the structure, then migrate, then automate, in that order, and move to the next step only once the previous one is actually clean, verified, and working the way the team expected it to.
