Apple introduces Siri AI, a profoundly more capable and personal assistant powered by Apple Intelligence, with personal context, world knowledge, and onscreen awareness.

New App Store capabilities will give developers more flexibility to market their apps, acquire users, and manage subscriptions.

At Microsoft Build 2026, Azure App Service introduced a powerful set of updates designed to help organizations accelerate their journey into AI, without increasing complexity or cost. These innovations focus on one clear business outcome: enabling teams to build, deploy, and scale AI-powered applications and agents faster, more securely, and with greater operational efficiency.

 

 

A key highlight is the new Easy AI experience, which allows existing web apps to become AI-ready with no rearchitecting required. With capabilities like built-in Model Context Protocol (MCP), developers can instantly expose app functionality as agent-ready endpoints, enabling AI agents to interact with business logic securely and seamlessly. This dramatically reduces development time, allowing teams to move from idea to intelligent application in a fraction of the usual effort.

Security and compliance are also strengthened with the general availability of Isolated v4 for Azure App Service Environments, delivering improved performance for customers that need single-tenant isolation and strong data residency guarantees. For enterprises operating in regulated industries, this ensures AI applications meet strict governance requirements without sacrificing scalability or speed.

For modernization scenarios, Managed Instance on Azure App Service simplifies the migration of legacy applications, including those with OS-level dependencies. Faster restarts, enhanced diagnostics, and AI-assisted migration workflows help organizations modernize existing systems cost-effectively—avoiding expensive rewrites while unlocking AI capabilities. Recent updates include an AI-assisted approach to migrating legacy IIS applications using a multi-agent workflow powered by MCP. Managed Instance is supported on both Premium v4 and Isolated v4, laying the foundation for a modern compute infrastructure across the board.  

Operational efficiency is further enhanced through platform and CLI improvements designed for the “agent era.” From structured deployment diagnostics to optimized Python pipelines delivering faster deployments, these updates reduce friction and infrastructure overhead, lowering total cost of ownership. 

Together, these innovations position Azure App Service as a future-ready platform where businesses can rapidly build intelligent, agent-driven applications securely, efficiently, and at scale.

👉 Learn more in the full announcement: Deep dive into Azure App Service Build 2026 updates

Overview

This blog supplements the Migrate to Azure SQL documentation and tries to summarize the Microsoft first party ways to copy or migrate SQL Server databases from on‑premises environments to one of the flavours of SQL Server running in Azure. It is organized first by target platform (Azure SQL Database/Hyperscale, Azure SQL Managed Instance and Azure SQL Virtual Machine) and then by tool (for example Azure DMS, Managed Instance Link, Distributed Availability Groups, SqlPackage, and data copy utilities). For each tool, you’ll find supported targets, prerequisites, whether it can run online (continuous change replication) or requires offline downtime, and the common limitations that influence tool choice.

Azure SQL Target Platforms

• Azure SQL Database (including Hyperscale) – Fully managed by Microsoft running as Platform as a Service (PaaS), the service provides database scoped access with no visibility between databases on a logical server. Some SQL Server features are not available (i.e. backup/restore) so migrations need to use logical transfer or export/import of data.
• Azure SQL Managed Instance (MI) – Fully managed by Microsoft running as Platform as a Service (PaaS), the service provides SQL Server instance scoped access and near-full SQL Server surface area. MI supports specialized migration/replication options such as Managed Instance Link as well as backup/restore based (Log Replay Service (LRS)) approaches.
• Azure SQL Virtual Machine (SQL Server on Azure VM) – This option uses Azure Infrastructure as a Service (IaaS). You manage the OS (Windows or Linux) and SQL Server. Since you are installing the full box product of SQL Server, this target supports all native SQL Server features on that OS platform.

SQL Server everywhere else – For completeness, this includes SQL Server running on-premises, another VM, or other cloud providers. Tools such as SqlPackage, SmartBulkCopy, and SqlDBCopy can copy data to any SQL Server targets when connectivity between the servers is available.

Key Decision Factors

