Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
Sign up nowGet Fabric certified for FREE! Don't miss your chance! Learn more
as per my understanding , there are two approaches for bi reports migration from one tool to another tool - one is lift and shift and other is refactoring , what is the difference between these two approaches, also do we perform report rationalization in case of lift and shift? in which case the efforts or time would be less?
Solved! Go to Solution.
Hi @powerbiexpert22 ,
In a nutshell:
Lift-and-Shift (L&S) is just replicating everything as-is on a new platform, including poor business logic, ineffective visuals etc.
Refactoring is rebuilding (sort of) from scratch on the new platform, correcting poor business logic, improving visual effectiveness etc. but also making use of any new/improved functionality that the new tool/platform can provide.
Re: Report rationalisation - yes, you can (and should) do this as part of L&S. You would not L&S any reports that are currently unused or are marked for deprecation, but these decisions would only be made within the scope of reducing the number of items to migrate in totality, not drifting into part-item rationalisation (e.g. slimming down a model then migrating it afterwards) as this then gets into Refactoring.
Re: Time/effort between the two - this is a grey area. I think it would largely depend on how good (or bad) a state your current tool/platform is in. If the current platform is in a slim, efficient, and generally effective state, then L&S will be the best option as you're unlikely to be migrating problems and technical debt onto the new platform. However, while refactoring may seem like more effort as you're effectively starting from scratch, the reality is that, if your current platform is a bit of a mess, then you'll just be carrying tech debt and opportunity/effectiveness loss over to the new platform if you DON'T refactor.
Pete
Proud to be a Datanaut!
Hi @powerbiexpert22,
Just following up to see if the Response provided by community members were helpful in addressing the issue. if the issue still persists Feel free to reach out if you need any further clarification or assistance.
Best regards,
Prasanna Kumar
Hi @powerbiexpert22,
Thank you for reaching out to the Microsoft Fabric Forum Community, and special thanks to @BA_Pete and @Thomaslleblanc for prompt and helpful responses.
Just following up to see if the Response provided by community members were helpful in addressing the issue. if the issue still persists Feel free to reach out if you need any further clarification or assistance.
Best regards,
Prasanna Kumar
You can not do a Lift and Shift if changing reporting tools. Unless, the new tool has a conversion option to convert previous report file to new report tool.
Refractoring is to improve the existing report with new features or remove outdated process/charts to improve performance
Choose Lift‑and‑Shift if:
Choose Refactoring if:
Hi @powerbiexpert22 ,
In a nutshell:
Lift-and-Shift (L&S) is just replicating everything as-is on a new platform, including poor business logic, ineffective visuals etc.
Refactoring is rebuilding (sort of) from scratch on the new platform, correcting poor business logic, improving visual effectiveness etc. but also making use of any new/improved functionality that the new tool/platform can provide.
Re: Report rationalisation - yes, you can (and should) do this as part of L&S. You would not L&S any reports that are currently unused or are marked for deprecation, but these decisions would only be made within the scope of reducing the number of items to migrate in totality, not drifting into part-item rationalisation (e.g. slimming down a model then migrating it afterwards) as this then gets into Refactoring.
Re: Time/effort between the two - this is a grey area. I think it would largely depend on how good (or bad) a state your current tool/platform is in. If the current platform is in a slim, efficient, and generally effective state, then L&S will be the best option as you're unlikely to be migrating problems and technical debt onto the new platform. However, while refactoring may seem like more effort as you're effectively starting from scratch, the reality is that, if your current platform is a bit of a mess, then you'll just be carrying tech debt and opportunity/effectiveness loss over to the new platform if you DON'T refactor.
Pete
Proud to be a Datanaut!
Share feedback directly with Fabric product managers, participate in targeted research studies and influence the Fabric roadmap.
| User | Count |
|---|---|
| 63 | |
| 62 | |
| 42 | |
| 19 | |
| 16 |
| User | Count |
|---|---|
| 118 | |
| 106 | |
| 38 | |
| 28 | |
| 27 |