Where SET MANAGED is supported, it has replaced DEEP CLONE as the primary migration path for UC Delta tables. DEEP CLONE is now more of a fallback tool.

Below are 3 options.

1. UC external → UC managed with ALTER TABLE … SET MANAGED (DBR 17+) – preferred

   • Databricks explicitly recommends SET MANAGED over CTAS/DEEP CLONE for converting UC external tables to managed because it:
     • Preserves full table history.
     • Minimizes downtime using a two-phase background copy (typical writer downtime ~1–5 minutes, readers often no downtime).
     • Keeps the same table name, permissions, comments, configs, and adds path-based redirect for legacy code.
   • Best practice: If you can get your table into UC external Delta, then run SET MANAGED. That is the “easy button”.

2. UC managed → UC external (same location) → SET MANAGED in new managed location – advanced but strongest semantics

   • For moving existing managed tables to a new managed location while preserving full history and supporting concurrent writes with ~1–2 min downtime, the pattern of managed → external → ALTER TABLE … SET MANAGED is an alternative to pure DEEP CLONE, assuming DBR 17+ and the catalog already has the desired managed location configured.
   • This is more operationally complex than a straight DEEP CLONE, but you get the SET MANAGED benefits (history, minimal downtime, no namespace change).

3. DEEP CLONE – still useful in some cases

   • Still a good choice when:
     • You’re changing format (e.g., Parquet → Delta) or coming from non-UC / foreign sources where SET MANAGED doesn’t apply.
     • You want a one-off copy (e.g., DR dry runs, sandboxing, moving between catalogs/metastores where you actually want a new table and don’t need history continuity).
   • Trade-offs: duplicates data, does not preserve version history across the move, and generally has more visible downtime than SET MANAGED in the external→managed scenarios.

Recommendation:
Given you’re on DBR 17+ and talking about tables that can be represented as UC external Delta, the current best practice is:

• Prefer a SET-MANAGED–based path over a pure DEEP CLONE, especially when you care about:
  • preserving table history,
  • minimizing writer/reader downtime, and
  • avoiding duplicate data and code changes.

So you are right: “first migrate as external, then SET MANAGED to managed” is now the better option than relying solely on DEEP CLONE, and DEEP CLONE should be reserved for cases where SET MANAGED simply doesn’t apply or you intentionally want a fresh copy.