Partnership that powers possibilities Let’s Build Together

LogoTechstern
Get A Quote

SQL Server Database Migration for SCOM Using Import & Export Wizard

Migration Process Overview

  • Launched the SQL Server Import and Export Wizard.
  • Selected essential SCOM tables and views (from dbo and SCOM-specific views).
  • Validated data type mappings between source and destination.
  • Initiated the migration, tracked row transfers, and reviewed logs for errors or warnings.

Project description

SQL Server Database Migration for SCOM Using Import & Export Wizard

We migrated a critical SCOM SQL Server backend to a new SQL environment using the Import & Export Wizard. The objective was to maintain data accuracy, performance, and monitoring continuity. Despite partial view transfer issues, essential tables like EntityDimvw and GroupDimvw migrated successfully. Schema scripting and health checks were recommended to fix broken views and ensure console-level visibility.

Objective

To securely and accurately migrate multiple SCOM-related tables from the source SQL Server to a new instance using the SQL Server Import and Export Wizard, preserving monitoring functionality and historical data integrity.

Modules

Key Observations from the Migration

01

Data Type Mapping Warning

  • Table: Domain Table Index Optimization History (possibly extended or custom monitoring metadata) • Warning: Data type mismatch—example: nvarchar (source) → LongText (destination)
  • Risk: Truncation or precision loss, affecting dashboards or reports if not aligned

02

Successful Row Transfers

Successful data movement for:

  • Domain Table Statistics Update History → 4439 rows
  • Domain Table Index Optimization History → 548 row

03

Indicates good initial mapping for SCOM tracking tables Critical Error & Partial Loads

  • Total Tables: 91
  • Success: 24
  • Failures: 1 critical error (Display String Dimvw)
  • Stopped Tables: ~13 (mostly Incident*vw views)

04

Critical Issue

  • Display String Dimvw failed with "Messages..." (unreadable from image)
  • This view is essential for UI translation and alert labels in SCOM Partially Transferred (Success)
  • Entity Dimvw: 53,558 rows
  • Group Contains ConfigItem Fact vw: 5,901 rows • Group Dimvw: 21 rows

Techstern

Working experience

Risk: Failure in DisplayStringDimvw may cause missing strings or object labels in the SCOM console UI.

  • Display String Dimvw: Stores localized display strings used in the SCOM UI and alert messages.
  • Entity Dimvw: Serves as a core mapping table for monitored objects and their associated metadata.
  • Group Dimvw: Defines logical groupings of components, typically used in distributed applications.
  • Incident*vw Views Used for alert generation, incident tracking, and integration with ticketing systems.
  • Domain Table Statistics Update History: Logs update and maintenance statistics related to monitored entities.

  • View-Based Migration: Many SCOM components are views, not base tables—these often fail to transfer without generating schema scripts.
  • VData Integrity: Missing rows in Incident*vw views can result in lost alerts or incomplete incident tracking.
  • VDependency Order: Certain tables rely on hierarchical relationships (e.g., EntityDim → MonitorStateDim) and must be migrated in proper sequence.
  • Monitoring Breakage: Incomplete data migration may lead to broken alerts or false-negative monitoring in SCOM.

  • Use Generate Scripts Instead: Use SSMS → Tasks → Generate Scripts to export schema and data more reliably than the wizard.
  • Run Health Checks Post-Migration: Validate view and object integrity using the SCOM SDK or Get-SCOMClassInstance.
  • Fix Permissions & View Filters: Ensure destination SQL users have required permissions to access all dependencies in the views.
  • Script Missing Views Manually: Manually recreate essential views like DisplayStringDimvw with accurate joins if automated migration fails.
  • Log-Based Troubleshooting: Use SQL logs to identify root causes of migration failures—such as foreign key errors or data type mismatches.

Despite one critical error and a few view-related failures, the core monitoring data (entities, groups, and update stats) were successfully migrated. Immediate impact was minimal as core data like EntityDimvw transferred over 50,000 rows. However, errors in key UI-related views (e.g., DisplayStringDimvw) could cause inconsistencies in the SCOM Console interface.

Conclusion This migration underscores the importance of:

  • Understanding how SCOM stores and queries data
  • Planning for views and not just tables
  • Ensuring data type precision and integrity
  • Running post-migration health checks in SCOM By refining the migration strategy with schema scripting and targeted validation, the IT team can ensure seamless SCOM operations with full historical visibility and alert accuracy.