• Downtime tolerance: Do you need an online migration (continuous replication) with a brief cutover phase or is an offline data migration approach acceptable?
• Scope: One database, many databases, or full instance and feature usage (replication, CLR, agent jobs, cross database query, linked servers, SSIS, SSAS, SSRS etc.)?
• Size and throughput: The PaaS offerings have maximum databases sizes that vary across each service. Ensure your growth and performance requirements are met by the service you select. For migrations, large databases may favor backup/restore and log shipping type approaches (if available) over row-by-row copy.
• Network connectivity: VPN/ExpressRoute, firewall rules, and whether you can deploy a self-hosted Integration Runtime (IR) or agents.
• Schema compatibility: Azure SQL Database/Hyperscale has the most feature differences; MI and SQL VM are closer to SQL Server.
• Operational constraints: Change control on production, ability to install agents, and security requirements for credentials and encryption.
• Cost model: Some approaches incur ongoing compute costs (for example ADF pipeline runs, IRs, interim storage, or extra replicas during migration).

Migration Assessments (SSMS 22+ and Azure Arc)

Before moving an on‑premises SQL Server database to Azure SQL Database/Hyperscale or Azure SQL Managed Instance, you should run a migration assessment. Assessments identify feature incompatibilities, behavior differences, and configuration gaps that are easy to miss until late in the project (for example unsupported instance features in Azure SQL Database, cross-database dependencies, SQL Agent usage, CLR/extended procedures, or deprecated syntax). Running an assessment early reduces rework, helps you choose the right PaaS target (SQL DB vs. MI), and informs remediation tasks and sizing/performance planning.

Starting with SSMS 22+, assessment capabilities are built into the primary management tool many DBAs already use, making this a low-friction, repeatable step. The assessment results typically highlight blocking issues, warnings, and recommended changes, along with links to guidance so teams can prioritize remediation. Treat this as a gating step for PaaS migrations: run it for every candidate database, track findings as work items, and re-run after remediation and again before cutover.

For organizations managing multiple on‑premises and edge SQL Servers, Azure Arc-enabled SQL Server can extend Azure management capabilities to your existing estate. Arc can provide centralized inventory, performance monitoring, policy-based governance, and (where configured) automatic/recurring assessments so you can continuously measure readiness for Azure SQL PaaS.

• When to assess: Run an assessment as soon as a database is a candidate for Azure SQL DB/HS or MI, then re-run after fixes and before cutover.
• What you learn: Compatibility blockers, feature gaps, and refactoring guidance; inputs to target selection (SQL DB vs. MI) and to migration method choice.
• SSMS 22+ workflow: Use the built-in assessment experience to generate findings you can track and share with dev/app teams.
• Arc value-add: Enable Arc on on‑premises SQL Server to get centralized management, performance monitoring, and ongoing assessments across your estate.
• Planning integrations: Use assessment outputs to drive remediation backlogs and to inform Azure DMS-based migration projects (and associated connectivity/identity planning). For larger estates, Azure Migrate assessments can complement SSMS/Arc by providing discovery at scale plus readiness, sizing, and cost estimates for Azure SQL targets.

Tooling by Target (at a glance)

Note: Exact capabilities depend on SQL Server version/edition, database features in use, and target service limitations. Some approaches copy data only (table-level) while others move a full database or instance. Always validate feature compatibility and run a proof-of-concept with production-like data volumes.

Tool Deep Dives

Azure Migrate

What it is: Azure Migrate is the Azure hub for discovery, assessment, and migration planning across servers, apps, and data platforms. For SQL Server specifically, Azure Migrate can discover SQL instances and databases (via an appliance or other supported discovery methods) and produce Azure SQL assessments that estimate readiness, right-size recommendations, and cost for targets such as SQL Server on Azure VM, Azure SQL Managed Instance, and Azure SQL Database.

