Migration

Migration guides describe one supported end state. They show old APIs only to identify and remove them.

Choose a guide

• From Nuxt Content v2 — replace queryContent, document-driven assumptions, and v2 rendering patterns.
• From Nuxt Content v3 — replace the package, SQL-backed query assumptions, route queries, navigation, and search.
• Ginko version upgrades — apply version-specific hard cuts inside Ginko.

Migration policy

• Do not run Ginko and Nuxt Content together in one Nuxt application.
• Do not add compatibility wrappers around removed pre-1.0 Ginko APIs.
• Move content configuration to collection handles before changing page code.
• Replace application routes and lists with the current unified query API.
• Scan for stale imports and identifiers after the mechanical changes.
• Verify the packed or installed package, not only workspace source.

Required final state

A completed migration has:

• only @lupinum/ginko-content registered as the content module;
• collections declared through @lupinum/ginko-content/config;
• page routes using useContentPage(handle);
• list and server reads using current collection-first verbs;
• links using normalized route fields;
• search using useContentSearch;
• no duplicate locale collection maps or application route facts;
• a successful build, typecheck, and production preview.