Azure SQL BACPAC parallel imports stuck at 100% for extended periods – expected behavior?

Question

Azure SQL BACPAC parallel imports stuck at 100% for extended periods – expected behavior?

FELDNER Ilanit 40

Hi,

I’m looking for clarification on the expected behavior of Azure SQL Database** BACPAC imports**, particularly in environments where imports may be triggered in parallel and imports reach 100% but do not complete.

Environment

Azure SQL Database
SKUs tested:

General Purpose, Gen5, 8 vCores

Hyperscale, provisioned, 8 vCores
Imports are done on copy DB's from another logical server

Imports initiated via Azure.ResourceManager.Sql (tested with both production SDK versions and 1.4.0-beta.3)

Fully Managed Identity–based flow (no SAS, no stored credentials)

No pod-based - as we want to avoid pods hanging on long imports

Private Endpoint Connections are used and approved

BACPACs stored in Azure Blob Storage (same region)

All imports target the same logical SQL server

Users can trigger imports independently

The solution must support importing both small and large (including very large) BACPACs

Observed behavior

Imports often reach 100% and then get stuck at that state for days.

Some imports eventually fail after remaining at 100%.

This behavior occurs for small BACPACs, and is observed on both GP Gen5 and Hyperscale.

The issue reproduces across multiple attempts and SDK versions.

Questions

Is this behavior (parallel imports reaching 100% and then getting stuck or failing) expected by design for Azure SQL BACPAC imports?

What does “100%” represent in the BACPAC import lifecycle, and what work (if any) happens after that point?

Is there a supported way to determine whether an import that reached 100% is still progressing versus effectively stuck?

Given the constraints above (parallel users, MI-only, no pod-based solution, mixed small and large BACPACs), are there recommended patterns to avoid imports getting stuck or failing?

Thanks for any clarification

FELDNER Ilanit 40 Reputation points

2025-12-25T09:54:37.5833333+00:00
Thanks for the response.

To answer your questions and clarify our constraints:

Metrics / bottlenecks: Yes, we’ve reviewed Azure SQL Database metrics during these imports. We do not see sustained CPU / DTU saturation when imports are stuck at 100%, including for small BACPACs. This has been observed on both General Purpose Gen5 (8 vCores) and Hyperscale (8 vCores).

Parallel imports / staggering: Staggering imports is not a reliable option for us. This is a production, automated flow, and imports may be triggered in parallel by design. This is not a manual or one-off migration scenario.

BACPAC sizes: The behavior is not limited to large imports. We are seeing imports reach 100% and then get stuck or eventually fail even for a small BACPAC (~35 MB / 35,001 KB). The same solution must also support very large BACPACs (hundreds of GBs / TB scale).

Additional important constraints in our environment:

SqlPackage is not an option. We must use an Azure-managed import mechanism only, with Managed Identity, no SAS tokens, and no client-side / pod-based execution.

We intentionally rely on the Azure SQL Import/Export service via ARM/SDK, with Private Endpoint Connections approved as part of the process.

Given all of the above, I’m trying to clarify the following:

Are there any Azure-managed alternatives to the Import/Export service for BACPACs that provide stronger guarantees around completion or parallel behavior?

Or is the Import/Export service the only supported Azure-side option, with completion and parallelism being best-effort, particularly during the finalization phase after the import reaches 100% (indexes, metadata, commit)?

Is it expected that an import can reach 100% and still remain stuck or fail later, even for small BACPACs, under parallel usage on a single logical SQL server?

One additional clarification: we sometimes use the same BACPAC file to initiate multiple imports (to different target databases) when imports are triggered in parallel. Is reusing the same BACPAC artifact fully supported, or are there any known limitations, contention, or best-effort behaviors associated with doing so?

I’ve attached a screenshot from the Import/Export history showing multiple imports on the same server with mixed outcomes (completed, failed, and running at 100% for an extended period), to illustrate the behavior we’re seeing.

