Clarify Azure SQL Database migration and validation steps

articles/dms/faq.yml

@@ -66,12 +66,10 @@ sections:
 
           * Online migration: During online migration to SQL Server on Azure VM and Azure SQL Managed Instance targets, downtime starts once  you initiate the migration cutover along with stopping the application. DMS restores all the backup files to the target, as long as the latest backup file/s from source have been transferred to SMB network storage or to Azure blob container (as per the migration configuration). After you press the cutover button, DMS shows the count for pending backup file/s (if any) which are present on the SMB network storage or Azure blob container and yet to be applied/restore on target. If the backup is taken with the CHECKSUM option, the DMS restore operation automatically performs the validation. In the absence of checksum, the integrity of the backup is explicitly checked before restoring. This ensures that the restore file is identical to the backup file and hence have the same data. You can verify all the backup files, including the last backup file name from source, with the backup file applied/restore on target shown on DMS migration monitoring page and validate their respective checksum.
 
-          For Azure SQL Database targets, DMS does logical migration in the case of Azure SQL Database. That is, it copies the data from the source SQL database's tables and writes it to the target Azure SQL database's tables. As DMS only supports offline migration to Azure SQL Database, application downtime starts when the migration starts. You can monitor and validate the number of rows read (from source database table) and copied (written to the target Azure SQL database table) from the migration monitoring page. As additional confirmation, you can run the following Transact-SQL to get the checksum both at source and destination databases and validate the source and restore data being identical.
+          For Azure SQL Database targets, DMS does logical migration in the case of Azure SQL Database. That is, it copies the data from the source SQL database's tables and writes it to the target Azure SQL database's tables. As DMS only supports offline migration to Azure SQL Database, application downtime starts when the migration starts. You can monitor and validate the number of rows read (from source database table) and copied (written to the target Azure SQL database table) from the migration monitoring page. As additional confirmation, you can use the following options to get the checksum both at source and destination databases and validate the source and restore data being identical.
 
-          `SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>;`
-
-          > [!NOTE]
-          > As long as no application is writing to source or target database, you can also use tools like [Database Comparison tool](https://techcommunity.microsoft.com/t5/modernization-best-practices-and/database-comparison-tool/ba-p/3249580) for data comparison.
+          For basic and fast validation: `SELECT CHECKSUM_AGG(CHECKSUM(*)) FROM <table_name>;`
+          For detailed validation: You can also use tools like [Database Comparison tool](https://techcommunity.microsoft.com/t5/modernization-best-practices-and/database-comparison-tool/ba-p/3249580) for data comparison.
 
   - name: Security
     questions: