From Zoo to Architecture. The Pragmatic Migration Path.

“How do we actually get there without a Big Bang, while keeping operations running, with a business that still needs to function tomorrow?”

We have heard this question frequently over the past few weeks. It rarely comes from IT and almost always from executive management. That is exactly where it belongs. Migration is not a technology question. It is a strategic and financial decision with technical consequences.

This fifth and final part of the Greenfield series is the answer. It contains the migration path we would recommend to our clients. A three-year roadmap, a seven-phase selection approach, an honest business case with value-lever categories, and finally the five mistakes we repeatedly see in migration projects.

Big Bang or Stages?

Both approaches exist, and both have their place. Big Bang means the entire tool landscape is replaced in a single large project with a fixed go-live date. It is painful in the short term and sometimes the right choice in the long term. But it is rarely realistic, especially for a mid-sized company with ongoing operations and limited project capacity.

Stage-based migration means the target architecture is defined upfront, while implementation takes place over several years in manageable steps. Pragmatic, controllable, financeable. But it requires a clear plan and discipline. Otherwise, three years of strategy turn into what we dissected in Part 1: the next zoo.

Our recommendation in the vast majority of projects is clear. Target architecture first, the big plan. Migration in three-year stages, the small steps. Both must fit together, otherwise one of them gets lost.

The Roadmap at a High Level: Three Years, Three Stages

What do these three years look like in practice? In almost every migration we support, they can be structured into three stages, each with clearly defined outcomes.

Year 1: Strategy and Quick Wins

In the first year, three things happen in parallel. First, strategic clarification: target architecture, steering, and business case – in other words, phases 1 and 2 of the selection methodology, which we will examine in more detail shortly. Second, quick wins that save money and reduce complexity immediately, regardless of the broader strategy: license audit, interface inventory, and master data sanity check. Third, the launch of the first major platform selection, typically the ERP core or a similarly central component.

Year 2: Initial Consolidation

In the second year, the first platform goes live, including pilot, rollout, and stabilization. At the same time, the next selection process runs from requirements definition through to contract signing. And it is precisely in this phase that data architecture emerges as its own discipline: master data, data contracts between systems, and the first waves of data cleansing.

Year 3: Embedding the Symbiosis

In the third year, the symbiosis begins to take visible shape. The second platform goes live, the interface landscape shrinks, and the AI data layer is established as a dedicated layer. Most importantly, the governance model from Part 4 becomes operational: roles are filled, routines become established, and shadow IT is channelled into controlled structures.

Three years is an indicative timeframe, not a law of nature. Some migrations take four years, while others succeed in two and a half. What we see in virtually every project is this: less than two years becomes too hectic, while more than four years loses momentum.

→ A good migration does not begin with technology. It begins with strategy.

Tackling Quick Wins and Strategic Levers in Parallel

One of the most common mistakes is separating quick wins from strategy. The argument is that the big target is still being developed, so there is no point in taking smaller steps beforehand. This comes at a double cost: credibility within the organization and immediate savings that are lost forever.

Quick wins are levers that work independently of the target architecture. An honest license audit uncovers six-figure amounts in decommissioned modules or full licenses assigned to occasional users in almost every organization. An interface inventory reveals which point-to-point connections are no longer needed. And a master data sanity check makes every future migration easier.

Strategic levers require the big plan. Platform consolidation is the most obvious one because it is directly linked to the symbiosis model. Data architecture is the less visible but most important long-term lever because it survives platform changes. And the governance model is the most human one because it cements accountability, not technology.

The Selection Approach: The Seven Prozept Phases

Every platform decision within the migration follows the same framework. We call it the Prozept methodology, and it consists of seven phases. It is not the only way to make a good software selection. But it is the approach that results in the fewest expensive surprises.

1. Strategic Preparation: Steering committee, project organization, business case, objectives, change strategy.

2. Current-State Analysis and Maturity Assessment: End-to-end processes, system landscape, data quality, migration effort.

3. Requirements (MoSCoW): Must, Should, Could, Won’t. Use cases. Acceptance criteria.

4. Market Analysis and Shortlist: Longlist, must-have filter, three to five vendors, culture and support.

5. RFP and Evaluation: Standardized tender process, evaluation matrix, transparent weighting.

6. PoC and Live Demos: Real data and use cases, key-user evaluation, references.

7. Decision and Contract: Five-year TCO, SLAs, data portability, IP, governance.

The official seven Prozept phases. Every platform selection within the migration project follows the same framework, from strategic preparation to contract signature.

