SAP MDG Deployment Options and Storage Types

SAP MDG Storage Types with respect to Deployment Options Explained

SAP MDG Deployment Options and Storage Types SAP MDG

Scenario 1 : SAP MDG Hub Deployment and Storage Modes

When planning an SAP Master Data Governance (MDG) implementation, the Hub Deployment model is often the strategic choice for complex landscapes. This setup involves a standalone SAP S/4HANA instance dedicated solely to master data management, acting as the “single source of truth” for all connected systems.

Here are the primary scenarios where a Hub Deployment becomes essential:

Legacy or Non-SAP Ecosystems

If your core transactional system is an older version of SAP ECC that cannot support the latest MDG features, or if you are using a Non-SAP ERP, a Hub deployment is the way forward. By setting up a new S/4HANA instance for MDG, you bypass the technical limitations of your legacy environment while still governing the data that feeds into it.

Heterogeneous Landscapes

For organizations operating across multiple regions or managing a high volume of connected systems, a central Hub acts as the traffic controller. It ensures that master data remains consistent across various business units, regardless of their local ERP versions or geographical locations.

Mastering the Hub Transition: Data Layers and Migration Tactics

When transitioning to an SAP MDG Hub environment on SAP S/4HANA, you aren’t just performing a technical install—you are orchestrating a strategic migration of your entire data ecosystem. To ensure the Hub governs effectively, we must replicate the existing ECC data hierarchy using specific tools and team expertise.

The Data Lifecycle: Build, Structure, and Execute

Think of your system as a building. You cannot have residents (Master Data) or activity (Transactions) without a solid foundation and frame. Here is how the responsibilities break down:

System Data (The Foundation): Managed by the BASIS Team. This includes the technical configurations, landscape settings, and RFC connectivity. In a Hub deployment, this layer is manually reconfigured to ensure the new S/4HANA instance communicates perfectly with the legacy systems.

Organizational Data (The Structure): Managed by Functional Teams. These are your Company Codes, Plants, and Sales Organizations. To keep the Hub in sync with your transactional systems, this data is typically moved via Transport Requests (TRs) or by activating BC Sets (Business Configuration Sets).

Master Data (The Residents): Managed by the MDM Team. Once the structure is ready, core entities like Customers, Vendors, and Materials are moved. For the initial setup, this is often handled as an Initial Load, frequently executed by the BODS (BusinessObjects Data Services) Team to ensure data cleansing and integrity.

Transactional Data (The Activity): Generated by End Users. These are the daily Sales Orders and Purchase Orders. While these stay in your ECC or S/4HANA transactional systems, they rely 100% on the “Golden Records” governed within the MDG Hub.

Migration Strategy: How We Move the Data

SAP MDG Deployment Options and Storage Types SAP MD

In a Hub scenario, the migration is a “surgical” process. We don’t move everything; we move what is necessary to make the Hub the central authority.

SAP MDG Deployment Options and Storage Types SAP MDG Deployment Options and Storage Types

While the Hub Deployment acts like a dedicated control tower, the Co-deployment model is more like a high-speed engine integrated directly into the chassis of your main ERP. In this setup, SAP MDG sits on the same instance as your SAP S/4HANA transactional system.

Here is the strategic breakdown for choosing a Co-deployment model and the logic behind its execution.

When implementing SAP Master Data Governance (MDG), one of the most critical architectural decisions is choosing between Hub vs. Co-deployment and Flex vs. Reuse storage modes. These choices dictate how data is staged, where it lives after approval, and how it reaches your transactional systems.

Hub Deployment: Flex Storage Mode (Financials Focus)

In this scenario, MDG acts as a standalone system. For Financial objects (like Profit Centers), we typically use Flex Storage.

The Process: When a requester creates a Profit Center (e.g., PFCT1), the data resides in the MDG Staging Area (Inactive).

Approval Flow: The data undergoes validation and final approval within the staging area.

Activation: Upon final approval, the Access Class moves data from the Inactive area to the Active area within the MDG Hub itself.

Distribution: Since the Hub is not the transactional system, the data must be replicated to target systems (like ECC) via the Data Replication Framework (DRF) using IDocs or SOA services.

SAP MDG Deployment Options and Storage Types SAP MDG

Key Characteristic: The “Source of Truth” for search and maintenance is the MDG Active Area. Existing data in ECC must be Initial Loaded into MDG via file uploads to be visible for change requests.

SAP MDG Deployment Options and Storage Types SAP MDG

Hub Deployment: Reuse Storage Mode (BP & Material Focus)

For domains like Business Partner (KNA1) or Material (MARA), MDG often utilizes the Reuse Storage mode.

SAP MDG Deployment Options and Storage Types SAP MD