Any clarification on the expected guarantees or documented limitations of the Azure SQL Import/Export service in this scenario would be very helpful.
Erland Sommarskog 134.1K Reputation points MVP Volunteer Moderator

2025-12-25T10:25:06.5333333+00:00

When you say parallel imports, do you mean that you are running two BACPACs against the same database?

You say that you have reviewed Azure SQL Database metrics, but have you actually looked into the database to see if there is any activity that appears to come from a BACPAC? There are any ways to deduce this, but one is to use my beta_lockinfo, which will give you a snapshot of the activity, including any blocking.
FELDNER Ilanit 40 Reputation points

2025-12-25T11:18:59.56+00:00

To clarify: we are using the same single BACPAC file, importing it into different target databases on the same logical SQL server. The behavior is inconsistent — the same BACPAC may complete in about 30 minutes in some cases, or remain stuck for many hours or days in others.

We have also tested using different BACPAC files across multiple databases (so the same BACPAC is not reused), and we still observe the same behavior.

Given that, the open question for us is not about BACPAC content or database-level locking, but about how Azure-managed BACPAC imports behave under parallel execution and what practical patterns are recommended to run this reliably in production.
Manoj Kumar Boyini 14,665 Reputation points Microsoft External Staff Moderator

2025-12-25T13:39:19.8533333+00:00

Hi FELDNER Ilanit,

Thanks for the clarification. Based on similar Azure SQL Import/Export scenarios, this behavior can occur when multiple BACPAC imports run in parallel on the same logical Azure SQL server, even when targeting different databases and even for relatively small BACPACs.

When progress reaches 100%, the data copy phase has typically completed. After that point, Azure SQL still needs to perform finalization work such as index creation, constraint validation, statistics generation, and transaction log commits. These steps can be log-write and I/O intensive and are subject to Azure SQL platform governance. This kind of throttling does not always surface clearly in CPU or DTU metrics.

One common way to validate whether this is occurring is to inspect activity inside a target database while an import appears stuck — for example by checking sys.dm_db_resource_stats. If avg_log_write_percent is high while CPU usage remains low, it indicates the finalization phase is being limited by log-write governance rather than database-level blocking.

Import/Export is currently the only Azure-managed mechanism for BACPAC imports and does not provide deterministic completion guarantees under parallel execution on a single logical server. Reusing the same BACPAC file is supported, but high parallelism can increase contention; using different BACPACs does not necessarily avoid this behavior.

From a production perspective, recommended patterns include serializing imports per logical server, distributing imports across multiple logical servers, or temporarily scaling up the target server during imports. If stronger guarantees are required, Azure Database Migration Service or native restore to Azure SQL Managed Instance may be better-suited alternatives.

Helpful References:
Troubleshoot Azure SQL Database Import/Export issues
Import a BACPAC file to Azure SQL Database
Azure Database Migration Service overview

Hope this helps, Please let us know if you have any questions and concerns.
Erland Sommarskog 134.1K Reputation points MVP Volunteer Moderator

2025-12-25T13:53:30.3566667+00:00

Given that, the open question for us is not about BACPAC content or database-level locking,

Nevertheless, it is worthwhile as a means of troubleshooting to get an understanding of what is going on.

Manoj says:

Azure SQL must still perform finalization work such as index creation, constraint validation, statistics generation, and transaction log commits.

If this is what is going on here, you would indeed see quite a bit of activity. At the same time, I like to add that this makes little sense in the case of small databases. If such imports are seemingly stuck at 100% for hours, blocking is the only possibility, if the issue is on the database side that is. You may sense that I am not sure whether Manoj is speaking of knowledge, or if he is just making things up.

You did not say whether the imports were parallel in the same database, or just in parallel on the same logical server. I may be naïve, but in the latter case, I can't see that the parallel business matters, since the database may very well be on different physical servers. But I'm not pretending to be a cloud expert. (My expertise is with the SQL Server Database Engine itself.)

