Migrating a Quasar v1 app to v2: incremental Vue 2 compat path or full Vue 3 rewrite?

The Recommended Strategy: Direct Rewrite

For a mid-sized codebase, a direct rewrite (porting) to Quasar v2 idioms is the lower-risk path. While a full rewrite sounds daunting, the Vue 3 migration build (compat mode) is designed for Vue-only applications; it does not resolve the breaking changes inherent in the Quasar framework itself. Because Quasar v2 introduces a new CLI, updated configuration formats, and modified component APIs, you would be forced to manage two sets of breaking changes simultaneously if you chose the incremental path.

Why the Migration Build is Discouraged here

The Vue 3 migration build allows Vue 2 components to run in Vue 3, but it does not make Quasar v1 components compatible with Quasar v2. Since your app relies heavily on QTable and QDialog, you must update these to the v2 API regardless of the Vue version. Attempting an incremental path often results in a "hybrid state" that increases bundle size and complicates debugging without bypassing the actual work of updating the Quasar components.

Systematic Migration Steps

1. Dependency Audit: Create a list of all third-party app extensions. Check for v2 versions. If a critical extension is v1-only, you must find a Vue 3 alternative or write a wrapper before starting the build migration.
2. Pattern Mapping: Before touching the CLI, perform a global search for Vue 2-specific patterns that must be replaced:
   • this.$children $\rightarrow$ Use refs or a state management store (Pinia).
   • Vue.prototype $\rightarrow$ Use provide/inject or global properties in the Vue 3 app instance.
   • Filters $\rightarrow$ Replace with computed properties or global utility functions.
3. Tooling Shift: Initialize a fresh Quasar v2 project using @quasar/app-vite (recommended for faster development) and migrate quasar.conf.js settings to the new quasar.config.js format.
4. Component Porting: Move components one by one. Update v-model implementations (which changed from value/input to modelValue/update:modelValue) and rename props based on the v2 documentation.

Verifying Parity for QTable and Notify

To ensure behavior parity without manual regression testing of every edge case:

• Notify: Since Notify is a plugin, verify the call signature. In v2, ensure you are using the Notify.create() pattern and check that the CSS transition timings match your previous production feel.
• QTable: Focus on the custom slots. Compare the slot names (e.g., body-cell-[name]) between v1 and v2. Use a side-by-side browser window with the v1 production site and the v2 dev build, feeding both the same JSON dataset to verify rendering and sorting logic.

Missing Diagnostic: Are your third-party app extensions primarily UI-based (Vue components) or logic-based (JavaScript plugins)? If they are deep UI integrations, the rewrite risk increases significantly.