How to design risk out of a complex ERP migration

An ERP migration is known as one of the riskiest projects an organization can undertake. Not because the technology is complex, but because almost every business process is affected simultaneously. If it goes wrong, it's not just a project at stake, but business continuity itself.
‍

That explains why many organizations maintain their ERP system longer than is actually desirable. Not because the current system is still adequate, but because the move to a new platform feels like a leap of faith.
‍

However, a migration doesn't have to be an all-or-nothing moment. Mastermate's experience shows that you can not only manage the biggest risk, but even largely design it out. At Composable Futures, Novulo implementation partner Retailstars and Mastermate discussed how they designed their migration strategy and adhered to it with military precision.

The real complexity isn't in the software

Many ERP projects are seen as a technical replacement. In reality, the complexity lies elsewhere. Over the years, exceptions, customizations, specific pricing rules, and hidden dependencies between processes emerge. They don't exist in documentation, but in daily operations. Only during a migration does it become clear how much of that knowledge has become implicit.
‍

Mastermate is a good example of this. The cooperative consists of five independent regional companies, 48 branches, and a central distribution center and data center. Products originate locally but must be available throughout the entire chain. Prices are not simply data, but the result of complex priority rules. Additionally, the existing Microsoft AX system had accumulated years of customizations.
‍

Precisely because of this, the migration wasn't about transferring data, but about preserving business logic.‍

Start where the risk is greatest

Many organizations choose to migrate a small branch or a limited process first. It feels safe: if something goes wrong, the impact remains limited. Mastermate and Retailstars deliberately chose the opposite strategy.
‍

The team deliberately chose not to start with “a small regional company,” but with the distribution center, because almost all critical dependencies converged there. Out-of-assortment items, WMS integrations, logistics messages, and pricing logic all came together here. If this component worked reliably, it instilled confidence for the rest of the organization. So the question wasn't: where can we start most easily? But: Where is the greatest operational risk?
‍‍

From risk management to risk by design

Many ERP migrations still follow the same pattern: months of testing, going live over a weekend, and hoping everything works when users log in on Monday morning. Even with a phased migration, every go-live remains a tense moment. Only after the switchover does it become clear whether processes behave as expected in practice. The approach Retailstars chose together with Mastermate goes a step further. Instead of accepting the risk and managing it as best as possible, they deliberately designed it out. Not by testing even more or adding extra project control, but by fundamentally restructuring the migration.
‍

The old AX system and the new Novulo platform ran in parallel production during the transition. For this purpose, Retailstars developed components that allow both systems to function seamlessly side-by-side and run their processes synchronously. This creates two data streams that can be compared side-by-side. This creates a temporary bridge between old and new, where both systems process the same transactions and their outcomes can be continuously compared. And that's different from testing: it's actual production behavior that you compare at scale. Only when the outcomes of both systems are demonstrably identical does a process switch over. “We were literally able to go live interface stream by interface stream and process by process,” said Rob van der Heijden, CEO of Retailstars. Not a leap of faith, but a transition that was verified beforehand.
‍

Don Heijmans, ICT Manager at Mastermate: “A phased transition was chosen to minimize risks to business continuity without creating additional complexity. The classic approach of going live with everything in one day simply doesn't work for us. That's why we chose to take small steps each time."‍

Why running in parallel makes such a difference

The value of this approach became evident at Mastermate through a detail that would otherwise only have surfaced after the system went live. Various regional departments were found to be storing customer information differently. “In the picking order for the warehouse, one system indicated the package should go to Delfgauw, while the other system said Volendam. Clearly, something was wrong with the configuration.” Because the two systems ran in parallel, this issue came to light well before the actual switch. With a big bang approach, the same package would likely only have ended up in the wrong region after going live.
‍

Naturally, unexpected situations still arise with this approach. That's inherent to any migration. The difference is that a problem never impacts the entire organization. A deviation is confined to a single process or interface. The team can roll back that specific go-live, analyze the root cause in isolation, and resolve the issue before proceeding to the next step. As Van der Heijden describes it: "The entire team is then available to address that one incident, ensuring it never escalates into a major problem."
‍‍

Architecture determines how much risk you can mitigate

This migration method requires more than just a meticulous project team. Temporary synchronization, parallel processes, controlled activation, and continuous comparison of production outcomes are only possible if the underlying software architecture is designed for them. Many traditional ERP systems are built around a single cutover moment: the old system is switched off, and the new one is switched on. A controlled parallel transition simply doesn't fit that model.
‍

This approach was only possible because the underlying platform was designed for it. The Novulo platform allowed for the addition of temporary components, individual activation of processes, and isolation of business logic. This enabled old and new systems to function side-by-side for an extended period without disrupting daily operations. Once a process was fully migrated, the temporary synchronization components were removed.‍

From gamble to controlled process

This approach does come with some demands. The IT department manages two systems simultaneously for an extended period, and the old system's database is put under additional strain by the synchronization. At Mastermate, there was already limited capacity in that area. In practice, this didn't cause major problems, and the trade-off was quickly made: the significant risk reduction and comfort during the transition far outweighed the temporary additional burden.
‍

This fundamentally changes the nature of the project. An ERP migration no longer has to be an all-or-nothing moment that you approach with bated breath. By running processes in parallel and only switching over when the outcomes are correct, migration becomes a controlled process instead of a gamble. This transforms the entire nature of an ERP migration. Success is no longer determined by one tense go-live weekend, but by hundreds of small, pre-validated moments.