A possible alternative would be to use CREATE DATABASE AS COPY OF. In that case, you would not have BACPACs, but databases that sits around and that you can copy to another environment. I am not all sure that this would fit into your scheme, but I mentioned just in case.
Manoj Kumar Boyini 14,665 Reputation points Microsoft External Staff Moderator

2025-12-25T14:48:10.98+00:00

Hi Erland Sommarskog,

I agree that for small databases this should normally complete quickly, which is why validating what’s actually happening during the “100%” phase is important. In Azure SQL, Import/Export can still be subject to platform-level behavior (for example, throttled finalization), so checking DMVs is the best way to distinguish between blocking, throttling, or service orchestration effects.

Your suggestion of CREATE DATABASE AS COPY OF is a very good one and is definitely the cleanest approach when the source is already Azure SQL. In this case the flow is BACPAC-based across environments, but the idea of importing once into a template database and then copying from there is a solid option to improve reliability.

Thanks again for the insights.

References:
https://learn.microsoft.com/en-us/azure/azure-sql/database/database-import-export-hang?view=azuresql
https://learn.microsoft.com/en-us/azure/azure-sql/database/resource-limits-logical-server?view=azuresql
https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-resource-stats-azure-sql-database?view=fabric-sqldb
Erland Sommarskog 134.1K Reputation points MVP Volunteer Moderator

2025-12-25T15:54:50.45+00:00

My impression is that database copy is not BACPAC-based, but I get the impression that bytes are copied from a transactionally consistent snapshot of the database. But it remains to see, if this solution fits into Feldner's scenario. And if it does, they would certainly have to re-engineer things quite a bit.
Anonymous

2025-12-26T05:17:01.8566667+00:00

Hi @FELDNER Ilanit

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
FELDNER Ilanit 40 Reputation points

2025-12-28T09:12:50.22+00:00
Thanks for all the replies — I’d like to add a few clarifications about our setup and flow:

We operate a multi-tenant environment with hundreds of Azure SQL Databases. These databases run across different SKUs and models based on customer needs, including Hyperscale (elastic pools), Premium, and General Purpose (serverless).

For each region, we maintain a dedicated Import/Export logical SQL server. When a customer needs to import a new BACPAC, we first copy the database via ARM to this dedicated server and then perform the BACPAC import there, also via ARM, including Private Endpoint approvals.

During the import flow, the databases on the dedicated import server are created as standalone databases, not in elastic pools. We scale these standalone databases up to high tiers for the duration of the import, based on the source database SKU.

The BACPAC files are stored in regional storage accounts, co-located with the target SQL server.

We can see that the Private Endpoint Connections are approved successfully, but in some cases they are deleted before the import has fully completed. It is not clear whether this early cleanup can contribute to the long delays or stalls we observe after the import reaches 100%.

We understand the guidance to serialize imports or isolate them on separate servers. Unfortunately, neither option is feasible for us: imports are triggered automatically in a multi-tenant flow, and we cannot add or dedicate additional SQL servers per request.

Given these constraints, what is the supported or recommended way to reliably run Azure-managed BACPAC imports and determine whether an import that has reached 100% is still actively progressing versus effectively stalled?
Anonymous

2025-12-29T06:30:14.3933333+00:00
Hi @FELDNER Ilanit

Thank you for the detailed clarification regarding your environment setup. After reviewing the additional details you provided, we have outlined the following mitigation steps to help resolve the reported issue -

Is this expected? No—long stalls at 100% are not expected; they usually indicate contention or Import/Export service backlog. Use SqlPackage or copy‑based fan‑out to avoid it.

What does 100% mean? Data transfer finished; Azure SQL is doing finalization internally.

Are PE approvals being deleted early causing stalls? Typically no; service‑managed PEs are job‑scoped and may be removed after storage work ends. Post‑processing does not require storage access.