• Where it fits: Use Azure Migrate early to build an inventory, group related workloads, understand dependencies, and generate sizing/cost guidance before you choose an execution tool (for example Azure DMS, MI Link, backup/restore, replication, or table-level copy).
• Discovery approach: Typically uses an Azure Migrate appliance for agentless discovery of servers and workloads (including SQL Server instances/databases) and ongoing performance collection; assessment quality improves when you collect representative performance data over time.
• Assessment outputs: Readiness (ready/conditional/not ready), recommended target (SQL VM vs. MI vs. SQL DB where applicable), right-sized SKU/tier, and cost estimates based on configuration-only or performance-based sizing.
• Strengths: Works well at estate scale; provides a consistent, repeatable assessment methodology and helps prioritize migration waves and modernization candidates.
• Limitations / considerations: Azure Migrate is primarily a planning and assessment tool for SQL; the actual database move is typically executed with tools like Azure DMS, MI Link, backup/restore-based approaches, replication, or data copy utilities. Treat Azure Migrate recommendations as inputs—validate with workload-specific testing and SQL feature compatibility checks (for example SSMS assessment results) before cutover.

Azure Database Migration Service (Azure DMS)

What it is: A managed Azure service that orchestrates database migrations using guided workflows. Depending on the source/target combination, it can perform offline (one-time move) or online (continuous sync + cutover) migrations.

• Typical targets: Azure SQL Database/Hyperscale, Azure SQL Managed Instance, and SQL Server on Azure VM.
• Prerequisites: Network connectivity from DMS to source/target (often via VPN/ExpressRoute), required firewall openings, and appropriate permissions on both ends.
• Strengths: Guided experience, assessment integration, and support for multiple database moves with monitoring.
• Limitations / considerations: Feature support varies by scenario; some migrations are offline only. DMS orchestrates the process but still depends on connectivity and may have constraints around file placement for restore-based workflows. Plan for validation, cutover steps, and potential reconfiguration tasks (logins, jobs, SSIS, etc.) outside the database move itself.

Azure SQL Managed Instance Link (MI Link)

What it is: A managed replication capability designed specifically for migrating from SQL Server to Azure SQL Managed Instance with near-real-time synchronization and a controlled cutover experience.

• Supported targets: Azure SQL Managed Instance only.
• Online/offline: Online synchronization with a short cutover window.
• Prerequisites: Supported SQL Server versions/editions and configurations, network connectivity to the MI endpoint, and permissions to configure the link. (Review current product documentation for the exact supported matrix.)
• Strengths: Designed for MI migrations; reduces the need for custom change-capture pipelines; supports validation and coordinated cutover.
• Limitations: Not usable for Azure SQL VM or Azure SQL Database targets. Feature support and prerequisites are scenario-specific; plan for testing and for migrating instance-level objects and application connectivity during cutover.

Log Replay Service (LRS)

What it is: LRS is a managed Azure SQL Managed Instance migration service that restores native SQL Server full, differential, and log backups from Azure Blob Storage to keep a target database catching up until cutover. It is useful when you want a backup/restore-based migration pattern with more control over orchestration, or when other guided migration tooling cannot be used because of environment, network, or operational constraints.

• Supported targets: Azure SQL Managed Instance only.
• Online/offline: Commonly used as a minimal-downtime migration method in continuous mode by repeatedly restoring new log backups until cutover. It can also be used in an autocomplete pattern when the full backup chain is already available and you simply want the restore to run to completion.
• Prerequisites: Source databases must use the full recovery model, and you need a valid backup chain (full, optional differential, and log backups) accessible in Azure Blob Storage. Plan storage layout carefully—each database should use its own folder path—and validate backup integrity (CHECKSUM recommended) before migration.
• Strengths: Supports migrations from SQL Server hosted almost anywhere, including on-premises, VMs, and other clouds; supports differential backups; and gives you direct control through PowerShell, Azure CLI, or APIs for custom orchestration and hybrid migration patterns.
• Limitations / considerations: Databases being restored through LRS are not usable until migration finishes (no read-only access during restore). After cutover, the migration is final and can’t be resumed with additional differential backups. Review current service-tier and feature limitations—especially for Business Critical—and schedule maintenance windows and cutover steps carefully.

Azure Arc SQL Migration Tooling

