Best Practice: Establishing Content Migration Policies

Effective change management policies are critical for ensuring smooth transitions between testing and product environments, minimizing disruptions, and maintaining the integrity of your data and systems. This article describes best content migration practices tailored to Metric Insights environments, as well as environment governance models and migration dependencies.

1. Dealing with Proof of Concept (POC) Environment

Firstly, you have to decide how to deal with the Proof of Concept environment. Determine if the POC environment will transition to a development or production environment or be scrapped to start fresh.

Factors to consider:

  • Assess the relevance and quality of content created during the POC phase. Define if the content created in this phase is actually useful for the Users
  • Evaluate the alignment of the POC setup with long-term governance policies. Check if the access permissions, structure of content, and metadata are correct
  • Ensure Data Source configurations and naming conventions comply with organizational standards of transitioning the POC environment. Check to what production tool or database the POC environment is connected

2. General Content Migration Recommendations

Here are some overall recommendations that will lessen the probability of losing important content or experiencing troubles during content migration:

  • Utilize backup-and-restore processes initially for whole-environment migration
  • Adopt a robust backup strategy to secure original configurations and data integrity
  • Avoid piecemeal migrations at early stages unless explicitly required by project constraints (for example, there could be policies that prohibit storage of data, or elevated User account permissions in higher environments)

3. Multiple Environments Governance Models

Establishing robust change management policies is essential for maintaining system integrity and supporting business objectives. By leveraging these best practices, organizations can achieve a balance between agility and control, ensuring effective governance across Metric Insights environments.

Every governance model has five key features:

  1. Speed of Implementation: How quickly changes can be implemented
  2. Governance Complexity: How complicated the governance structure is
  3. Testing Rigor: How thoroughly changes are tested before going live
  4. Control/Compliance: The level of oversight and compliance enforcement
  5. Flexibility: Ability to adapt or make changes directly in production

There are three available governance models: Simple, Standard and Restrictive.

3.1. Simple Governance Model

This governance model represents streamlined changes with minimal intervention while maintaining oversight. Main features of it are:

  • Lower environments are used for testing and outlining use cases (for example, testing new versions of Metric Insights or building custom Portal Pages), but content promotion is optional
  • Changes are often made directly in production for efficiency
  • Production environments can be promoted downward to lower environments for upgrade testing using backup/restore
  • Audits are reviewed in production to monitor user activities. Custom audit reports can be made using Metric Insights internal database

Advantages:

  • Fast implementation of changes
  • Simplified governance reduces overhead

Risks:

  • Potential for unvetted changes impacting production stability

3.2. Standard Governance Model

This governance model promotes balance between thorough testing and streamlined operations. It's main features are:

  • Testing and new use cases are developed in lower environments
  • Selective content (Elements, Datasets, Categories, Folders, Portal Pages) is promoted to production
  • Lower and higher environments should connect to the same data sources with identical names
  • Export/import mechanisms (e.g., local files or Git repositories) are used for migrating use cases
  • Low-risk changes like adding Elements to Folders or changing a Notification Schedule are typically done in production. They can be reversed quickly if needed. Changes to custom code (e.g., Portal Pages, Email Templates), and security model access are done in non-production
  • Lower environments are upgraded and tested against production versions prior to upgrading production

Advantages:

  • Ensures vetted use cases before production implementation
  • Allows for flexible ongoing maintenance in production

Risks:

  • Moderate governance complexity may slow changes

3.3. Restrictive Governance Model

This governance model ensures maximum control and compliance in regulated environments. Main features of this model are:

  • Use cases are developed in a sandbox or development environment
  • Thorough testing is performed in a UAT environment that mirrors production
  • Only non-exportable changes are made directly in UAT
  • Approved use cases are promoted to production
  • No changes are made directly in production
  • Upgrades are sequentially tested from lower environments to production
  • One lower environment must mirror production but allow controlled changes

Advantages:

  • Rigorous testing minimizes production risks
  • High compliance for regulated industries

Risks:

  • Potential delays in implementation due to stringent processes

4. Migration Dependencies

Every Object in the Metric Insights has a set of connections to other objects within the system. When it is migrated, it is migrated with all those connections. Those connections can be described through two types of objects:

  • Foreign Entities: Objects referenced by the migrated object
  • Reference Entities: Objects referencing the migrated object

During migration, ensure connected objects are properly handled:

  • Choose appropriate migration options (Folder relationships, Portal Page variables, Custom Fields)
  • Maintain naming consistency for Datasets, Categories, Folders, and Dimensions across environments

NOTE: Ensure the destination environment can accommodate the object structure and dependencies without breaking functionality.

4.1. Migration Restriction: Dimensions

The migration of the Dimension is complicated and has to be done with caution. If the Dimension is a foreign or reference object, its migration is restricted to prevent problems. To avoid complications, make sure to maintain consistency through environments for the following Dimension features:

  • The Dimension Key Value type (e.g., “text” / “integer”)
  • The Dimension type (e.g., Compound / Simple)
  • The Parent, Primary, and Secondary Dimension
  • The Include "Total" Dimension Value feature status

4.2. Data Source Consistency

All environments (development, UAT, production) should ideally point to the same source image/data platform. It is not necessary to point lower environments of Metric Insights to lower environments of Tableau, Power BI, etc.

Key recommendations:

  • Ensure Data Sources across environments (e.g., Tableau, Power BI) share consistent naming conventions for seamless migration. If prod and non-prod environments both point to the exact same tool (e.g. Tableau), they need to have the same Data Source name (e.g. "Tableau - Production")
  • Periodically audit Data Source configurations to ensure alignment