Supported way to run reliably & detect progress vs stall? Use Pattern A (import once → AS COPY OF) or Pattern B (SqlPackage from same‑region VM with high tier DB). Detect progress using Azure metrics + DMVs/XE; if flat, abort + retry.
Anonymous

2025-12-30T03:39:39.9766667+00:00

Hi @FELDNER Ilanit

Did you get any chance to review the above response. Do let me know if you have any further queries.
FELDNER Ilanit 40 Reputation points

2025-12-30T14:16:44.0833333+00:00

Thank you for the detailed clarification. We understand that long stalls at 100% are not expected and usually indicate contention or backend backlog. However, we have observed this behavior even with very small BACPACs (~35 MB), with sequential execution and when only a single database exists on the server.

We also understand that reaching 100% means data transfer has completed, and Azure SQL is performing internal finalization. The challenge is that during this phase there is often no observable activity and no ARM-level signal to distinguish between active finalization and an effectively stalled operation.

Regarding Private Endpoints, we understand they are service-managed and job-scoped. In our observed cases, endpoint removal coincides with imports that never complete, while ARM continues to report the operation as InProgress, making it difficult to determine whether progress is still occurring.

Finally, while alternatives such as SqlPackage or pod-based execution were mentioned, we are specifically looking for an Azure-managed solution that avoids pod-based or in-cluster processing and can reliably support large BACPAC imports.
Manoj Kumar Boyini 14,665 Reputation points Microsoft External Staff Moderator

2025-12-30T16:27:45.2466667+00:00

Hi FELDNER Ilanit,

I kindly request you to please share the details requested in the private message for further investigation.
Anonymous

2025-12-31T01:16:43.1066667+00:00
Hi FELDNER Ilanit,

Thank you for reviewing the proposed solution. Please find below the mitigation steps that may help address your additional questions.

A. Why Small BACPAC Imports Can “Stall” After 100%

Sometimes, even small BACPAC files (say, around 35 MB) appear stuck after hitting 100% during an import. That doesn’t mean the process has failed — it’s usually just in the finalization phase.

At this stage, the system is busy applying indexes and constraints and validating metadata behind the scenes. Because these internal steps aren’t always reflected in progress meters, it can look frozen even though they’re still working.

You can read more about this behavior in the official docs: Import a BACPAC to Azure SQL Database – Concepts & Limitations.

A few things to keep in mind:

Serverless tiers: If your database uses a serverless tier or was scaled down too early, auto-pause or cold starts can make the import seem idle. Using a provisioned compute tier (Premium, Business Critical, or Hyperscale) and disabling auto-pause during the import helps avoid this. Serverless compute overview

Queue contention: Even small imports can get delayed due to regional Import/Export queue congestion. Import/Export service guidance

B. How to Tell if It’s Still Running or Truly Stalled

Azure doesn’t provide a progress bar for finalization, but you can still check activity using a few signals:

ARM LRO Status: When you start an import via the REST API, you’ll get a status URL. Keep polling it — if it shows “InProgress” for more than about 60 minutes and your database metrics stay flat, it could be stalled. Databases – Import (REST) Learn more about how these status updates work here: Async Operations

Portal metrics: Watch metrics like CPU, data I/O, and log write throughput. If those stay active, finalization is ongoing. Flat metrics across multiple checks (e.g., over 10 minutes) suggest a stall.

DMVs (Dynamic Management Views): Check the following views for ongoing activity:

sys.dm_exec_requests – ongoing index or constraint operations

sys.dm_tran_database_transactions – log updates

sys.dm_tran_locks – long blocking chains Monitoring & Troubleshooting with DMVs

Activity Log: Look at the Subscription Activity Log for Import/Export events. If no new events appear after the 100% mark and metrics remain flat, the job most likely stalled. Azure Activity Log

C. Private Endpoint Removal During “InProgress” Imports

If you notice the private endpoint (PE) disappearing during import, that’s completely normal. These endpoints are temporary and are only needed while the system accesses your storage. Once the data transfer stage is over, the finalization phase happens entirely within Azure SQL, so the PE is removed.

