Import large collections

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

For databases that the data migration tool warns are too big, a different data packaging approach is required to migrate to Azure DevOps Services. If you're unsure whether your collection exceeds the size threshold, you should run a data migration tool validation on the collection. The validation lets you know whether you need to use the SQL Azure VM method for import.

Determine if you can reduce the collection size

Before you proceed, we recommend checking to see whether your old data can be cleaned up. Over time, collections can build up very large volumes of data. This is a natural part of the DevOps process, but you might find that you don't need to retain all of the data. Some common examples of no longer relevant data are older workspaces and build results.

Cleaning older, no-longer-relevant artifacts could remove a lot more space than you might expect, and it could determine whether you use the DACPAC import method or a SQL Azure VM.


After you've deleted older data, it can't be recovered unless you restore an older backup of the collection.

If you're under the DACPAC threshold, follow the instructions to generate a DACPAC for import. If you still can't get the database under the DACPAC threshold, you need to set up a SQL Azure VM to import to Azure DevOps Services.

Set up a SQL Azure VM to import to Azure DevOps Services

Let's walk through how to accomplish this. At a high level, you'll:

  • Set up a SQL Azure VM.
  • (Optional) Restrict access to Azure DevOps Services IPs only.
  • Configure IP firewall exceptions.
  • Restore your database on the VM.
  • Configure your collection for import.
  • Configure the import specification file to target the VM

Set up a SQL Azure VM

You can set up a SQL Azure VM from the Azure portal with just a few clicks. To learn how, see Use the Azure portal to provision a Windows virtual machine with SQL Server.

Azure DevOps Services is available in several Azure regions across the globe.


To ensure that the import starts successfully, it's critical to place your data in the correct region. If you set up your SQL Azure VM in a location other than the regions listed in the following table, the import will fail to start.

If you're using this import method, determine where to create your SQL Azure VM by referring to the following table. Creating your VM in a region other than those in this list is not supported for running an import.

Desired import region SQL Azure VM region
Central United States Central US
Western Europe West Europe
Australia East Australia East
Brazil South Brazil South
South India South India
Central Canada Canada Central
Asia Pacific Southeast Asia (Singapore)
UK South UK South

Although Azure DevOps Services is available in multiple regions in the US, only the Central United States region accepts new organizations. Companies can't import their data into other US Azure regions at this time.


DACPAC customers should consult the region table in the "Step 3: Upload the DACPAC file" section. The preceding guidelines are for SQL Azure VMs only.

Here are a few more SQL Azure VM configurations that we recommend:

  • Use D Series VMs, because they're optimized for database operations.
  • Ensure that the D Series VMs have at least 28 gigabytes (GB) of RAM. For imports, we recommend Azure D12 V2 VM sizes.
  • Configure the SQL temporary database to use a drive other than drive C. Ideally the drive should have ample free space; at least equivalent to your database's largest table.
  • If your source database is still over 1 terabyte (TB) after you've reduced its size, you need to attach additional 1-TB disks and combine them into a single partition to restore your database on the VM.
  • If your collection databases are over 1 TB in size, consider using an SSD for both the temporary database and collection database. Also, consider using larger VMs with 16 virtual CPUs (vCPUs) and 128 GB of RAM.
  • You need to have a public facing IP address for the service to reach this machine.

(Optional) Restrict access to Azure DevOps Services IPs only

We highly recommend that you restrict access to your VM to only IPs from Azure DevOps Services. You do this by allowing connections only from the set of Azure DevOps Services IPs that are involved in the collection database import process. The IPs that need to be granted access to your collection database depend on the region you're importing into. The following tables can help you identify the correct IPs. The only port that's required to be opened to connections is the standard SQL connection port 1433.

First, no matter what Azure DevOps Services region you import into, you must grant the following IP addresses access to your collection database.


In the following table, the two IP addresses listed with x.x.x.0/23 indicate a range. Allow the entire /23 range. For example, if you're importing into the Central United States region, allow the /23 range for For IP addresses with x.x.x.0/24, allow the /24 range.

Service IP address
Azure DevOps Services Identity Service,

Next, grant access to the Regional Identity Service. You need to grant an exception for the data migration tool instance only in the region that you're importing into.

Service IP address
Regional Identity Service - Central United States,,,,,,,,,,,
Regional Identity Service - West Europe,,,,,,,,,,,
Regional Identity Service - Australia East,,,,,
Regional Identity Service - Brazil South,,,,
Regional Identity Service - India South,,,,
Regional Identity Service - Canada Central,,
Regional Identity Service - Asia Pacific (Singapore)
Regional Identity Service - UK South,

Next, grant access to the data migration tool for Azure DevOps itself. You need to grant an exception for the data migration tool instance only in the region that you're importing into.
Service IP address
Data migration tool - Central United States,,,
Data migration tool - West Europe,,,,,,
Data migration tool - Australia East,,
Data migration tool - Brazil South,
Data migration tool - India South,
Data migration tool - Canada Central,,
Data migration tool - Asia Pacific (Singapore)
Data migration tool - UK South,,

Next, grant Azure DevOps Services access. Again, you need to grant an exception for the Azure DevOps Services instance only in the region that you're importing into.
Service IP address
Azure DevOps Services - Central United States,,,,,,
Azure DevOps Services - West Europe,,,,,,,,,
Azure DevOps Services - Australia East,,,,
Azure DevOps Services - Brazil South,,,
Azure DevOps Services - India South,,,
Azure DevOps Services - Canada Central,
Azure DevOps Services - Asia Pacific (Singapore)
Azure DevOps Services - UK South,,,

Next, grant Azure Pipelines Releases service access. You need to grant an exception for the Azure DevOps Services instance only in the region that you're importing into.

