Platform migrations usually underestimate the SQL. Not the number of queries. The meaning hidden inside dialect behavior.

SQL drift is migration debt

SQLGlot documentation describes dialects and SQL transpilation across different SQL variations. That makes it useful for migration analysis, but the hard part is not only converting syntax.

Dialect drift includes unsupported functions, changed type behavior, date arithmetic, identifier rules, optimizer assumptions, and different answers that look close enough to pass casual review.

A drift budget makes risk visible

A drift budget gives migration teams a way to count and classify risk. Track which queries transpile cleanly, which require manual rewrite, which need semantic tests, which depend on vendor-specific behavior, and which are too risky to move without product-owner review.

The budget should be public enough that leaders can see migration debt before it becomes timeline theater. One green transpilation count is not the same as proven semantic equivalence.

Core idea: Portable SQL is not a vibe. It is a measured reduction in dialect-specific assumptions.

The ODI migration loop

Open Data Infrastructure reduces migration risk by keeping data, metadata, and contracts portable. SQL still needs its own evidence loop: parse, transpile, classify, test, compare outputs, and attach remediation work to owners.

For adjacent context, read SQLGlot lineage and portable data models, SQLGlot rewrite rules, and modernizing a closed data stack.

What breaks first

  • Teams count converted files instead of verified business outputs.
  • Unsupported syntax is logged but not assigned an owner or deadline.
  • Semantic drift appears only after dashboards disagree in production.
  • Migration tests cover happy paths and miss edge cases around nulls, time zones, and numeric precision.

Questions to ask

Ask how much SQL is portable, how much is rewritten, and how much is untested. Ask which dialect features represent accepted risk and which block migration.

A drift budget makes migration risk boring enough to manage.

Sources to start with

These primary sources anchor the technical claims in this guide.

The migration is not done when the SQL runs. It is done when the meaning survives.