This doesn’t mean there’s an issue — it just signals that the storage phase is complete. Private Endpoints for Azure SQL Import/Export Private Link (Preview)

If the endpoint is removed and the job never reaches “Succeeded,” go back to the checks in Section B to see if the process stalled.

D. A Reliable Azure-Managed Approach for Large BACPACs

For large imports where you don’t want to use in-cluster tools or pods, try this two-step approach to keep things fast and dependable:

Stage 1 – Import into a Staging Database

Create an empty database on a high-tier server (Premium, Business Critical, or Hyperscale).

Import the BACPAC through the Azure Portal, PowerShell, or REST.

Monitor it using ARM status polling, metrics, and DMVs.

Once finished, keep the staging DB online — don’t scale it down yet.

Import a BACPAC Databases – Import (REST) Elastic Pool Import Limitations

Stage 2 – Use Database Copy for Distribution After the import completes, create tenant copies from the staging database using Azure’s Database Copy feature. In Hyperscale, this process is nearly instant because it uses snapshots.

Copy a Database

This way, you only run one heavy import but can spin up multiple tenant databases efficiently.

E. What to Do if the Import Stalls

If you suspect the import is stuck after checking the metrics:

Abort: Drop the target DB — data hasn’t been finalized yet, so it’s safe.

Retry: Run the import again, ideally with temporarily higher compute.

Fan-out: Once the staging import succeeds, copy from that instead of re-importing for each tenant.
Erland Sommarskog 134.1K Reputation points MVP Volunteer Moderator

2025-12-31T10:35:40.77+00:00

Sometimes, even small BACPAC files (say, around 35 MB) appear stuck after hitting 100% during an import. That doesn’t mean the process has failed — it’s usually just in the finalization phase. At this stage, the system is busy applying indexes and constraints and validating metadata behind the scenes. Because these internal steps aren’t always reflected in progress meters, it can look frozen even though they’re still working.

Sorry for being blunt, but this is hogwash. To start with, the indexes and constraints come with the bacpac, and the bacpac should not say 100% until it has completed this phase. But since I rarely import bacpacs myself, I don't know what the experience is. What is more to the point is that creating indexes and constraints for a 35 MB bacpac does not take a whole lot of time, not even with a feeble service level like an S0.

In any case, Feldner, as I've mentioned a few times, you can easily determine if this would be the case by running my beta_lockinfo to see what activity there are in the database. Essentially, this is the same advice as Vrishnabanath is giving when he says that you should look at DMVs. My beta_lockinfo simply gathers that piece of information into a single place. And most importantly: it will show any blocking, which is the only imaginable explanation on the SQL Server side of things why the import gets stalled. (The stall could also be on the machine which actually running the bacpac. Since that machine is part of the service and invisible to us, it is more difficult to diagnose.)

You can read more about this behavior in the official docs: Import a BACPAC to Azure SQL Database – Concepts & Limitations.

I could not see anything in that topic that relates to this behaviour. I note that it recommends SqlPackage over the portal, which certainly is a hint to Feldner. But it does not talk about "finalisation" what I can see.

Serverless tiers: If your database uses a serverless tier or was scaled down too early, auto-pause or cold starts can make the import seem idle

As long as the import is talking with SQL Server, the database is not going on autopause in the middle of it all. Of course, if the import agent goes for lunch or is inactive in SQL Server for a longer period, the database may autopause. But once the agent is back from lunch, the database will wake up in a few minutes. The more interesting question is why the import agent would be inactive for such a long time that the database autopauses.

Queue contention: Even small imports can get delayed due to regional Import/Export queue congestion. Import/Export service guidance

That link only seems to talk about export?

I think I stop there. But Feldner, I think you see where I'm going: I don't have much faith in the advice you get here in this forum.