Three observations about this methodology. First: the most important phases are the first two. Anyone who takes Phase 1 (Strategic Preparation) and Phase 2 (Current-State Analysis and Maturity Assessment) seriously has already won half of the later customization debate. Those who skip them will pay for it in Phase 6 or 7, with compound interest.

Second: Phase 6 (PoC and Live Demos) is the only phase in which real data and real use cases are tested. Everything before that is a promise. Anyone who does not give this phase enough room ends up buying a tool based on marketing slides.

Third: the methodology ends with Phase 7, the decision and the contract. Implementation is deliberately not part of the selection process. It is a separate scope with its own roles, budget, and accountability. Those who mix the two lose the clarity of both disciplines.

The Business Case: What the Migration Is Really Worth

A migration costs money. A lot of money. Three years of concentrated effort, multiple platform transitions, external support, and internal change management. The question is not whether it costs something. The question is where the value comes from.

We see four value-lever categories in every migration, and together they form the business case. They vary in how easily they can be measured, but all four matter.

Direct savings are the most obvious: retired modules, eliminated interface maintenance, consolidated contracts. They appear immediately in the budget and are the easiest argument in discussions with the CFO.

Indirect savings are larger but harder to prove. Efficiency gains from leaner processes, fewer data errors, and reduced training effort for inconsistent system landscapes. They often add up to two or three times the direct savings.

Avoided risks are what does not happen. Compliance gaps, cyber incidents, innovation stagnation because legacy systems cannot support anything new. Difficult to quantify, but often the decisive argument in board-level discussions.

Strategic value is difficult to express in euros, but it determines long-term success. The speed at which the company can react to market changes. Scalability. Readiness for AI and data products that will be standard within five years.

These benefits must be weighed against the investments over three years, typically between €900,000 and €1.4 million. License transitions, external support, internal change management, and implementation effort. In most projects, the balance becomes positive in year two or three, while the strategic value is additional and lasts considerably longer.

→ No one waits until the house is on fire. Yet when it comes to IT architecture, we often do exactly that.

Five Mistakes We Keep Seeing in Migration Projects

We rarely enter projects where everything is running smoothly. That is simply the nature of our business. But for that exact reason, we can identify the mistakes that keep recurring. There are five of them, and all five are avoidable if the first few weeks are taken seriously.

1. Technology Before Strategy

The classic. A technology conference, an enthusiastic CIO, a vendor with an impressive roadmap, and the selection process is already underway before the target architecture even exists. The result is always the same. The tool is purchased, the process does not fit, and the next twelve months are spent on workarounds.

2. Skipping Phases 1 and 2

Strategic preparation and current-state analysis often look like consulting folklore at first glance. Four weeks of workshops, many slides, and in the end a steering committee and a business case. But those four weeks determine whether the next two and a half years run smoothly or require constant correction.

3. Big Bang as a Compromise

Our recommendation is clear: the stage-based approach is better. But three years can feel long, and management wants speed. The result is an attempt to replace multiple platforms at the same time. Risk multiplies, complexity increases non-linearly, and operations suffer visibly.

4. Ignoring Quick Wins

A strange loyalty to the grand strategy sometimes leads organizations to leave obvious levers untouched until the architecture is complete. That is discipline applied in the wrong place. Quick wins create credibility, help fund later investments, and demonstrate that the initiative delivers tangible results.

5. Governance at the End

The most expensive mistake. Platform selection is completed, the system is implemented, and only then does the discussion begin about who is responsible for what. By that time, five business units have built their own data structures, every workflow has developed a slightly different interpretation, and the governance model from Part 4 becomes a cleanup exercise instead of a foundation.

What Remains

At the beginning of this series, we made a confession. Consultants do well from complexity. We do well from Best-of-Breed strategies of the 2000s, from license negotiations with three vendors, from waves of custom AI development, from three-year migration programs. We even benefit from the very zoo we dissected in Part 1.

With this series, however, we wanted to try something different. Not the promise that it will be easy. But a more honest consulting conversation that starts with the target architecture rather than the next tool on the agenda. One that takes the idea of a cost-optimized symbiosis seriously instead of chasing the next hype. One that asks the question “Who will manage this in five years?” sooner rather than later.

No one needs to execute a Big Bang tomorrow. But no one should continue watching the zoo grow today in the hope that the next generation will clean it up.

One final question that you are welcome to take into your next IT strategy meeting. What would your successor criticize if they looked at your current tool landscape five years from now? And what part of that can you change today without waiting for the big plan?

With this article, the Greenfield series comes to a close. Thank you for reading. Those who would like to continue working with us are in the right place. Those who do not, hopefully still leave with a few images that stay in their minds.