What it is: Azure Arc-enabled SQL Server adds an Azure portal experience for continuous migration assessment and, for supported scenarios, integrated migration workflows. It helps you discover Arc-enabled SQL Server instances, evaluate readiness for Azure SQL targets, compare recommended destinations and sizing, and then move into guided migration execution without stitching together separate tools by hand.

• Where it fits: Best for organizations that have already Azure Arc-enabled their SQL Server estate and want a more centralized migration journey covering discovery, readiness, target recommendation, and guided execution from the Azure portal.
• Assessment outputs: Arc can continuously generate migration readiness results, identify risks and mitigation guidance, recommend a target type (Azure SQL Managed Instance, Azure SQL Database, or SQL Server on Azure VM), suggest sizing/service tier, and provide retail cost estimates to support migration planning.
• Supported migration direction: Arc-based SQL migration tooling is centered on Arc-enabled source SQL Server instances. Current portal experiences focus on integrated migration to Azure SQL targets, including Azure SQL Managed Instance, with expanding support for SQL Server on Azure VM scenarios.
• Strengths: Consolidates assessment and migration activities into one operational surface, reduces context switching, helps compare modernization-vs.-cost strategies, and keeps assessments refreshed on a schedule so you can track readiness over time.
• Limitations / considerations: Requires the source SQL Server to be enabled by Azure Arc, and some migration experiences are still scenario- or platform-specific. Treat Arc guidance as a planning and orchestration layer—validate the recommended target, chosen migration method, feature compatibility, and operational prerequisites with workload-specific testing before production cutover.

Transactional Replication

What it is: A SQL Server replication technology that continuously streams committed changes from a Publisher to one or more Subscribers via a Distributor. For migrations, it is commonly used to keep a target synchronized with minimal downtime, then cut over applications to the subscriber.

• Supported targets: SQL Server on Azure VM, Azure SQL Managed Instance, Azure SQL Database/Hyperscale, and SQL Server anywhere - subject to replication feature support and version compatibility.
• PaaS subscription model: When the subscriber is a PaaS target (Azure SQL Database or Azure SQL Managed Instance), you typically use a push subscription so that the on‑premises publisher/distributor (or an IaaS SQL Server acting as distributor) connects outbound to the PaaS subscriber.
• Distributor placement: You can host the Distributor on‑premises (common when outbound connectivity to Azure is allowed and you want to keep replication infrastructure local), or on a SQL Server on Azure VM (common when you want replication infrastructure closer to the cloud target, to simplify network paths, or to avoid routing large snapshot/distribution traffic across the WAN). In both cases, ensure the Distributor can reach the Publisher and can make outbound connections to the PaaS subscriber for push subscriptions.
• Online/offline: Online data movement after initialization; cutover requires a brief downtime window to quiesce writes, allow the subscriber to catch up, and switch application connections.
• Prerequisites: A configured Distributor, reliable network connectivity, and appropriate permissions. Articles generally need a primary key (or a defined unique row identifier) for updatable patterns; initialization uses a snapshot that must be delivered to the subscriber.
• Strengths: Proven low-latency replication for many OLTP workloads; supports one-to-many topologies; useful when you want to keep a cloud target warm for validation and phased cutover.
• Limitations: Operational overhead (monitoring agents, distribution database growth, troubleshooting latency). Not a full instance migration (logins, jobs, etc. are separate). Some schema changes require careful coordination and may force reinitialization. Large objects, high churn, or very large initial snapshots can increase time and storage requirements. Plan identity range management, constraints, and replication of DDL based on your workload and target.

Distributed Availability Groups (DAG)

What it is: A SQL Server feature that replicates databases between two separate Availability Groups. It can be used for migration by establishing asynchronous data movement to a secondary AG and then performing a controlled cutover.

• Supported targets: SQL Server only targets—commonly SQL Server on Azure VM. (Not applicable to Azure SQL Database or Managed Instance.)
• Online/offline: Online replication with a short cutover window; can provide very low data loss when configured appropriately.
• Prerequisites: Availability Groups and underlying clustering infrastructure (WSFC on Windows or Pacemaker on Linux), compatible SQL Server editions, and network connectivity between replicas.
• Strengths: Mature HA/DR technology with robust monitoring; suitable for larger databases and for keeping a warm secondary environment.
• Limitations: Higher complexity and operational overhead (clusters, AG configuration, certificates/endpoints). Not a lightweight option when change control or infrastructure constraints are tight.