Given the scale and complexity of your solution, I would assume that you are in an organisation with a good support policy. I would recommend that you open a support case on a higher level than developer (which has you to end up here). Maybe then you get to talk with someone who knows a little more about these things, and maybe more importantly, someone who can investigate on the Azure side of things that are going on with these stalls.

Then again, I would not be surprised if you would be given the same advice, as you got here originally: Use SqlPackage or redesign your solution in some other way. I have a gut feeling that you may be using the import service on a level or a purpose for which it was not designed originally. But I should hasten to add that bacpac import is not within my expertise, so I could very well be wrong.

Answer accepted by question author

Anonymous

Hi @FELDNER Ilanit

Thanks for reaching out to Microsoft Q&A! Here’s a step-by-step guide to help you fix the issue.

It seems like you're running into some really critical behavior with Azure SQL Database BACPAC imports getting stuck at 100%. Let me break things down a bit and outline what might be going on, along with a few things you can try next.

Is This Normal?

In short, no. A BACPAC import shouldn’t get stuck at 100% for too long. If that’s happening, it usually means something in the background is causing a slowdown—especially if multiple imports are running at the same time.

What Does “100%” Actually Mean?

When the progress hits 100%, it typically means the data transfer itself is done. However, that’s not the end of the process. Azure might still be doing things like creating indexes, updating metadata, or finalizing the schema. If the database is under heavy load or there’s competition for resources, this is where things often get hung up.

How to Check If It's Truly Stuck

Instead of just relying on the Azure Portal, here are a couple of ways to get a clearer picture:

Use Get-AzSqlDatabaseImportExportStatus in Azure PowerShell to track the import’s real-time status.
Keep an eye on the database metrics to see if the CPU, DTUs, or storage are maxing out.

Avoid Stuck Imports

Given you're running parallel imports and using Managed Identity without pods, here are a few things you can try:

Reduce Parallel Imports: If possible, space out your imports so they don’t all run at once.
Temporarily Scale Up: Moving to a higher tier during imports can give you more resources to handle the load.
Try SqlPackage: If you're dealing with larger BACPACs (especially over 150GB), SqlPackage is often more reliable than imports through the portal.
Check for Clustered Indexes: Large tables without clustered indexes can really slow things down.
Validate Source DB Settings: Ensure the source database doesn’t have unsupported configurations, logins, or settings that could cause issues during the import.

A Few Questions to help find the Issue:

Have you checked your Azure SQL Database metrics for any CPU or DTU bottlenecks?
Would staggering the imports be an option to reduce the load?
What sizes are the BACPAC files you're working with?

Reference B articles -

0 comments

1 additional answer

Your answer

Erland Sommarskog 134.1K Reputation points MVP Volunteer Moderator

2025-12-25T10:25:06.5333333+00:00

When you say parallel imports, do you mean that you are running two BACPACs against the same database?

You say that you have reviewed Azure SQL Database metrics, but have you actually looked into the database to see if there is any activity that appears to come from a BACPAC? There are any ways to deduce this, but one is to use my beta_lockinfo, which will give you a snapshot of the activity, including any blocking.
FELDNER Ilanit 40 Reputation points

2025-12-25T11:18:59.56+00:00

To clarify: we are using the same single BACPAC file, importing it into different target databases on the same logical SQL server. The behavior is inconsistent — the same BACPAC may complete in about 30 minutes in some cases, or remain stuck for many hours or days in others.

We have also tested using different BACPAC files across multiple databases (so the same BACPAC is not reused), and we still observe the same behavior.

Given that, the open question for us is not about BACPAC content or database-level locking, but about how Azure-managed BACPAC imports behave under parallel execution and what practical patterns are recommended to run this reliably in production.
Erland Sommarskog 134.1K Reputation points MVP Volunteer Moderator

2025-12-25T13:53:30.3566667+00:00

Given that, the open question for us is not about BACPAC content or database-level locking,

Nevertheless, it is worthwhile as a means of troubleshooting to get an understanding of what is going on.