The Process: During the Change Request process, data stays in the MDG Staging Area.

Activation: Once approved, the Access Class doesn’t move data to a separate “MDG Active table.” Instead, it writes directly to the standard SAP ERP tables (e.g., KNA1, MARA) within the S/4HANA Hub.

SAP MDG Deployment Options and Storage Types SAP MDG

Distribution: To use this data in downstream ECC systems, DRF replication is triggered from the Hub to the target environment.

Key Characteristic: Active data does not live in “MDG-specific” tables; it reuses the existing S/4HANA structures. For legacy ECC data, an initial load (often via SAP BODS) is required so the Hub can “see” and manage those records.

Scenario 2 : SAP MDG Co-Deployment and Storage Modes

SAP MDG Deployment Options and Storage Types SAP MDG

Co-deployment is the preferred strategy for organizations looking for a “lean” architecture where the master data management layer and the business processes live in the same house.

Minimal Architectural Complexity

For companies running a single, global SAP S/4HANA instance, adding a separate Hub can be overkill. Co-deployment eliminates the need for a standalone server, reducing hardware costs, maintenance efforts, and the complexity of managing additional system interfaces.

Immediate Consumption of Data

In a Co-deployment, there is no “latency” between the Hub and the Target. Once a record (like a new Supplier or Material) is approved in MDG, it is immediately available for transactional use (Sales Orders, POs) in the same system. You skip the “Data Replication” step that is mandatory in Hub environments.

Reuse of Existing Configuration

Because MDG and S/4HANA share the same database, MDG can natively see your Company Codes, Plants, and Cost Centers. You don’t have to “re-create” or “re-transport” the organizational structure from a transactional system to a Hub—the MDG layer simply sits on top of the data that’s already there.

Mastering the Co-deployment Transition: Integration Tactics

Transitioning to a Co-deployment isn’t about moving data to a new system; it’s about activating governance on top of your existing data.

The Data Lifecycle: Activation and Governance

In this model, the “building” is already standing. Your goal is to install “security cameras and checkpoints” (MDG) to manage how people enter and move within it.

System Data (The Foundation): Managed by the BASIS Team. Since the system is already live, the focus shifts from “connectivity” to “activation.” This involves turning on the MDG business functions and ensuring the underlying SAP HANA database has the capacity for the governance workflows.

Organizational Data (The Ready-Made Frame): Managed by Functional Teams. In Co-deployment, this is a major win. Your Company Codes, Purchase Organizations, and Plants are already configured for your daily business. MDG simply uses these existing values in its dropdowns and validation rules—no migration required.

Master Data (The Existing Residents): The MDM team manages these records. Instead of an “Initial Load” between systems, you perform Data Governance Activation. You pull existing “Active” records into the MDG staging area only when they require changes or mass enrichment.

SAP MDG Deployment Options and Storage Types

Transactional Data (The Seamless Activity): End users manage this data through a transition that remains largely invisible to them. While they continue creating Sales Orders and Purchase Orders, “change requests” now govern the data, ensuring every new entry meets corporate standards before it hits the table.

Co-Deployment: Flex Storage Mode

Co-deployment means you install MDG directly on top of your existing S/4HANA production system. When you use Flex mode in this setup (typically for Finance):

Data Lifecycle: Similar to the Hub-Flex model, the system creates the Profit Center in the Inactive Staging area.

Activation: After approval, data moves to the MDG Active area via the Access Class.

Usage Gap: Even though MDG is on the same box, because it is in Flex Mode, the “Active MDG” data is separate from the “Transactional” data. You still need to replicate the data (DRF) to ensure it is available for business transactions in the local system or other connected ECCs.

Search: The system searches against the MDG Active tables.

Co-Deployment: Reuse Storage Mode

This approach offers the most integration for Business Partners and Materials.

The Process: MDG stages data during the approval process.

Instant Availability: Upon final approval, the Access Class writes the data directly into the local S/4HANA application tables.

No Replication Required: Because you write data directly to the underlying system tables, it is immediately available for business transactions. The local system does not require DRF.

The Advantage: There is no need for an Initial Load for local data. Since MDG sits on top of the S/4HANA tables, it can “see” all existing customers and materials instantly.

Author’s Note: Ultimately, choosing the right combination depends on your landscape strategy. For instance, if you want a centralized “clean” room, you should go for the Hub. On the other hand, if you want to leverage your existing S/4HANA investment with minimal replication lag, Co-deployment is your best friend.

The MDG Lab – Mastering Data, One Table at a Time.

SAP MDG Deployment Options and Storage Types

Click here to read our Previous post : SAP MDG Deployment Options

SAP MDG Deployment Options and Storage Types