Convert a SQL query from one database to another

Convert the SQL query below from {{source_dialect}} to {{target_dialect}}, so that it returns exactly the same rows and values on the new database and {{audience}} can switch over without a surprise in a report.

The query:
"""
{{query}}
"""

Table definitions or column types, where I have them:
"""
{{table_definitions}}
"""

What the query is used for: {{query_purpose}}
Database versions: {{versions}}

Give me:
1. A table of every difference you found, with the columns Original (quote the clause), What it does, Equivalent in {{target_dialect}}, Behavior to watch. Consider row limits (TOP, LIMIT, FETCH FIRST), date and time functions and intervals, string concatenation with NULLs, ISNULL, IFNULL and COALESCE, identifier quoting, boolean values, integer division, string aggregation, case sensitivity in comparisons, and implicit type casts.
2. The converted query in a code block, keeping my aliases, CTE names and layout, with a -- comment on each line whose behavior might differ.
3. Things to test before switching, as a numbered list of up to 8 checks, for example running both versions on the same data and comparing row counts and the sums of key columns, then testing NULLs, month ends, time zones and ties in ORDER BY.

Keep any text outside the table, the query and the list under 250 words.

Keep the logic identical. Do not optimize, restructure or rename anything unless {{target_dialect}} requires it, and mark every change it forces. A good conversion is one where the only differences between the two queries are the ones the table explains.

Watch for behavior that changes silently even when the query runs. For example, Oracle treats an empty string as NULL, SQL Server's DATEDIFF counts boundaries crossed rather than time elapsed, and MySQL may accept columns in SELECT that are neither grouped nor aggregated. Check each such case against the versions given.

If a function has no exact equivalent, give the closest one and add "-- CHECK:" with what may differ. If the result depends on a column's data type and the table definitions do not say, ask instead of assuming. If part of the result relies on a setting rather than syntax, such as the session time zone or the collation, say so.