Forum Discussion
Advocate IPower BI Incremental Load HELP
I developed a Power BI report in Power BI Desktop. Initially, I loaded data from January 2025 to May 31, 2026, and configured Incremental Refresh to refresh the last 4 days only.
I then published the report to the Power BI Service. The scheduled refresh has been running every day, and today (June 27) the report in the Power BI Service shows data up to June 27.
Now I opened the original Power BI Desktop (.pbix) file, which still contains data only up to May 31. I added some new pages, visuals, and measures, but I did not refresh the data in Desktop.
If I now publish this updated .pbix file and choose Replace, what will happen?
My concern is:
The report in the Power BI Service currently has data up to June 27.
The Desktop file only has data up to May 31.
After I replace the report, will the Power BI Service show data only up to May 31 again?
When the next scheduled refresh runs, will it refresh only the last 4 days (because of Incremental Refresh)?
If so, what happens to the data from June 1 to June 24? Will it remain, or will it be lost?
My main question is: What is the standard way organizations work in this situation?
In real projects, developers frequently need to add new pages, visuals, and measures and republish reports. How do they do this without losing the historical data already refreshed in the Power BI Service?
I have only one PBIX file which contain 5 pages.... I need to update daily adding new things etc... and maybe in near future will load more tables etc...
Yes, publishing your Desktop PBIX with Replace will overwrite the dataset in the Service with the model that only has data through May 31. The historical partitions built up by the daily refreshes (June 1 to June 27) will be discarded. After that, the next scheduled refresh will only bring in the last 4 days based on your incremental policy, so you would have a gap roughly from June 1 to around June 23.
The standard approach once incremental refresh is running is to stop republishing the full PBIX from Desktop. Instead, you push only the metadata changes (new pages, visuals, new measures) to the published dataset using the XMLA endpoint, typically with Tabular Editor or ALM Toolkit. That preserves all the data partitions already in the Service. This path requires PPU or Premium capacity for XMLA write access.
If you are on Pro and cannot use XMLA, the practical workaround is to widen the incremental refresh policy window so a republish can rebuild the full range from the source, assuming the source still holds the historical rows.
If this helped, a thumbs up and accepting it as the solution would be appreciated.
Best regards,
Shai Karmani- The danger is that replacing the full PBIX can replace the semantic model in the Service, including the partitions that were built by incremental refresh.The standard pattern in real projects is to separate the semantic model from the report:
- one PBIX / semantic model for the dataset, incremental refresh, relationships, measures
- separate thin report PBIX files connected live to that semantic modelThen you can update pages and visuals without republishing the semantic model and without risking the historical partitions.If you need to change measures or model metadata, that is different: measures live in the semantic model. In Premium / PPU / Fabric capacity, you can use XMLA-based tools such as Tabular Editor or ALM Toolkit to deploy only metadata changes and preserve existing partitions.If you are on Pro only, the safer workaround is to make sure your incremental refresh policy can rebuild the needed history from the source, because republishing the full PBIX can reset the Service model.So the best practice is:- avoid republishing the full PBIX once incremental refresh is running- use thin reports for visual/page changes- use XMLA/ALM tools for model or measure changes where available- keep enough historical data in the source so the model can be rebuilt if needed🔍Parchitect
Solutions Architect · Microsoft Fabric Specialist💡Helpful? Kudos are appreciated.
✔️Solved? Mark as Solution so others can find it faster.
5 Replies
- Parchitect
Solution Sage
The danger is that replacing the full PBIX can replace the semantic model in the Service, including the partitions that were built by incremental refresh.The standard pattern in real projects is to separate the semantic model from the report:- one PBIX / semantic model for the dataset, incremental refresh, relationships, measures
- separate thin report PBIX files connected live to that semantic modelThen you can update pages and visuals without republishing the semantic model and without risking the historical partitions.If you need to change measures or model metadata, that is different: measures live in the semantic model. In Premium / PPU / Fabric capacity, you can use XMLA-based tools such as Tabular Editor or ALM Toolkit to deploy only metadata changes and preserve existing partitions.If you are on Pro only, the safer workaround is to make sure your incremental refresh policy can rebuild the needed history from the source, because republishing the full PBIX can reset the Service model.So the best practice is:- avoid republishing the full PBIX once incremental refresh is running- use thin reports for visual/page changes- use XMLA/ALM tools for model or measure changes where available- keep enough historical data in the source so the model can be rebuilt if needed🔍Parchitect
Solutions Architect · Microsoft Fabric Specialist💡Helpful? Kudos are appreciated.
✔️Solved? Mark as Solution so others can find it faster. - Shai_Karmani
Super User
Yes, publishing your Desktop PBIX with Replace will overwrite the dataset in the Service with the model that only has data through May 31. The historical partitions built up by the daily refreshes (June 1 to June 27) will be discarded. After that, the next scheduled refresh will only bring in the last 4 days based on your incremental policy, so you would have a gap roughly from June 1 to around June 23.
The standard approach once incremental refresh is running is to stop republishing the full PBIX from Desktop. Instead, you push only the metadata changes (new pages, visuals, new measures) to the published dataset using the XMLA endpoint, typically with Tabular Editor or ALM Toolkit. That preserves all the data partitions already in the Service. This path requires PPU or Premium capacity for XMLA write access.
If you are on Pro and cannot use XMLA, the practical workaround is to widen the incremental refresh policy window so a republish can rebuild the full range from the source, assuming the source still holds the historical rows.
If this helped, a thumbs up and accepting it as the solution would be appreciated.
Best regards,
Shai Karmani- alicegray
Helper I
Incremental refresh is a great option for large datasets, but it depends on having a reliable column that identifies new or updated records. Typically, this is a Last Modified or Transaction Date field. If your source doesn't have one, Power BI can't determine which rows need to be refreshed, so it may end up processing more data than expected. If you're using SQL Server, features like Change Tracking or Change Data Capture (CDC) can help identify changes efficiently. Could you share which data source you're connecting to and whether you already have a date or timestamp column available?
- Ahmed-Elfeel
Hi mustafa_data ,
I hope you are doing well today ☺️✨
So deploying the local .pbix file which contains a data snapshot limited to May 31st via the Replace option will overwrite the existing semantic model residing in the Power BI Service
This action will purge the incremental partitions that were built by daily scheduled refreshes from June 1st through June 27th following the overwrite and the next scheduled refresh will execute strictly according to your 4 day incremental policy retrieving only the most recent window (approximately June 23rd to 27th)
Note: This creates a permanent data gap for the period spanning June 1st to June 23rd unless immediate manual remediation is performed.
So here is also recommended approach (Workaround) for PowerBI Pro license:
- Temporarily expand the Store rows from the past window within your refresh policy to encompass the complete historical period (e.g., from January 2025 to the current date)
- Deploy the updated .pbix file to the Service via the replace option
- Immediately trigger a Full Refresh on the published dataset to materialize all historical data from the source system
- Once the refresh completes successfully revert the incremental policy to your preferred 4day retention window
if this post helps, then I would appreciate a thumbs up and mark it as the solution to help the other members find it more quickly.
mustafa_dataHi Ahmed,
Thank you.
I currently have a 4-day incremental refresh policy configured in Power BI Desktop. Suppose I temporarily change it to 30 days, then republish the report and trigger a refresh in the Power BI Service. The service correctly loads the last 30 days of data, which is expected.
Now I want to switch the policy back to 4 days. To do that, I open the same Power BI Desktop file (which still contains data only up to 31 May), change the policy back to 4 days, and republish the report.
My understanding is that this republishes the model from Power BI Desktop, which contains data only up to 31 May, and overwrites the existing model in the Power BI Service.
If that's the case, what is the benefit of changing the incremental refresh policy? Doesn't republishing the report overwrite the existing model and require the service to rebuild it again?
Could you please clarify how this is supposed to work?
