Migration is a project, not a switch. Plan in stages so reporting, automation, and integrations all land aligned with the new model.
- Enable Lightning Knowledge in a sandbox
Salesforce ships a migration tool that enables Lightning Knowledge and maps existing __kav objects to Record Types on the unified Knowledge object. Run the tool in a sandbox first.
- Map fields per Article Type
Document the field mapping from each __kav object to the corresponding Record Type's layout. Translate validation rules, formula fields, and any per-type Apex code.
- Rebuild reports and dashboards
Classic Knowledge reports do not run against Lightning Knowledge. Identify every report referencing a __kav object and rebuild against the unified Knowledge object with the right Record Type filter.
- Update integrations and Apex
External systems and Apex code that reference __kav objects need to update SOQL and API calls. Confirm Knowledge API integrations support the new schema.
- Validate and cut over production
Once the sandbox migration validates content, reports, and integrations, run the production migration during a planned change window. Plan a freeze on new article authoring during the cutover.
- Classic Article Type objects continue to function but receive no new platform investment. Long-term staying on Classic blocks new Knowledge features.
- Reports built against __kav objects do not run after migration. Plan for rebuilding every Knowledge report.
- External integrations that query specific __kav objects need code changes. Survey all integrations before scheduling the migration.
- Pre-2020 documentation that references Article Type usually translates to Record Type in Lightning Knowledge; treat older guides as historical.