Migrating master data into IBM Master Data Management

If your organization has an existing master data management deployment on IBM InfoSphere Master Data Management (InfoSphere MDM), you can migrate your existing master data and matching algorithm into the IBM Master Data Management service to take advantage of its modernized, cloud-native MDM capabilities and interconnectivity with other services.

You can also use the migration service to migrate matching algorithms from IBM InfoSphere Big Match for Hadoop to IBM Master Data Management. The migration process converts your existing Big Match metadata to IBM Master Data Management.

Restriction: The IBM Master Data Management migration service only supports migrating from IBM InfoSphere Master Data Management version 14.0 or IBM InfoSphere Big Match for Hadoop version 11.6.

Migrating your master data is a strategic modernization initiative, not just a technical lift-and-shift. To migrate your master data from InfoSphere MDM, you can use the IBM Master Data Management migration service, which includes easy-to-use APIs that simplify the migration process and ensure that your critical master data maintains its structure and integrity. The migration service uses your existing InfoSphere MDM Publisher deployment to move data from InfoSphere MDM to the IBM Master Data Management service.

The IBM Master Data Management migration process is designed to minimize system downtime and maximize ease of use.

The IBM Master Data Management migration service APIs provide programmatic control for repeatable, auditable migrations. When you migrate your master data by using the migration service APIs, you ensure that your data maintains its existing structure. Your existing master data entities, relationships, groups, and matching algorithm all remain intact and unchanged.

What happens during migration

After you initiate a migration by using the IBM Master Data Management API, the migration service and InfoSphere MDM Publisher perform the following operations:

Convert data models: The system analyzes your InfoSphere MDM schema and converts entity types, attributes, identifiers, and cross-reference segments to the IBM Master Data Management data model format.
Create the data model in IBM Master Data Management: The migration service registers the converted data model with IBM Master Data Management, ensuring all entity types, attributes, and relationships are defined.
Extract data: MDM Publisher extracts operational tables, extension tables, and reference data from your InfoSphere MDM database to temporary storage. MDM Publisher uses Apache Spark pods that are dynamically deployed, transforming the data into hierarchical structures stored in JSON files.
Generate record payloads: The system transforms extracted data into IBM Master Data Management record JSON format, including entity typing, attribute conversion, and standardized values.
Generate relationship payloads: The system creates relationship JSON payloads that define connections between entities (such as party-to-address, party-to-phone, and party-to-identifier relationships).
Transfer and load data: MDM Publisher moves the JSON payloads to the IBM Master Data Management landing zone and invokes the bulk load API to import the data.

Planning your migration in stages

The migration from InfoSphere MDM to IBM Master Data Management follows an "upgrade-like" methodology that prioritizes business continuity. Unlike traditional migration approaches that require extended downtime, this process enables parallel operation of both systems during the transition, allowing for thorough validation before the final cutover.

The migration process consists of four stages, each designed to reduce risk and ensure data integrity:

Stage 1: Initial migration (no production downtime)

The first stage establishes the foundation for migration without affecting production operations:

Single API trigger: Initiates migration of data models, algorithms, and operational data.
Data model migration: Workbench project analysis automatically transfers data model definitions.
Algorithm migration: Matching and linking algorithms are migrated via Workbench analysis.
Operational data migration: MDM Publisher (deployed on a separate OpenShift cluster) integrates with IBM Master Data Management migration service to transfer operational data.
Proxy service setup: Metadata generation to prepare the proxy layer depending on the InfoSphere MDM style (physical MDM or virtual MDM).

During this stage, InfoSphere MDM continues normal production operations while the target IBM Master Data Management environment is populated with migrated content.

Stage 2: Test migration mode (no production downtime)

The second stage validates the migration through simulataneous operation of the two systems:

Simultaneous operation: InfoSphere MDM and IBM Master Data Management operate simultaneously, but separately. You can complete testing on IBM Master Data Management without influencing production data on InfoSphere MDM.
Data validation: Comprehensive validation of migrated data and functionality.
Performance testing: Optimization and performance benchmarking.
Test traffic routing: Test traffic can be routed to IBM Master Data Management through the proxy service, but production data and incoming requests remain on InfoSphere MDM.

This stage allows you to complete thorough testing without impacting production data, so you can identify and resolve any issues before production cutover. InfoSphere MDM continues to function as the active production system, and IBM Master Data Management is used solely as a testing environment. There is no synchronization between the two systems. Data changes made in production are not automatically propagated to the newly migrated IBM Master Data Management system. All ongoing business operations continue to run exclusively on the InfoSphere MDM instance.

Stage 3: Switch stage (no production downtime)

The third stage transitions production traffic to IBM Master Data Management while maintaining InfoSphere MDM availability:

Read-only mode: InfoSphere MDM instances set to read-only (inquiry transactions remain operational).
Delta data load: Migration service loads incremental operational data changes.
Traffic redirection: Application traffic redirects to IBM Master Data Management proxy APIs.
Monitoring and stabilization: Both systems remain operational with production traffic flowing to IBM Master Data Management.
Rollback capability: InfoSphere MDM remains available for rollback if needed.

During this stage, users can still query InfoSphere MDM for historical data, but all data updates now flow to IBM Master Data Management.

Stage 4: InfoSphere MDM cutout (planned maintenance window)

The final stage completes the migration after IBM Master Data Management proves stable in production:

Final verification: Comprehensive validation of IBM Master Data Management stability and performance.
Decommissioning: InfoSphere MDM instances are decommissioned.
Permanent routing: All traffic permanently routes to IBM Master Data Management through the proxy service.
Final tuning: Configuration and performance optimization of IBM Master Data Management.

This stage requires a planned maintenance window, to be scheduled only after IBM Master Data Management demonstrates stable production operation.

Downtime considerations

The IBM Master Data Management migration strategy minimizes production impact through careful planning:

Most activities in parallel: Stages 1 and 2 occur without production downtime.
Read-only access maintained: During Stage 3, InfoSphere MDM remains available for inquiry transactions.
Single maintenance window: Stage 4 requires downtime only after IBM Master Data Management proves stable in production.
Rollback capability: InfoSphere MDM remains available during Stage 3 for emergency rollback.