Five steps to success in multi-site CloudSuite

Two weeks ago, Fortude’s team was at the M3 User Association UK Annual Conference 2026 as a Diamond Sponsor. This gave us the opportunity to take to the keynote stage to share something rare in the world of ERP transformation: an honest, in-progress story. Not a polished case study with hindsight smoothed over the rough edges, but a live account of a multi-site Infor CloudSuite implementation. 

Fortude’s Poshitha Ratnayake, Head of Consulting for EU & UK, led the conversation with Ines Ashton, Digital & AI Strategy Director (CIO), of The Compleat Food Group. Together, they uncovered what it takes for a business on an ambitious acquisition mission to scale CloudSuite across multiple sites without losing momentum, quality, or business continuity. 

Here’s a summary of that conversation, structured around five pillars that define a successful multi-site CloudSuite rollout. 

The most important decision in any multi-site ERP project happens before a single site goes live: it’s whether to build a shared blueprint or let each site define its own configuration. With nine legacy systems and no way to compare site performance, a unified template was essential for this customer. 

In practice, that meant starting with Infor CloudSuite Food & Beverage and anchoring it around core manufacturing, supply chain, and finance. Fortude worked alongside the central business team to evolve that blueprint through the early rollout phases, building a solution that could be confidently reused. 

The rule became simple: design once, reuse everywhere, unless there is a business-critical, proven reason not to. The result was a dramatic reduction in implementation costs and a significant increase in rollout speed. After the second site went live, the team knew the blueprint worked. Everything that followed was about optimizing the process of deploying it.

If the blueprint is the foundation, data is the material you build it with. And in a multi-legacy environment, it is also the most likely point of failure. 

The customer understood the importance of data migration early on in the implementation. With two decades of unmanaged data across some systems, the team knew that if a go-live struggled, it would be because of data, not the blueprint, not the system configuration. That clarity shaped everything. 

Fortude treated data migration as a repeatable, business-owned process, not a one-off technical task handed off to IT at the last moment. That meant early mock conversions, rigorous validation led by business users (not just technical teams), and multiple dry runs leading up to each go-live.  

The business benefit was tangible: each site went live with a high degree of trust in the system. The Fortude data migration toolkit, refined across each deployment, became a key enabler of the repeatability that made scaling possible.

One of the clearest themes from the keynote was that a project of this complexity does not succeed on partner capability alone. It requires the right people, in the right roles, on the client side and a partnership model that treats the implementation partner as a genuine collaborator, not an order-taker. 

The central business team was built with purpose: fifteen individuals who owned decisions on behalf of the whole company, consulted the sites, but were ultimately accountable for the outcome. Critically, this team included strong representation in areas like EDI – the integration layer that connects the business to its customers and suppliers – people who understood day-to-day operations, not just program management. 

On Fortude’s side, the governance model was structured but not bureaucratic. It included weekly joint tracking sessions, clear ownership of delivery versus business decisions, and a culture of surfacing concerns early rather than hoping problems would resolve themselves. 

Empowerment mattered too. When a site requested customization that did not serve the broader business, the answer was no, and it held. That same discipline is what gave the global template described at the start of the blog its standing.

In a 24×7 manufacturing environment, change management cannot be an afterthought. Operators running production lines at midnight need the same confidence in the system as those on the day shift and that confidence only comes from proper, timely training. 

The target was 80% training completion across all departments before go-live. Not approximately 80%. Not 80% with the intention of catching stragglers afterwards. 80% and it was non-negotiable. 

Training was role-based and pragmatic, focused on what each person needed to do on day one, not an exhaustive tour of system features. Fortude supplemented this with a blended delivery model, combining key user enablement close to go-live with offshore support for extended coverage. 

What the team learned after the first site go-live shaped every subsequent deployment: even well-attended training does not guarantee retention. Night shifts in particular were prone to gaps. The response was to treat every first shift on a newly live system as a mini go-live with the full central team present and hypercare support extending two weeks beyond the cutover date. Fortude’s team participated in hypercare not just to support the site, but to understand the operational context firsthand, so that when business-as-usual support began, nothing came as a surprise.

Go-live is not the finish line. In a project that spans multiple sites over multiple years, the ability to sustain momentum and to keep learning is what separates implementations that deliver long-term value from those that gradually lose pace. 

Fortude’s ongoing support relationship means that the same team that supported hypercare transitions into business-as-usual support. Beyond individual site support, the implementation was designed from the outset to keep improving. Governance and provisioning structures have been built to accommodate ongoing feedback, monitoring, and refinement. This also means continuously aligning system and technology changes with evolving business goals, so the ERP grows with the business, not behind it. 

Another important aspect of managed services is system updates and the testing that follows. With Fortest — AI-powered automated regression testing, we maintain 90% reduction in test cycle time and 100% accuracy across cycles. The product’s AI capabilities also help detect broken scripts, automate script generation based on real user workflows, and provide security for your system data throughout.