Chapter 2
Design Phase, Building for Scale
Migration success is determined before migration begins. Not in the execution. Not in the cutover. Not in the hypercare period after go-live.
In the design.
The design phase is where the future-state operating model is defined. It is where the organisation decides what will be standardised across all markets, what will remain local, and what will be eliminated entirely. Every decision made well in this phase saves significant time and cost during execution. Every decision deferred to execution creates pressure, rework and risk.
In an S/4HANA context the design phase has a specific scope. Country structures, company codes, general ledger accounts, cost centres, profit centres, business partners, purchase requisitions, purchase orders, service and order objects, all of these must be defined before a single transaction is migrated. The system cannot be configured around undefined processes. The data cannot be mapped to objects that do not yet exist.
The design phase is not a planning activity. It is the foundation on which the entire migration is built.
Key Takeaway:
The quality of the design phase determines the quality of the migration. Organisations that invest in design before execution arrive at cutover with a stable foundation. Organisations that skip or compress the design phase pay for it during execution at a significantly higher cost.
"Migration succeeds in the blueprint, not in the execution."
MarvinPro_|_March_2026
marvinpro.com
The design phase has a specific deliverable, a complete definition of the future-state operating model. This is not a high-level architecture document. It is a detailed, decision-level specification of how the organisation will operate in the new system.
In S/4HANA terms this means defining the core objects the system will use to represent the business:
Country structures, how the organisation is represented in the system. Company codes, controlling areas, plant structures. These are the foundation on which every financial transaction is recorded.
Master data, the objects the system uses to execute processes. Business partners covering customers and suppliers. Materials and products. Cost centres and profit centres. These must be cleansed, standardised and validated before migration begins.
Process flows, the end-to-end workflows the system will execute. Order-to-Cash covering the full customer lifecycle from order creation to billing. Procure-to-Pay covering supplier interactions from purchase requisition to invoice payment. These must be defined at the transaction level — not just described at a high level.
Integration points where S/4HANA connects to other systems. Every integration must be mapped, tested and validated during the design phase. Integrations discovered after go-live are among the most expensive problems a migration can produce.
Key Takeaway:
The design phase produces a complete definition of the future-state operating model, master data, process flows, organisational structures and integration points. Anything undefined at the end of the design phase will become an exception during execution.
"What is not defined in design becomes an exception in execution."
MarvinPro_|_March_2026
marvinpro.com
Every organisation operating across multiple markets faces the same fundamental design question: what gets standardised and what stays local?
This is the most consequential decision in the design phase. And it is the decision most organisations make poorly either standardising too aggressively and creating processes that do not work in specific markets, or localising too broadly and carrying the complexity of regional variation into the new system.
The correct approach starts with a default position. Standardisation is the default. Every process, every object, every approval flow should be standardised unless there is a specific, documented reason why it cannot be. Local variation should be justified not assumed.
The justification for local variation falls into three categories. Regulatory requirements where local law mandates a different process. Operational necessity where the market structure genuinely requires a different approach. Commercial requirement where the customer or supplier relationship demands specific handling.
Everything else should be standardised. Not because standardisation is inherently better than local variation but because every point of local variation increases the complexity of the system configuration, the cost of ongoing maintenance and the risk of future migrations.
The organisation that arrives at S/4HANA with fifty regional process variations will find the migration significantly more complex than the organisation that arrives with five formally approved exceptions and a standardised baseline for everything else.
Key Takeaway:
Standardisation is the default. Local variation should be justified, documented and minimised. Every undocumented regional variation in the design phase becomes a configuration exception in the system and a maintenance cost forever.
"Every local variation that enters the system without justification is a complexity that the organisation will pay for indefinitely."
MarvinPro_|_March_2026
marvinpro.com
The design phase includes a decision that shapes every subsequent phase of the migration the choice of migration approach.
Three approaches are available in an S/4HANA context.
Greenfield is a full redesign. The organisation builds the new system from scratch, using the migration as an opportunity to standardise processes, eliminate legacy complexity and implement best practice from the ground up. Greenfield is the highest effort and highest reward approach. It produces the cleanest outcome but requires the most design work and the highest organisational change management investment.
Brownfield is a system conversion. The existing system is converted to S/4HANA with the existing processes, configurations and data structures carried forward. Brownfield is faster to execute and lower risk in the short term but it carries legacy complexity into the new system. The organisation gets S/4HANA without the transformation.
Selective or hybrid combines elements of both. Some processes are redesigned. Others are converted. This approach is the most common in large, complex organisations where a full greenfield is not feasible but a pure brownfield would not deliver sufficient value.
The choice between these approaches is not a technical decision. It is a strategic one. It must reflect the organisation's process maturity, its change management capacity, its timeline and its long-term operating model ambitions.
Key Takeaway:
The migration approach must match the organisation's process maturity and strategic ambition not just its timeline. A greenfield chosen without the process design work to support it will fail. A brownfield chosen to avoid the design work will carry legacy complexity forward indefinitely.
"The migration approach chosen for speed rather than maturity carries the cost of that choice forward indefinitely."
MarvinPro_|_March_2026
marvinpro.com
In a large organisation operating across multiple European markets, the design phase revealed a problem that no one had anticipated the organisation did not have a single, consistent definition of its own business partners.
Customers in one market were structured differently from customers in another. Supplier records had been created independently in each country, resulting in the same supplier appearing multiple times in the system under different names and reference numbers. The master data that was supposed to be the foundation of the new system was inconsistent, duplicated and in many cases incomplete.
This was not a data quality problem in the traditional sense. The data was accurate within each market. The problem was that it had never been standardised across markets because the legacy system had never required it to be.
S/4HANA required it.
The business partner object in S/4HANA consolidates customer and supplier data into a single structure. Every customer, every supplier, every internal business partner must be defined in a consistent format before the system can process a single transaction involving them.
The design phase became a master data project before it became a process design project. Every business partner record across all markets was reviewed, deduplicated and standardised. The work took longer than anticipated. It delayed the migration timeline.
But it was work that had to be done. The organisation that discovers its master data is inconsistent during cutover does not have time to fix it properly. The organisation that discovers it during design has the time to make good decisions.
The delay in the design phase saved significantly more time than it cost.
"The organisation that designs its processes before migration arrives at the system ready. The organisation that waits designs under pressure and pays for it twice."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome:
The design phase is not a formality. It is the migration.
Every hour invested in defining the future-state operating model, standardising master data, documenting process flows and choosing the migration approach deliberately saves multiple hours during execution.
The organisations that struggle with S/4HANA migrations almost always struggle for the same reason. Not technology failure. Not vendor performance. Not project management methodology.
Insufficient design.
Define everything before execution begins. Standardise by default. Justify every exception. Choose the migration approach that matches the organisation's maturity, not the one that fits the timeline.
The execution will still be challenging. But a well-designed migration is a manageable challenge. A poorly designed one is an indefinite crisis.
"A poorly designed migration is not a technical failure. It is the consequence of decisions that were deferred until the cost of making them well had passed."
MarvinPro_|_March_2026
marvinpro.com