Metric Definitions
Part of BI system performance and cost control
Planning a BI platform migration with reproducible metrics
Plan a BI migration using versioned metric definitions, fixed reference data and explicit checks for accuracy, access, freshness and performance.
Plan a BI migration around figures reproducible in the current and proposed environments. An inventory shows what might move; versioned metric definitions and fixed reference data show whether the result keeps its meaning. Move one bounded reporting slice first, then assess accuracy, access, freshness, function, performance and operating cost.
Choose a reporting slice
Choose a maintained report with a decision owner, known consumers and an available source. Inventory its dataset, calculations, filters, scheduled deliveries, exports and downstream uses. Have owners confirm any output proposed for retirement. Record the current report and model versions.
A published migration guidance series sets out stages that include preparing to migrate, gathering requirements, planning deployment, conducting a proof of concept, creating and validating content, and deploying. In that series, the stage that creates content produces a solution validated in a development workspace before it is deployed to production. Those planning questions can inform another migration, but the destination's implementation still needs its own assessment.
Stages in the published migration guidance series
- Preparing to migrate
- Gathering requirements
- Planning deployment
- Conducting a proof of concept
- Creating and validating contentProduces a solution validated in a development workspace before it is deployed to production.
- Deploying
Preserve the metric and reference case
For each consequential measure, record its unit, population, exclusions, grain, calculation, date role, timezone, source cutoff, currency where relevant and owner. Preserve a source extract or reproducible snapshot for a closed period. Keep the current calculation, report filters, expected totals, breakdowns and record IDs that expose boundary cases.
A headline total can match despite offsetting errors. Include cases involving a changed status, date boundary or restricted user when those conditions affect the report.
| Acceptance area | Evidence to prepare | Reason to hold release |
|---|---|---|
| Meaning | Versioned definition and fixed-period results | Unexplained population or calculation difference |
| Data | Source snapshot, cutoff and correction rule | Incomplete or untraceable period |
| Access | Intended roles and permitted detail | Records exposed outside the approved audience |
| Function | Required filters, exports and scheduled outputs | A decision task cannot be completed |
| Performance and cost | Comparable action, workload and account-specific usage | Requirement missed or material cost still unknown |
Release acceptance areas and evidence to prepare
- MeaningVersioned definition and fixed-period results; hold release if population or calculation difference is unexplained.
- DataSource snapshot, cutoff and correction rule; hold release if the period is incomplete or untraceable.
- AccessIntended roles and permitted detail; hold release if records are exposed outside the approved audience.
- FunctionRequired filters, exports and scheduled outputs; hold release if a decision task cannot be completed.
- Performance and costComparable action, workload and account-specific usage; hold release if a requirement is missed or material cost remains unknown.
Explain differences
Build the slice in the proposed platform using its appropriate model and permission design. Run the same fixed-period questions with aligned filters and cutoffs. Classify each difference as an approved definition change, a defect, a source-timing difference or unresolved.
An error in the old report need not be copied into the new one. Approve the corrected rule and record which historical periods change.
Check ordinary user accounts as well as administrators. Compare what each can view, filter, export and receive on a schedule. Assess response time with representative data volume and concurrent work. A small demonstration cannot establish production performance or cost.
Classify and resolve output differences
- Build the sliceUse the proposed platform's appropriate model and permission design.
- Run fixed-period questionsAlign filters and cutoffs with the current report.
- Classify the differenceApproved definition change, defect, source-timing difference or unresolved.
- Approve correctionsRecord the corrected rule and the historical periods it changes.
Set cutover and recovery rules
Agree who accepts each metric, when the old output stops being authoritative and which version readers should use during transition. Where feasible, compare both outputs over an agreed period with visible data cutoffs. Keep discrepancies, decisions and owners in one record. Define how to return to the earlier route if a release condition fails.
Retain the metric definitions, source snapshot, reference results, configuration and decision record after cutover. Repeat affected checks when a calculation, source, permission or delivery route changes.
Cutover and recovery checks
- Metric acceptanceAgree who accepts each metric.
- Authoritative outputSet when the old output stops being authoritative and which version readers use during transition.
- Parallel comparisonWhere feasible, compare both outputs over an agreed period with visible data cutoffs.
- Decision recordKeep discrepancies, decisions and owners in one record.
- Return routeDefine how to return to the earlier route if a release condition fails.
- RetentionRetain metric definitions, source snapshot, reference results, configuration and decision record after cutover.
- Repeat checksRepeat affected checks when a calculation, source, permission or delivery route changes.