Manoj says:

Azure SQL must still perform finalization work such as index creation, constraint validation, statistics generation, and transaction log commits.

If this is what is going on here, you would indeed see quite a bit of activity. At the same time, I like to add that this makes little sense in the case of small databases. If such imports are seemingly stuck at 100% for hours, blocking is the only possibility, if the issue is on the database side that is. You may sense that I am not sure whether Manoj is speaking of knowledge, or if he is just making things up.

You did not say whether the imports were parallel in the same database, or just in parallel on the same logical server. I may be naïve, but in the latter case, I can't see that the parallel business matters, since the database may very well be on different physical servers. But I'm not pretending to be a cloud expert. (My expertise is with the SQL Server Database Engine itself.)

A possible alternative would be to use CREATE DATABASE AS COPY OF. In that case, you would not have BACPACs, but databases that sits around and that you can copy to another environment. I am not all sure that this would fit into your scheme, but I mentioned just in case.
Manoj Kumar Boyini 14,665 Reputation points Microsoft External Staff Moderator

2025-12-25T14:48:10.98+00:00

Hi Erland Sommarskog,

I agree that for small databases this should normally complete quickly, which is why validating what’s actually happening during the “100%” phase is important. In Azure SQL, Import/Export can still be subject to platform-level behavior (for example, throttled finalization), so checking DMVs is the best way to distinguish between blocking, throttling, or service orchestration effects.

Your suggestion of CREATE DATABASE AS COPY OF is a very good one and is definitely the cleanest approach when the source is already Azure SQL. In this case the flow is BACPAC-based across environments, but the idea of importing once into a template database and then copying from there is a solid option to improve reliability.

Thanks again for the insights.

References:
https://learn.microsoft.com/en-us/azure/azure-sql/database/database-import-export-hang?view=azuresql
https://learn.microsoft.com/en-us/azure/azure-sql/database/resource-limits-logical-server?view=azuresql
https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-resource-stats-azure-sql-database?view=fabric-sqldb
Erland Sommarskog 134.1K Reputation points MVP Volunteer Moderator

2025-12-25T15:54:50.45+00:00

My impression is that database copy is not BACPAC-based, but I get the impression that bytes are copied from a transactionally consistent snapshot of the database. But it remains to see, if this solution fits into Feldner's scenario. And if it does, they would certainly have to re-engineer things quite a bit.
Anonymous

2025-12-26T05:17:01.8566667+00:00

Hi @FELDNER Ilanit

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.
FELDNER Ilanit 40 Reputation points

2025-12-28T09:12:50.22+00:00

Thanks for all the replies — I’d like to add a few clarifications about our setup and flow:

We operate a multi-tenant environment with hundreds of Azure SQL Databases. These databases run across different SKUs and models based on customer needs, including Hyperscale (elastic pools), Premium, and General Purpose (serverless).

For each region, we maintain a dedicated Import/Export logical SQL server. When a customer needs to import a new BACPAC, we first copy the database via ARM to this dedicated server and then perform the BACPAC import there, also via ARM, including Private Endpoint approvals.

During the import flow, the databases on the dedicated import server are created as standalone databases, not in elastic pools. We scale these standalone databases up to high tiers for the duration of the import, based on the source database SKU.

The BACPAC files are stored in regional storage accounts, co-located with the target SQL server.

We can see that the Private Endpoint Connections are approved successfully, but in some cases they are deleted before the import has fully completed. It is not clear whether this early cleanup can contribute to the long delays or stalls we observe after the import reaches 100%.

We understand the guidance to serialize imports or isolate them on separate servers. Unfortunately, neither option is feasible for us: imports are triggered automatically in a multi-tenant flow, and we cannot add or dedicate additional SQL servers per request.

Given these constraints, what is the supported or recommended way to reliably run Azure-managed BACPAC imports and determine whether an import that has reached 100% is still actively progressing versus effectively stalled?
Anonymous

