Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Next up in the FabCon + SQLCon recap series: The roadmap for Microsoft SQL and Maximizing Developer experiences in Fabric. All sessions are available on-demand after the live show. Register now

Reply
Aparnaa_MS
Advocate II
Advocate II

Fabric Warehouse BACPAC Deployment from Dev to Prod – Dropped Tables Not Removed in Prod

Hi everyone, 

I’m deploying a Microsoft Fabric Warehouse from Dev to Prod using Azure DevOps BACPAC-based deployment and I've run into a behaviour I'd like to understand better.

As part of understanding how schema changes are handled, I tested the following scenario:

  • A table was dropped in the Dev Fabric Warehouse
  • The Azure DevOps pipeline was triggered to deploy the latest BACPAC to Prod
  • The deployment completed successfully

However, after the deployment:

  • The dropped table still exists in the Prod warehouse
  • Other changes (new/modified objects) seem to deploy as expected, but deletions are not reflected

This raised a few questions for me:

  1. Is this the expected behavior when deploying Fabric Warehouse using BACPAC?
  2. Does BACPAC deployment only add or update objects and not remove dropped objects in the target environment?
  3. Is there any supported way to sync deletions (for example, dropped tables) from Dev to Prod as part of CI/CD?

Any pointers or alternative approaches would be greatly appreciated!

Thanks in advance!

1 ACCEPTED SOLUTION
Lodha_Jaydeep
Resolver III
Resolver III

Hi @Aparnaa_MS ,

Thanks you reaching out to fabric community. Will happy to help with your issue. Here are the answers to your questions.

Question 1&2: Yes, this is expected behavior when using BACPAC deployment.

A BACPAC is essentially a snapshot of the database schema and data, and when you deploy/import it to the target (Prod), it focuses on:

  • Creating missing objects
  • Updating existing objects

However, it does NOT perform schema comparison and does NOT remove objects that exist in the target but are no longer present in the source (Dev). This is by design to avoid unintended data loss in the target environment.

 

Why your dropped table still exists in Prod:

  • The table was removed in Dev
  • BACPAC deployment does not detect or apply deletions
  • Therefore, the table remains in Prod

 

Question 3: Here are the ways for the work around you can use for the deplyment.

How to handle deletions in CI/CD:

If you need Dev and Prod to stay fully in sync (including dropped objects), you should consider these approaches:

1. Use DACPAC (Recommended Solution)

  • DACPAC supports schema comparison
  • You can enable:

    /p:DropObjectsNotInSource=True
  • This ensures objects removed in Dev are also removed in Prod

2. Use Schema Compare / Deployment Scripts

  • Generate SQL scripts that explicitly include DROP statements
  • Deploy those scripts via your pipeline

3. Maintain Migration-Based Scripts

  • Track changes (CREATE / ALTER / DROP) in version control.
  • Apply them incrementally in your release pipeline.
    I hope you find this suggestion helpful! If it resolves your issue, please consider accepting it as the answer.
    it helps others in the community too. Always happy to assist further if needed. Kudos are always appreciated!

View solution in original post

1 REPLY 1
Lodha_Jaydeep
Resolver III
Resolver III

Hi @Aparnaa_MS ,

Thanks you reaching out to fabric community. Will happy to help with your issue. Here are the answers to your questions.

Question 1&2: Yes, this is expected behavior when using BACPAC deployment.

A BACPAC is essentially a snapshot of the database schema and data, and when you deploy/import it to the target (Prod), it focuses on:

  • Creating missing objects
  • Updating existing objects

However, it does NOT perform schema comparison and does NOT remove objects that exist in the target but are no longer present in the source (Dev). This is by design to avoid unintended data loss in the target environment.

 

Why your dropped table still exists in Prod:

  • The table was removed in Dev
  • BACPAC deployment does not detect or apply deletions
  • Therefore, the table remains in Prod

 

Question 3: Here are the ways for the work around you can use for the deplyment.

How to handle deletions in CI/CD:

If you need Dev and Prod to stay fully in sync (including dropped objects), you should consider these approaches:

1. Use DACPAC (Recommended Solution)

  • DACPAC supports schema comparison
  • You can enable:

    /p:DropObjectsNotInSource=True
  • This ensures objects removed in Dev are also removed in Prod

2. Use Schema Compare / Deployment Scripts

  • Generate SQL scripts that explicitly include DROP statements
  • Deploy those scripts via your pipeline

3. Maintain Migration-Based Scripts

  • Track changes (CREATE / ALTER / DROP) in version control.
  • Apply them incrementally in your release pipeline.
    I hope you find this suggestion helpful! If it resolves your issue, please consider accepting it as the answer.
    it helps others in the community too. Always happy to assist further if needed. Kudos are always appreciated!

Helpful resources

Announcements
FabCon and SQLCon Highlights Carousel

FabCon &SQLCon Highlights

Experience the highlights from FabCon & SQLCon, available live and on-demand starting April 14th.

New to Fabric survey Carousel

New to Fabric Survey

If you have recently started exploring Fabric, we'd love to hear how it's going. Your feedback can help with product improvements.

March Fabric Update Carousel

Fabric Monthly Update - March 2026

Check out the March 2026 Fabric update to learn about new features.