BlobShipper Service (log shipping via Azure Blob Storage)

What it is: The BlobShipper application is a Windows service that automates SQL Server full and log backups to Azure Blob Storage and restores them to a target SQL Server (commonly on an Azure SQL VM). It is a backup-driven approach intended to minimize production changes while enabling low-downtime cutover.

• Supported targets: SQL Server on Azure VM (primary), and generally SQL Server-to-SQL Server scenarios where backup/restore is available.
• Online/offline: Online up to cutover (continuous log shipping), then a short downtime window for the final log backup/restore and application cutover.
• Prerequisites: Ability to take full + log backups, Azure Storage account access, and connectivity from the target to read backups from Blob Storage.
• Strengths: Minimal change to production beyond taking ownership of the backup/log chain; controlled file placement on the target; can optionally apply logs with a delay to provide a read-only fallback window.
• Limitations: Target must support restoring native SQL Server backups (therefore not Azure SQL Database). Log chain control means you typically stop other backup jobs for the migrated databases while the service runs.

Log Shipping (native SQL Server)

What it is: A built-in SQL Server feature that keeps a secondary database synchronized by repeatedly backing up transaction log backups on the primary, copying them to a secondary location, and restoring them on the secondary. For migrations to Azure, Log Shipping is commonly used from on‑premises SQL Server to SQL Server on Azure VM to achieve low downtime cutover.

• Supported targets: SQL Server only - including SQL Server on Azure VM. (Not applicable to Azure SQL Database or Azure SQL Managed Instance.)
• Online/offline: Online log restore cycles up to cutover; downtime is typically limited to the final log backup/restore and application connection switch.
• Prerequisites: The source database must be in full recovery model with a healthy log chain, and you need a mechanism to copy log backups from on‑premises to the Azure VM (file share, storage account, or other transfer path). Agent jobs run on both ends to schedule backup/copy/restore.
• Strengths: Simple, well-understood, and works with very large databases; provides a warm standby you can validate before cutover.
• Limitations: Asynchronous by design (some data loss is possible if you cut over before the last logs are applied). Requires ongoing management of backup files, schedules, and retention. You must coordinate other backup jobs so they don’t break the log chain and ensure you can meet RPO/RTO.
• Relationship to BlobShipper: BlobShipper automates a similar log-shipping pattern using Azure Blob Storage as the transfer medium and adds operational conveniences (for example, controlled restore timing and simplified blob-based transport).

Azure Data Factory (ADF) copy pipelines

What it is: A cloud data integration service that can copy data from on‑premises SQL Server to Azure data stores (including Azure SQL Database, Managed Instance, and SQL Server on Azure VM) using configurable pipelines.

• Prerequisites: For on‑premises sources you typically deploy a Self-hosted Integration Runtime (IR) in your network (or a connected network) to enable secure connectivity. You also configure linked services, datasets, and credentials.
• Online/offline: ADF copy itself is often offline for consistent point-in-time results, but you can implement incremental patterns (for example, watermark columns, Change Tracking/CDC-based extracts, or time-window batching) to reduce cutover downtime. Our team has a custom tool to make this process much easier - if you are interested, reach out to us.
• Strengths: Works across many sources/targets; good for selective table moves, transformations, and repeatable pipeline operations.
• Limitations / considerations: Throughput is influenced by IR sizing, source/target performance, network bandwidth, and parallelism settings. Pipeline executions incur costs (activity runs, data movement, and IR compute if you use Azure-hosted resources). You are responsible for schema management and for handling constraints/ordering, as well as for designing incremental logic and validation.

SSIS (SQL Server Integration Services)

What it is: A data integration and ETL technology in SQL Server that can extract data from an on‑premises SQL Server and load it into many targets. SSIS is often used as an offline copy mechanism for selected tables (or full database data via multiple packages) when you already have SSIS skills/infrastructure or when you need transformations during the move.