2025-12-29T06:30:14.3933333+00:00

Hi @FELDNER Ilanit

Thank you for the detailed clarification regarding your environment setup. After reviewing the additional details you provided, we have outlined the following mitigation steps to help resolve the reported issue -

Is this expected? No—long stalls at 100% are not expected; they usually indicate contention or Import/Export service backlog. Use SqlPackage or copy‑based fan‑out to avoid it.

What does 100% mean? Data transfer finished; Azure SQL is doing finalization internally.

Are PE approvals being deleted early causing stalls? Typically no; service‑managed PEs are job‑scoped and may be removed after storage work ends. Post‑processing does not require storage access.

Supported way to run reliably & detect progress vs stall? Use Pattern A (import once → AS COPY OF) or Pattern B (SqlPackage from same‑region VM with high tier DB). Detect progress using Azure metrics + DMVs/XE; if flat, abort + retry.
Anonymous

2025-12-30T03:39:39.9766667+00:00

Hi @FELDNER Ilanit

Did you get any chance to review the above response. Do let me know if you have any further queries.
FELDNER Ilanit 40 Reputation points

2025-12-30T14:16:44.0833333+00:00

Thank you for the detailed clarification. We understand that long stalls at 100% are not expected and usually indicate contention or backend backlog. However, we have observed this behavior even with very small BACPACs (~35 MB), with sequential execution and when only a single database exists on the server.

We also understand that reaching 100% means data transfer has completed, and Azure SQL is performing internal finalization. The challenge is that during this phase there is often no observable activity and no ARM-level signal to distinguish between active finalization and an effectively stalled operation.

Regarding Private Endpoints, we understand they are service-managed and job-scoped. In our observed cases, endpoint removal coincides with imports that never complete, while ARM continues to report the operation as InProgress, making it difficult to determine whether progress is still occurring.

Finally, while alternatives such as SqlPackage or pod-based execution were mentioned, we are specifically looking for an Azure-managed solution that avoids pod-based or in-cluster processing and can reliably support large BACPAC imports.
Manoj Kumar Boyini 14,665 Reputation points Microsoft External Staff Moderator

2025-12-30T16:27:45.2466667+00:00

Hi FELDNER Ilanit,

I kindly request you to please share the details requested in the private message for further investigation.

Answer 1

AI answer

When using the Azure SQL Database Import/Export service, it is not uncommon for imports to reach 100% and then appear to get stuck for extended periods. This behavior can be attributed to several factors:

What does “100%” represent?
The 100% completion status indicates that the service has finished processing the data transfer. However, it does not necessarily mean that all finalization tasks are complete. After reaching 100%, the service may still be performing additional work related to the logical backup, such as finalizing the import process and ensuring data integrity.
Determining Progress:
Unfortunately, there is no straightforward method to determine if an import that has reached 100% is still progressing or effectively stuck. The service has a limited number of compute virtual machines (VMs) per region to handle import/export operations, and if multiple requests are made simultaneously, it can lead to delays. If an import remains at 100% for an extended period (e.g., days), it may indicate that the operation has encountered an issue.
Recommended Patterns:
To avoid imports getting stuck or failing, consider the following best practices:
- Limit the number of parallel imports to reduce contention for resources.
- Use the SqlPackage command-line utility for larger BACPAC files, as it may handle imports more efficiently than the Azure portal or PowerShell.
- Ensure that the target database is empty before starting the import to avoid conflicts with existing objects.
- Monitor the performance and resource utilization of the Azure SQL Database to ensure it is adequately provisioned for the workload.
- Utilize Business Critical or Premium tiers for better performance during import operations.

By following these recommendations, you may improve the reliability and performance of your BACPAC imports in Azure SQL Database.

AI-generated content may be incorrect. Read our transparency notes for more information.

Share via

Azure SQL BACPAC parallel imports stuck at 100% for extended periods – expected behavior?

1 additional answer

Your answer