CHAPTER 3
Phases
Design Phase, Understanding the Legacy, Envisioning the Future
CHAPTER 3
Phases
Design Phase, Understanding the Legacy, Envisioning the Future
The design phase is where migration decisions are made or deferred.
Every decision made well in the design phase saves multiple decisions made badly during execution. Every decision deferred from the design phase becomes a problem that arrives at the worst possible time, when the system is being configured, when the data is being migrated, when the cutover window is open and there is no time to think carefully about anything.
The design phase has a specific purpose. It is not to plan the migration. It is to define what the organisation will migrate to. Not what it currently has, that is the legacy. Not what it had before the last system change, that is the past. What it should have when the migration is complete and the organisation is operating at the standard the new environment makes possible.
This requires two things that most organisations find more difficult than they anticipated. The first is understanding the legacy honestly, not the official version of how processes work but the actual version, including the variations, the workarounds and the gaps that have developed over years of operation. The second is envisioning the future deliberately, making specific, documented decisions about how processes should work in the new environment, rather than defaulting to how they work now.
Both of these are design activities. Both require time, discipline and the involvement of the people who actually operate the processes not just the people who manage them. And both must be completed before migration execution begins, because the decisions made in the design phase are the foundation on which everything else is built.
Key Takeaway:
The design phase determines migration success before a single transaction is moved. The quality of the decisions made in this phase about the legacy state, the future state and everything that must change between them determines the quality of every subsequent phase.
"Migration succeeds in the blueprint, not in the execution."
MarvinPro_|_March_2026
marvinpro.com
Understanding the legacy means understanding what the organisation actually has not what it thinks it has.
Most organisations have a reasonable understanding of their official processes. They have process maps, standard operating procedures and system documentation that describe how work should be done. What they often do not have is an accurate understanding of how work is actually done the informal adaptations that have developed alongside the official processes, the regional variations that were never formally approved, the workarounds that were created to handle scenarios the official process could not accommodate and that have since become the standard way of working.
The gap between the official process and the actual process is the most important thing to understand before migration begins. It is where the most expensive migration problems hide.
A process map that describes the official approval flow is not sufficient for migration design if the actual approval flow involves informal decisions that bypass the documented steps. A data migration that moves the data from the legacy system to the new one is not sufficient if the data was created according to regional conventions that the new system's data model cannot accommodate. A system configuration that reflects the official process description is not sufficient if the people operating the process will continue to use the workarounds they developed because the official process did not meet their actual needs.
Understanding the legacy requires going beyond the documentation. It requires conversations with the people who operate the processes every day the team leaders, the process specialists, the people who have been handling the exceptions for years and know exactly where the gaps are. It requires observing the processes in operation, not just reading about them. It requires asking not just how the process works but where it breaks and what people do when it does.
This work surfaces the reality of the legacy state. It is not always a comfortable picture. It almost always reveals more variation, more informality and more accumulated workaround than the official documentation suggests. But it is the only honest foundation for designing the future state because you cannot design where you are going if you do not understand where you actually are.
Key Takeaway:
Understanding the legacy requires looking beyond the official documentation to the actual operational reality. The gap between the two is where the most expensive migration problems hide and where the most valuable design work can be done.
"You cannot design the future state if you do not understand what you are actually replacing."
MarvinPro_|_March_2026
marvinpro.com
Envisioning the future means making specific decisions about how the organisation will operate after the migration decisions that are documented, agreed and specific enough to be built into a system configuration.
This is harder than it sounds. The instinct in most organisations is to configure the new system to match the current processes as closely as possible. This instinct is understandable it minimises the change management burden, it reduces the risk of disruption and it feels safer than redesigning processes under migration pressure. But it is almost always wrong.
Migrating the current processes into a new system without redesigning them is an opportunity missed. The migration is a forcing function, it requires the organisation to document its processes, resolve its variations and make decisions about how things should work. These are decisions the organisation should have made years ago but did not, because the existing system accommodated the ambiguity and there was no forcing function to resolve it.
The new system is that forcing function. It requires definition. It will not accommodate ambiguity the way the legacy system did. The organisation can use the migration to define its processes well deliberately, with time and with the right people involved or it can define them badly under pressure, inconsistently and with insufficient consideration of the downstream consequences.
Envisioning the future requires three specific decisions for every process being migrated. The first is what stays the same, the aspects of the current process that are well-designed, well-documented and should be carried forward into the new environment. The second is what changes, the aspects of the current process that need to be redesigned to meet the standard the new environment requires. The third is what is eliminated, the redundant steps, the duplicate processes and the workarounds that exist only because the legacy system required them and that have no place in the future state.
These decisions must be made explicitly. They must be documented. They must be agreed by the people who will operate the processes and the people who will configure the system. And they must be made before migration execution begins because the design phase is the only time in the migration when there is enough time to make them well.
Key Takeaway:
Envisioning the future means making explicit, documented decisions about what stays, what changes and what is eliminated before the system requires those decisions under pressure. The organisation that makes these decisions well in the design phase arrives at execution with a foundation it can build on.
"The future state is not a better version of the current state. It is a deliberate design built on an honest understanding of what the current state actually is."
MarvinPro_|_March_2026
marvinpro.com
Every organisation operating across multiple markets faces the same fundamental design question: what gets standardised across all markets and what stays local?
This is the most consequential decision in the design phase. It shapes the system configuration, the data model, the approval flows, the reporting structure and the governance model. It determines how complex the migration will be, how expensive the ongoing maintenance will be and how resilient the organisation will be to future changes in its operating environment.
Most organisations make this decision poorly, not because they lack the intelligence to make it well but because they make it implicitly rather than explicitly. They configure the system to match the current processes without making a conscious decision about which aspects of the current processes reflect genuine local requirements and which reflect historical accident. The result is a system that carries the complexity of the legacy environment forward with all its regional variations, all its local exceptions and all its accumulated inconsistencies into a new platform that was supposed to simplify operations.
The correct approach starts with a default position. Standardisation is the default. Every process, every object, every approval flow and every reporting structure should be standardised unless there is a specific, documented reason why it cannot be. The burden of proof is on local variation, not on standardisation.
The justification for local variation falls into three categories. Regulatory requirements where local law or regulation mandates a different approach that cannot be accommodated within the standard process. Operational necessity where the specific characteristics of the local market, the local customer base or the local supply chain genuinely require a different process design. Commercial requirement where a specific customer or supplier relationship demands handling that the standard process cannot provide.
Everything else should be standardised. Not because standardisation is inherently superior to local variation in some cases the local approach is better than the global standard and should replace it. But because every point of unresolved variation increases the cost of the system configuration, the complexity of the ongoing maintenance and the difficulty of every future migration.
Key Takeaway:
Standardisation is the default in migration design. Local variation must be justified, documented and minimised. Every undocumented variation that enters the new system is a complexity the organisation will pay for indefinitely.
"Standardise by default. Localise by exception. Document both."
MarvinPro_|_March_2026
marvinpro.com
In a large organisation preparing for a system migration across multiple European markets, the design phase revealed a problem that the organisation had not anticipated it did not have a single, consistent definition of its own customer categories.
Each market had developed its own customer classification system over years of independent operation. The classifications were used for pricing, for service level assignment, for reporting and for regulatory compliance. They were deeply embedded in the operational processes of each market. And they were completely inconsistent across markets, the same customer type was classified differently in different countries, and the same classification code meant different things in different markets.
This was not a data quality problem in the traditional sense. The classifications were accurate within each market. The problem was that they had never been standardised because the legacy system had never required them to be and the organisation had never had a reason to compare them.
The new system required a single, globally consistent customer classification framework. Every customer in every market had to be assigned a classification from the same framework before the system could apply pricing, service levels or reporting logic consistently.
The design phase became a customer classification project before it became a process design project. Representatives from every market were brought together to agree on a global classification framework that could accommodate the genuine differences between markets while eliminating the inconsistencies that had developed by accident. The work took three months.
Three months in the design phase. The alternative, discovering the inconsistency during data migration, with a go-live date fixed and no time to resolve it properly would have cost significantly more.
"Three months resolving a classification problem in the design phase cost a fraction of what discovering it during data migration would have."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome
The design phase is not a planning activity. It is the migration.
Every decision made in the design phase, about what the legacy state actually is, about what the future state should be, about what gets standardised and what stays local is a decision that will be made somewhere in the migration process. The only question is when and under what conditions.
Made in the design phase, with time and the right people, these decisions are made well. Made during execution, under pressure and on a deadline, they are made badly, quickly, inconsistently and with consequences that take months to resolve.
The organisation that invests in the design phase does not have an easier migration. It has a migration where the difficulty is known in advance, planned for and manageable. The organisation that compresses the design phase has a migration where the difficulty arrives as a surprise at the moment when surprises are most expensive.
Understand the legacy. Envision the future. Standardise by default. Document every decision. These are the outputs of the design phase. They are also the foundation of everything that follows.
"The design phase is where the migration is won or lost. Everything that follows is the consequence of the decisions made here."
MarvinPro_|_March_2026
marvinpro.com