• Supported targets: SQL Server on Azure VM, Azure SQL Managed Instance, Azure SQL Database/Hyperscale, and many other destinations via connectors/drivers.
• Online/offline: Most SSIS-driven copies are offline point-in-time loads. Incremental loads are possible but require package design (watermarks, CDC/CT patterns, staging, and merge logic).
• Prerequisites: An execution environment for SSIS packages (for example SQL Server Integration Services on-prem, or an Azure-hosted SSIS runtime where applicable), connectivity from the runtime to source and target, and appropriate drivers/connectors and credentials.
• Strengths: Mature tooling, rich transformation support, and strong control over batching, error handling, and staging.
• Limitations / considerations: Package development and operations can be complex at scale. Performance depends on runtime sizing and network throughput. Like other table-level copy approaches, SSIS does not automatically migrate schema/instance objects unless you build that into the process. For cloud-first pipelines, ADF may be preferred for managed scheduling/monitoring, but SSIS remains a solid choice when you already have packages and patterns.

SqlDBCopy (offline copy and Change Tracking–based incremental copy)

What it is: SqlDBCopy is a utility that can copy tables between SQL Server endpoints either as a one-time offline operation or incrementally by leveraging SQL Server Change Tracking to move only changed rows.

• Supported targets: SQL Server, Azure SQL VM, Azure SQL Managed Instance, and Azure SQL Database (depending on connectivity).
• Offline mode: Copies a static snapshot of data; best when you can stop writes or when the data set is reference/static.
• Incremental mode (Change Tracking): Can continuously or periodically apply changes for tables where Change Tracking is enabled and where tables have a primary key. This enables lower-downtime migration patterns for selected tables.
• Prerequisites: Target schema and keys must exist; Change Tracking must be enabled on the source database and tables used for incremental copy; plan retention/cleanup so changes aren’t lost before they’re applied.
• Limitations: Change Tracking does not capture all DDL changes—schema evolution must be managed separately. Tables without primary keys are not suitable for Change Tracking–based incremental copy. Large change volumes may require tuning batch sizes and scheduling to keep up.

SmartBulkCopy (table-level bulk copy utility)

What it is: A table-level bulk copy approach for moving data between SQL Server-compatible endpoints using high-throughput bulk operations. It is useful when you want to copy selected tables (not a whole database) or when backup/restore-based methods aren’t available.

• Supported targets: SQL Server, Azure SQL VM, Azure SQL Managed Instance, and Azure SQL Database (connectivity and permissions permitting).
• Online/offline: Commonly offline for consistent results unless you implement your own change capture and replay pattern.
• Prerequisites: The target schema must already exist (tables, indexes as needed). You also need appropriate permissions for bulk insert/copy and sufficient target throughput.
• Strengths: Fast for large table copies; you can scope to a subset of tables and parallelize work.
• Limitations: Does not automatically migrate schema, users/logins, or instance-level objects. Maintaining referential integrity and identity values may require careful ordering and settings. If you need minimal downtime, you must add a separate mechanism to capture and apply ongoing changes.

SqlPackage (BACPAC export/import and DAC deployment)

What it is: A command-line utility used to export a database to a BACPAC (schema + data) and import it into a target, or to publish schema changes using a DACPAC. It is commonly used to move databases to Azure SQL Database or to create a portable logical copy for SQL Server targets.

• Supported targets: Azure SQL Database/Hyperscale, Azure SQL Managed Instance, and SQL Server (including SQL Server on Azure VM) depending on options used.
• Online/offline: Typically offline for a full data move—export from the source represents a point-in-time snapshot. To avoid data drift, you usually stop writes or accept a reconciliation step.
• Strengths: Simple packaging model; good for smaller databases, dev/test cloning, and scenarios where logical export is preferred over backup/restore.
• Limitations: Can be slow for large databases (export/import is largely single-threaded and sensitive to network and target performance). Requires enough local or intermediate storage for the BACPAC. It is not a minimal downtime option. Some objects/features may not be supported on the target platform (especially Azure SQL Database), and you may need to resolve compatibility issues before import.

