Migration is mostly about identifying which Classic Templates the org used and rebuilding the same read-time experience with Lightning components.
- Inventory Classic Templates per Article Type
Document each Article Type and its current Template assignment (Table of Contents, Linear, FAQ, or custom Visualforce). Note any per-channel variations.
- Map each Template to a Lightning component
Standard templates usually map to the default Article Lightning Web Component with configuration adjustments. Custom Visualforce templates map to bespoke Lightning components.
- Build or configure Lightning components
Configure the standard Article component in Experience Builder for default cases. Build custom Lightning Web Components where the Classic template was custom.
- Validate read-time experience in a sandbox
Render representative articles through the Lightning components. Verify section behaviour, table of contents, and any branding match the Classic experience the team expects.
- Retire Classic Templates after cutover
Once Lightning Knowledge is production, Classic Templates no longer drive read-time experience. Remove unused Visualforce template pages and document the new presentation model.
- Classic Article Type Templates are not a Lightning Knowledge concept. Documentation that describes them is by definition legacy.
- Custom Visualforce templates do not migrate automatically; they must be rewritten as Lightning Web Components.
- Read-time experience differences are easy to miss until users notice. Validate in a sandbox against representative articles before cutover.
- Branded layouts often require Lightning component customisation. The default Article component is functional but rarely matches a custom brand.