DORA Exit Planning for Azure SQL Database: Building a Regulatory-Ready Blueprint

Under the EU Digital Operational Resilience Act (DORA), financial entities face heightened requirements for ICT risk management, third-party oversight, and crucially, exit planning and substitutability. When a customer recently requested formal advisory support from Microsoft regarding DORA compliance for Azure SQL Database workloads, it highlighted a growing need for structured exit planning guidance. This post distills that real-world support thread into practical, generalized guidance for building DORA-ready exit strategies.

Microsoft's DORA Resources: Your Regulatory Foundation

A critical component of any DORA exit plan is leveraging Microsoft's formal compliance resources. Microsoft publishes comprehensive DORA-related guidance through the Microsoft Trust Center, including a dedicated DORA compliance hub designed specifically for financial institutions. The Service Trust Portal provides additional compliance documentation for supervisory and audit processes.

For customers navigating DORA requirements, Microsoft Learn offers an overview of DORA scope and key considerations. The practical approach is to align your regulatory narrative with specific questions from your regulator, using Trust Center and Service Trust Portal materials as the "Microsoft-published" backbone, then supplementing with your customer-owned exit runbooks and test evidence.

Data Ownership and Portability: The Foundation of Exit Planning

Central to any exit strategy is understanding that Azure SQL Database is built on the SQL Server engine, and customers retain ownership of their data. The service supports portability through SQL Server-compatible schemas, T-SQL, and documented export/restore mechanisms, reducing dependency on proprietary formats.

For DORA compliance, frame "reversibility" as standards-based data and schema portability using SQL/T-SQL plus documented export/import capabilities. This standards-based approach is exactly the type of substitutability narrative regulators want to see.

Building Your Exit Strategy: Supported Capabilities

The support response outlined a high-level exit approach using documented, supported capabilities:

• Exporting database schema and data using SQL Server-compatible formats
• Restoring or importing into an on-premises SQL Server environment with functional equivalence
• Maintaining security controls (authentication, encryption in transit/at rest, integrity protections) during transition
• Validating restored data and application functionality as part of exit testing

BACPAC: Your Portability Evidence Artifact

One concrete, Microsoft-documented portability method is exporting to a BACPAC file (containing schema and data), which can later be imported into Azure SQL Database, Azure SQL Managed Instance, or SQL Server. According to Microsoft documentation, BACPAC files can be stored in Azure Blob storage or local storage.

For transactional consistency, ensure no write activity during export or export from a transactionally consistent copy. Note that blob-storage exports have a maximum BACPAC size of 200 GB; larger exports should use local storage with SqlPackage. Importantly, BACPAC is not intended as a backup/restore mechanism—Azure SQL has built-in automated backups.

DORA relevance: BACPAC serves as strong "portability evidence" because Microsoft explicitly positions it for "archiving" or "moving to another platform," including SQL Server.

Large Database Considerations: Beyond One-Click Export

The support thread specifically addressed "large database" scenarios, noting that Microsoft documentation describes high-level migration patterns such as offline export/import and staged validation for large databases. If your database exceeds typical BACPAC constraints (e.g., 200 GB blob export limit), your exit plan should explicitly describe:

• A staged approach (e.g., dry-run validation environment, phased cutover planning)
• Capacity planning (network bandwidth, validation windows)
• Testing cadence that produces regulator-friendly evidence

The advisory emphasized that customers should plan for sufficient time and capacity for transfer and validation, especially for large databases.

Customer Responsibilities Under DORA

A key statement from the support advisory bears repeating: Microsoft provides the technical capabilities enabling data portability and exit, but customers remain responsible for defining, documenting, testing, and periodically validating exit procedures—including planning timelines, allocating sufficient capacity, executing test exits, and maintaining evidence for regulatory review.

This aligns with DORA's intent and Microsoft's broader guidance: DORA requires operational resilience outcomes, and organizations must integrate cloud capabilities into their governance and controls.

DORA-Ready Exit Plan Checklist

Below is a general checklist you can adapt to structure your exit plan documentation and evidence pack:

Scope & Dependencies

• Identify Azure SQL Database workloads, dependent applications, and data flows to be included
• (Customer-owned documentation and evidence)

Portability Mechanism(s)

• Reference documented portability options such as schema+data export mechanisms (e.g., BACPAC) where applicable

Security Controls During Transition

• Document how auth and encryption controls are maintained during transfer and restoration

Validation Plan

• Define how you will validate data integrity and application functionality in the target environment

Scale Planning (Large DBs)

• Document transfer capacity planning, timelines, and staged validation where needed

Evidence & Audit Trail

• Store test outputs, run logs, and references to Microsoft Trust Center/Service Trust Portal materials used in submissions

From the support request's formal advisory perspective, the message is consistent: Azure SQL Database supports data portability and exit planning via SQL Server-compatible design and documented export/import mechanisms; Microsoft provides DORA-oriented compliance materials via the Trust Center and Service Trust Portal; and customers should own the exit runbook, testing, and evidence required for regulatory review.

Remember that while this guidance provides a framework, always align with your compliance team and regulators, as requirements may vary by jurisdiction and specific regulatory interpretation.