Security Considerations

Security planning is a critical part of any on‑premises to cloud migration. In addition to securing network paths (VPN/ExpressRoute, firewall rules, Private Link where applicable) and protecting credentials used by migration tools, you should plan for how identity and access will work on the target platform after cutover.

For Azure SQL PaaS targets (Azure SQL Database and Azure SQL Managed Instance), many organizations choose to standardize on Microsoft Entra ID (formerly Azure AD) authentication. This can require translating existing on‑premises Active Directory logins and database users into Entra-based identities and groups and then remapping database permissions, so applications, users and administrators retain the correct access.

• Inventory and map identities: List server logins, database users, role memberships, and explicit GRANT/DENY permissions on the source. Decide which should become Entra users vs. Entra groups (recommended for manageability) and confirm synchronization/hybrid identity requirements with your identity team.
• MoveLogins: Use this PowerShell script to help script existing logins, users, roles and permissions and use the AD lookup function to map the AD logins to Entra UPNs. The script can then be reviewed and applied to the target server. (Contact our team if you need this script).
• ScriptLoginsAndUsers: Use this utility to script out Entra and SQL logins, users, roles and permission so you can recreate the security structure on the target. This is especially helpful when you are moving PaaS databases from one Tenant to another.

Dev/Test with Obfuscated Data

Many migration projects benefit from creating a development or test copy of production data to validate application behavior, performance, and migration tooling. When production contains sensitive information (PII/PHI/PCI or confidential business data), you may need to obfuscate that data before it can be used outside tightly controlled production environments.

• Typical use cases: Building realistic dev/test environments, rehearsing migrations and cutovers, enabling troubleshooting by broader teams, and sharing data with partners/vendors where raw production data is not permitted.
• Obfuscate tool: Use the Obfuscate utility to transform sensitive columns (for example names, emails, phone numbers, identifiers, free-text fields) into non-sensitive substitutes while preserving useful characteristics (such as format, referential integrity, and distribution patterns) as required by testing scenarios.
• Plan the masking strategy: Define which tables/columns are sensitive, which must remain consistent across tables (keys/lookup values), and what level of realism is needed (synthetic values vs. deterministic masking). Document the rules so results are repeatable for refreshes.
• Sequence and constraints: Obfuscation often needs to run in a controlled order to preserve foreign keys and uniqueness constraints. Consider disabling/re-enabling constraints or using staging tables if your process requires it.
• Security hygiene: Treat the obfuscation process and outputs as sensitive until validated. Restrict access to the obfuscation configuration, logs, and any intermediate exports that may contain raw values.
• Verify effectiveness: Add validation steps to confirm that sensitive values are masked, that key relationships still hold, and that the application behaves correctly with the obfuscated dataset.

Data validation

Regardless of which copy or migration mechanism you choose, you may want to plan for data validation immediately before cutover. Validation reduces the risk of silent data drift and missed objects, and it helps you quantify exactly what is left to reconcile before switching applications to the new target.

Database Compare Utility

The Database Compare Utility can validate that source and target have the same schema objects and contain identical data with the option to generate a change script to align the target to the source. It supports comparisons between other heterogeneous database platforms, but it fully supports any SQL Server to SQL Server comparison assuming there is connectivity between the two. The latest version includes a GUI or it can also be executed in batch/console mode. The tool is multi-threaded (configurable parallelism) but can generate significant load on databases and the network. It can do row count verification, table hash verification or row by row verification. For tables with primary keys, it can also generate change scripts. Advanced scenarios can be driven by an Excel input that maps different schema/table/column names, supplies filters to split large tables into parallel tasks, and defines alternate keys or column exclusions.

CPQR Utility

The Compare Query Performance and Result sets (CPQR) utility’s purpose is to compare the execution times and result sets (i.e. every column value for every row) generated by running two queries against two different data sources; one any OLEDB data source and the other a SQL Server data source. Note that although the performance of queries is measured, since multiple queries are being run by the application concurrently, the performance may be affected by other queries that are being run in parallel (to mitigate this you can turn off parallelism).

