When you migrate a schema between database engines, not every object translates the same way. Cross-dialect readiness is the idea of knowing, up front, which object types port cleanly and which need a human — before you run anything.
Full — translates cleanly
- Tables and columns — with type mapping between dialects.
- Primary and foreign keys — structural; references are requalified to the target schema.
- Indexes and unique constraints — via each dialect's own
CREATE INDEXform.
None — needs manual review
- Views — the body is dialect-specific SQL; a cross-dialect view is flagged, not auto-translated.
- User-defined types — each engine's enum/domain/object model differs with no clean bridge.
- Functions, procedures, triggers — procedural code rarely ports one-to-one.
Why up-front readiness matters
The alternative to knowing this in advance is discovering it as a runtime error halfway through a migration. A readiness panel turns those surprises into a checklist you handle deliberately, alongside the auto-generated structural DDL.
See it in action
FoxSchema shows a cross-dialect readiness panel whenever you compare two different engines. Read the cross-dialect migration guide, then try it.