Release Management IPs

Service IP address
Releases service - United States,,,,,
Releases service - West Europe,
Releases service - Australia East,
Releases service - Brazil South,
Releases service - India South,
Releases service - Canada Central,
Releases service - Asia Pacific (Singapore)
Releases service - UK South

Next, grant Azure Artifacts access. Again, you need to grant an exception for the Azure DevOps Services instance only in the region that you're importing into.

Azure Artifacts IPs

Add exceptions for all three services that make up Azure Artifacts.

Service IP address
Azure Artifacts - United States,,,,,,,,
Azure Artifacts - West Europe,
Azure Artifacts - Australia East,,
Azure Artifacts - Brazil South,
Azure Artifacts - India South,
Azure Artifacts - Canada Central,,,
Azure Artifacts - Asia Pacific (Singapore)
Azure Artifacts - UK South

Service IP address
Azure Artifacts Feed - United States,,,,,
Azure Artifacts Feed - West Europe,
Azure Artifacts Feed - Australia East,
Azure Artifacts Feed - Brazil South,
Azure Artifacts Feed - India South,
Azure Artifacts Feed - Canada Central,
Azure Artifacts Feed - Asia Pacific (Singapore)
Azure Artifacts Feed - UK South

Service IP address
Azure Artifacts Blob - United States,,,,
Azure Artifacts Blob - West Europe
Azure Artifacts Blob - Australia East,,
Azure Artifacts Blob - Brazil South
Azure Artifacts Blob - India South
Azure Artifacts Blob - Canada Central,,,
Azure Artifacts Blob - Asia Pacific (Singapore)
Azure Artifacts Blob - UK South,

Test Plans IPs

Add exceptions for Test Plans IP addresses only in the region you're migrating into.

Service IP address
Test Plans - United States,,,,,
Test Plans - West Europe
Test Plans - Australia East
Test Plans - Brazil South
Test Plans - India South
Test Plans - Canada Central
Test Plans - Asia Pacific (Singapore)
Test Plans - UK South

Analytics IPs (Azure DevOps Server 2019 or later only)

If you included preview features with your import, add an exception for the analytics IPs only in your target import region.

Service IP address
Analytics service - United States,,,,,,
Analytics service - West Europe,,
Analytics service - Australia East
Analytics service - Brazil South
Analytics service - India South
Analytics service - Canada Central
Analytics service - Asia Pacific (Singapore)
Analytics service - UK South


Alternatively, you can also use Service Tags in place of explicit IP ranges. Azure Service Tags are a convenient way for customers to manage their networking configuration to allow traffic from specific Azure services. Customers can easily allow access by adding the tag name azuredevops to their network security groups or firewalls either through the portal or programmatically.

Configure IP firewall exceptions

Granting exceptions for the necessary IPs is handled at the Azure networking layer for your SQL Azure VM. To get started, go to your SQL Azure VM in the Azure portal. In Settings, select Networking. This will take you to the network interface page for your SQL Azure VM. The data migration tool requires the Azure DevOps Services IPs to be configured for inbound connections only on port 1433. You can grant exceptions for the IPs by selecting Add inbound port rule in the networking settings.

Screenshot of the "Add inbound port rule" button on your SQL Azure VM network interface page.

On the Add inbound security rule pane, select Advanced to configure an inbound port rule for a specific IP.

Screenshot of the "Advanced" button on the "Add inbound security rule" pane.

In the Source drop-down list, select IP Addresses, enter an IP address that needs to be granted an exception, set the Destination port range to 1433 and, in the Name box, enter a name that best describes the exception you're configuring.

Depending on other inbound port rules that have been configured, you might need to change the default priority for the Azure DevOps Services exceptions so they don't get ignored. For example, if you have a "deny on all inbound connections to 1433" rule with a higher priority than your Azure DevOps Services exceptions, the data migration tool might be unable to make a successful connection to your database.

Screenshot of a completed inbound port rule configuration.

Repeat adding inbound port rules until all necessary Azure DevOps Services IPs have been granted an exception. Missing one IP could result in your import failing to start.

Restore your database on the VM

After you set up and configure an Azure VM, you need to take your detached backup from your Azure DevOps Server instance to your Azure VM. Azure has several documented methods for how to accomplish this task. The collection database needs to be restored on your SQL instance and doesn't require Azure DevOps Server to be installed on the VM.

Configure your collection for import

After your collection database has been restored on your Azure VM, configure a SQL login to allow Azure DevOps Services to connect to the database to import the data. This login allows only read access to a single database.

To start, open SQL Server Management Studio on the VM, and then open a new query window against the database to be imported.

Set the database's recovery to simple:


Create a SQL login for the database, and assign that login the 'TFSEXECROLE':

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Following our Fabrikam example, the two SQL commands would look like the following:


USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'


Be sure to enable SQL Server and Windows authentication mode in SQL Server Management Studio on the VM. If you don't enable authentication mode, the import will fail.

Configure the import specification file to target the VM

Update the import specification file to include information about how to connect to the SQL Server instance. Open your import specification file and make the following updates:

  1. Remove the DACPAC parameter from the source files object.

    The import specification before the change is shown in the following code:

    Screenshot of the import specification before the change.

    The import specification after the change is shown in the following code:

    Screenshot of the import specification after the change.

  2. Fill out the required parameters and add the following properties object within your source object in the specification file.

        "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 

Following the Fabrikam example, after you apply the changes, the import specification would look like the following:

Screenshot of the import specification referencing a SQL Azure VM.

Your import specification is now configured to use a SQL Azure VM for import. Proceed with the rest of preparation steps to import to Azure DevOps Services. After the import has finished, be sure to delete the SQL login or rotate the password. Microsoft does not retain the login information after the import has finished.