How to choose an approach

• If your target is Azure SQL VM and you need minimal downtime: prefer log/replication approaches such as BlobShipper (log shipping), Transactional Replication, or Distributed Availability Groups, depending on how much infrastructure and change you can accept.
• If your target is Azure SQL Managed Instance and you need minimal downtime: start with Managed Instance Link (when supported) or DMS online migrations. Transactional Replication (push subscription) can also work for many patterns when you can manage distributor operations and table/article constraints; use table-level incremental copy (SqlDBCopy/ADF patterns) only when a full database move isn’t feasible.
• If your target is Azure SQL Database/Hyperscale: prioritize compatibility assessment early. For smaller databases, SqlPackage (BACPAC) may be acceptable. For larger or lower-downtime needs, consider DMS online (supported scenarios), Transactional Replication (push subscription) for suitable table/article sets, or ADF incremental patterns.
• If you only need certain tables or you’re consolidating data: table-level tools (ADF, SmartBulkCopy, SqlDBCopy) can be simpler than full database migrations—just plan schema creation and data consistency.
• Always plan the non-data work: logins/users, SQL Agent jobs, maintenance plans, SSIS/SSRS, linked servers, certificates/keys, and application connection changes often dominate the overall cutover effort.

Conclusion

There is no single best migration method for every SQL Server workload. The right choice depends primarily on the Azure target, downtime tolerance, and how closely you need to preserve SQL Server instance features. Use the matrix above to narrow options by target, then validate prerequisites and limitations in a proof-of-concept. For production migrations, include performance testing, data validation, cutover rehearsal, and a rollback plan appropriate to your business risk.

Feedback and suggestions

If you have feedback or suggestions for improving this data migration asset, please contact the Azure Databases SQL Customer Success Engineering (Ninja) Team (datasqlninja@microsoft.com).

Thank you for your support!

The Apple Developer Program License Agreement and App Review Guidelines have been revised to support new features, updated policies, and to provide clarification. Please review the changes below and sign in to your account to accept the updated terms.

Apple Developer Program License Agreement

• Sections 3.1, 14.8: Specified requirements for providing information and responding to questions about developer identity, including in the context of export compliance.
• Definitions, Section 3.3.3(N): Clarified requirements for use of the Sensitive Content Analysis framework.
• Definitions, Section 3.3.3(Q): Specified requirements for use of the Suggested Actions API.
• Definitions, Section 3.3.3(R): Specified requirements for use of the Trust Insights framework.
• Section 3.3.4(A): Specified terms regarding end users’ ability to modify content for personal accessibility purposes.
• Definitions, Section 3.3.7(L): Specified requirements for use of the Media Device Extension framework.
• Definitions, Section 3.3.7(M): Specified requirements for use of the Spatial Audio Extension APIs.
• Definitions, Section 3.3.9(E): Specified requirements for use of the Customer Engagement APIs.
• Section 3.2(h): Updated terms for use of and access to Apple models.
• Section 3.3.11: Grouped AI and machine learning technologies under new subsection.
• Section 3.3.11(A): Updated requirements for use of Foundation Models framework.
• Section 6.7: Specified that analytics may additionally be provided via Xcode and/or App Store Connect API.
• Section 7.9: Specified requirements on providing information regarding apps in App Store Connect, and protection of end users who are minors.
• Section 10: Clarified terms regarding indemnification.
• Attachment 2, Section 1.1: Clarified requirements for use of the In-App Purchase API.
• Attachment 5, Section 3.3: Updated privacy requirements for use of Passes.
• Attachment 11, Section 4: Updated the name of identity guidelines for EnergyKit.

App Review Guidelines

• Introduction: revised kid and teen safety guidance.
• 1.2: new paragraph clarifies developer responsibilities for content that violates this guideline.
• 4.3(a): clarifies the basis for the guideline and adds an example.
• 4.3(b): clarifies the basis for the guideline and adds examples.
• 4.5.3: clarifies that Live Activities may not be used to spam, phish, or send unsolicited messages to customers.

---

Translations of the updated agreement will be available on the Apple Developer website within one month.