Migrate an on-premises enterprise geodatabase in SQL Server to Azure SQL Database

Summary

Enterprise geodatabases, also known as multiuser geodatabases, are stored in a relational database such as Oracle, Microsoft SQL Server, IBM Db2, IBM Informix, PostgreSQL, or SAP HANA.

In some cases, you can migrate your data from an on-premises relational database to a database-as-a-service offering. This article provides some considerations to plan for when migrating Microsoft SQL Server databases to an Azure SQL Database or Azure SQL Managed Instance. As with any data migration project, the most important stage is developing a plan for conducting the migration. This is an iterative process and new factors and information may arise that impact the state of the plan. 

An enterprise geodatabase at its core, is a series of standard database tables, column types, indexes, and other database objects. Enterprise geodatabase integrity and behavior are defined by the system tables, procedures and functions that are created when running either the Create Enterprise Geodatabase or Enable Enterprise Geodatabase geoprocessing tools or a Python script.

Procedure

Microsoft Azure SQL Database or Microsoft Azure Managed Instance are both currently supported for use with ArcGIS. Microsoft has provided multiple options for migrating from an on-premises SQL Server database to each of these database-as-a-service cloud implementations. Below are some helpful links for this migration process:

• SQL Server database migration to Azure SQL Database
• SQL Server instance migration to Azure SQL Managed Instance

These and other Microsoft resources should be included in your planning phase when migrating a SQL Server database that has been enabled with enterprise geodatabase functionality.

Prior to using the database migration tools, ensure that your enterprise geodatabase version is at 10.6 release or later. Once your database has been migrated into the cloud, an additional step must be completed to begin successfully using the enterprise geodatabase with ArcGIS client applications. When enterprise geodatabases are created or enabled directly in Azure SQL Databases or Managed Instances, the system stored procedures and functions have some differences from enterprise geodatabases created in SQL Server on-premises. These differences can lead to connection and display issues unless the procedures are updated after migrating an on-premises geodatabase into Azure. Migrating will not automatically update these stored procedures. 

After the database has been migrated into Azure, you must connect to the enterprise geodatabase using an ArcGIS client and upgrade the geodatabase. To perform the upgrade, use the Upgrade Geodatabase geoprocessing tool. This tool updates the stored procedures and functions even if you are not actually upgrading the release of the geodatabase. For example, if migrating an on-premises ArcGIS 10.8.1 enterprise geodatabase, you can use ArcGIS 10.8.1 to update the system stored procedures of the geodatabase once it exists in Azure SQL Database.

It is important to plan for this migration as you would for any migration of an enterprise geodatabase. ArcGIS layers, maps, and projects that reference data in the enterprise geodatabase prior to migrating must have their data sources reset after migrating the enterprise geodatabase. This also means that any published ArcGIS Server services that referenced the data must be republished to reflect the new data source.

Note: 
The ArcGIS 10.8.1 release has a fix that resolves a limitation that prevented use of non-default collations as described in BUG-000129828. Upgrading geodatabases that exist in the Azure SQL environment were also affected by this bug. This fix has been released as a patch for ArcGIS 10.7.1 and the link for this patch can be found in the Related Information section below.