Strategy ONE

Object Migration Best Practices in MCS

Migration Process

There are three package types:

  • Object: Copy the selected objects with or without their dependencies between projects.
  • Project: Synchronize a large number of objects between projects.
  • Administration: Copy select administration objects with or without their dependencies between environments.

At a high level, the migration process includes:

  • Configure the Storage Service to establish a package storage location.
  • Connect Workstation to the on-premises environment.
  • Create a migration package by adding objects & dependencies, then configuring package settings.
  • Export the package.
  • Connect Workstation to the MCS environment.
  • Import the package to the package storage location, then perform the object migration.
  • Test functionality, validate data accuracy, and resolve any identified issues.

For more information on migrations, see Manage Migrations.

Migrate From On-Premises to MCS Best Practices

Use the following best practices when migrating from on-premises to MCS:

Staged Migration Approach

  • Migrate in logical phases rather than all at once.
  • Start by migrating Administration objects to help establish security roles, groups, etc. in the new MCS environment.
  • To migrate an existing project from on-premises to MCS, best practice is to use a Project migration package.
  • To migrate objects, such as dashboards, Strategy recommends that you create multiple smaller packages instead of one large package. Smaller batches are easier to test.

Package Management

  • Name packages clearly, including the date, content type, and version.
  • Document each package's contents in a migration log.
  • Ensure that object actions are properly defined (replace, use existing, etc.)

Project Merge

  • Before migrating a Project package from on-premises to MCS, create a blank "dummy" project in the target (MCS) environment.
  • Merge the project package into the target environment, ensuring the configured ACL options are set to use the objects from the source environment.
  • If any objects in the target environment shares the same name as any objects in the source environment, Strategy recommends that you use the Replace option under Advanced Conflict Resolution to successfully overwrite the object during the project migration.

Version Compatibility

  • Ensure both environments are on the same or compatible version. Issues may occur when migrating between environments on different versions.
  • Migrations are supported in MicroStrategy 2021 Update 7 and later. Strategy recommends that you upgrade the on-premises environment to the latest release before migrating to MCS.
  • Apply any necessary patches or updates to the on-premises environment before migrating.
  • Test the migration with a small sample before full migration.

Testing & Reversing Migrations

  • Best practice is to test after migrating each package.
  • Each package can be reversed through Workstation if the migration results in an unsatisfactory result.
  • If the outcome of a migration is unsatisfactory, Strategy recommends that you reverse the migration before you proceed with additional migrations.

Storage Service

  • To use Workstation migrations, configure the Storage Service for the on-premises and MCS environments.
  • When you install Strategy One in an on-premises environment, select the Strategy Storage Service during the installation process.
  • The Strategy Storage Service supports AWS S3, Azure Blob, Google Cloud Storage, or Share Folder. Strategy recommends that you configure a storage location that both environments can access.

Security Considerations

  • Review security roles and access permissions before and after migration.
  • Create specific migration user accounts with the appropriate privileges.

Performance Optimization

  • Schedule migrations during off-peak hours.
  • Break large migrations into smaller batches.
  • Close unnecessary applications during migration.
  • Consider leveraging Python in Workstation to support migrations, including scheduling migration operations during off-peak hours.

Content Evaluation

  • A one-to-one migration to MCS is not recommended for any outdated or unused analytics content in the on-premises environment. Organizations should take the opportunity to consolidate and modernize analytics objects before migrating them to MCS. If the organization is running an older version of Strategy, assess the current analytics footprint and reimagine the most frequently used content for MCS.
  • Adopt new capabilities: Leverage out-of-the-box capabilities in MCS such as Mosaic Studio and Auto Dashboard in Library to build new AI-powered data models and dashboards.

Customization Support

  • MCS does not support customizations. Therefore, customizations may fail if you include them in the migration.
  • For incompatible custom visualizations, identify Library-native alternatives. For a smoother transition, eliminate customizations in the on-premises environment before migrating objects.

API Workflows

  • MCS only supports modern RestAPI SDK. Existing API workflows may need to be reworked to leverage the supported APIs.

Connection Configuration

  • Document all data source connections used in the on-premises environment, including connection strings, authentication methods, and drivers. Ensure the the required database drivers are available and compatible with MCS.
  • Coordinate with your IT team to install the Data Gateway Agent in order to access data residing on-premises behind the firewall.
  • When you migrate data sources from on-premises to MCS, update connection information in the MCS environment accordingly.