Guide section 25 of 31
Migration Pattern: Existing Report → New Power BI Page
The migration work established that redesign should not start by tracing the old screen one-to-one. Work with business stakeholders to decide what from the legacy report remains valuable.
| Decision | Meaning |
|---|---|
| Keep | Still answers a real user/business question and can be implemented appropriately. |
| Improve | The need remains but hierarchy, visual, wording or interaction should change. |
| Combine | Related legacy content can be consolidated into one clearer pattern/page. |
| Remove | No longer supports a decision or is duplicated/unused. |
| Replace | The need remains but a different Power BI-native mechanism answers it better. |
| New requirement | A validated need not represented in the legacy report. |
Recommended migration sequence
- Observe how the legacy report is actually used, not only how it is structured.
- Identify the business question and decision for each existing section/page.
- Classify each element Keep / Improve / Combine / Remove / Replace / New.
- Check whether the required data and measures exist in the new model.
- Select the new page archetype/template from the task, not from legacy layout.
- Map to native Power BI visuals/interactions.
- Validate with business and development before build.
- Only then document exceptions or custom requirements.
Project-specific example generalized from the migration Operational/store reports often benefit from an overview that surfaces KPI status and exceptions, followed by analysis/root-cause pages and then exact-record detail. This is a reusable analytical journey, not a requirement to preserve the legacy page count.