You are here:
Lightning Knowledge Migration Tool Features and Considerations
Before planning and performing the migration with the Lightning Knowledge Migration Tool, learn about the differences between Classic Knowledge and Lightning Knowledge. Understand the limits of the migration tool and Classic features that either aren’t supported or work differently in Lightning Knowledge.
Required Editions
| Available in Salesforce Classic and Lightning Experience. View supported editions. |
Key things to note about the post-migration Lightning Knowledge data structure:
- Record Types —The migration tool maps Classic Knowledge article types to record types and consolidates fields in one Lightning Knowledge object.
- Files—Files from custom file fields in Classic Knowledge articles are moved to the standard Files object. After migration, view and attach files in the Files related list.
- Permissions—User profiles are granted new authoring permissions in user profiles or permission sets, and no longer use article actions with public groups.
Let’s compare Classic Knowledge to Lightning Knowledge:
| Feature | Classic Knowledge | Lightning Knowledge |
|---|---|---|
| Access & Permissions |
|
|
| Approvals & Workflow | Per article type |
|
| Authoring | Custom Article Management tab | Standard Actions (admin can control in page layout) |
| Data model | Custom article types | Standard record types |
| File Attachment | Custom file fields (5 max) |
|
| Object Home |
|
Unified standard object home with list views |
| Page layouts |
|
|
| Record Home | Custom record home (static) | Standard record home (configurable with page layouts and App Builder) |
| Search | Custom Knowledge search | Standard Search: Knowledge in Global Search |
| Sharing | Article access by data category | Standard Salesforce sharing also available |
| Validation Rules | Per article type |
|
As part of the migration plan, we recommend that Knowledge admins become familiar with all the limitations. Before performing sandbox and production migrations, assess whether these items pertain to your org’s implementation of Knowledge and prepare accordingly.
The following items do not migrate from Classic into Lightning Knowledge:
| Item | Description |
|---|---|
| Article Number | For orgs with multiple article types, article numbers change during migration. Because Article Number is a standard auto-number field, you can’t retain the numbers when migrating to Lightning Knowledge. |
| Article Status | The following are removed during migration:
Publish scheduled articles and archive scheduled articles before starting the migration. |
| Automated Article Feed Posts | Article Feed Posts that show article changes (published, edited). |
| ContentPublication | Due to the ContentPublication limit (how many ContentVersion objects can be created per day), the migration tool supports only orgs with 200,000 or fewer custom files. Contact Salesforce support if your org has more than 200,000 files. |
| ContentVersion, Physical Delete | Due to the nature of ContentBody reuse, if an org performs an UNDO, the ContentVersion rows must be physically deleted before migration. Because physical delete runs as a cron job during off hours, the overall UNDO process can take several days. |
| Field Tracking Limits | Field histories migrate when field tracking is enabled. If the total number of fields with tracking enabled across all Article Types exceeds the limit, you see an error message, and the migration doesn’t start. To make sure that the total is below the threshold, remove the tracking on some fields , and retry the migration. The default limit for field tracking is 20 fields. If you need to raise this limit, contact your Salesforce representative. |
| Soft Deleted Records | Soft-deleted records are not migrated from Classic. |
| Undeployed Article Types | Undeployed article types are removed during migration. Deploy article types you need and delete those you don't. |
| URL Redirect | After migration, article URLs in these two standard formats redirect to the appropriate article in Lightning Knowledge.
After migration, Smart Links automatically redirect to the correct environment. The URL redirect behavior varies based on the environment. For information about URL redirects, see Target Behavior for Smart Links. |
| Workflow and Approval Processes | Approval process history doesn’t migrate to Lightning Knowledge. |
| Metadata Types | Description |
|---|---|
| Article Type Metadata |
|
| Feed Tracking | Feed Tracking does not migrate to Lightning unless an old article type with feed tracking is enabled. |
| Field Metadata |
|
| Fields Sets | Code that uses field sets |
Customizations based on article types don’t work after migration. In orgs with multiple article types, you must update customizations to use the new knowledge object. Consider these customizations:
- SOQL that queries the concrete entity name
- Visualforce pages that refer to old article types
- Code that uses field sets
- Apex code that refers to old article types
- Custom code using API calls referencing article types
- Customer application logic, such as current API code
- Some AppExchange packages
- Validation rules
- CRUD (per Article Type)
- Applications that use metadata APIs on field sets, compact layouts, and so forth
- Reports that point to old article types
- Although your sandbox org might contain corrupt data, your production org data might not be corrupt, or might have different corrupt data.
- If a record doesn’t load properly in either the Salesforce Classic or Lightning Knowledge interface, it can be due to data corruption.
- You can’t compare the article count from the migration summary page with SOQL results using
COUNT(). Because of limitations with Workbench, SOQL queries usingCOUNT()don't return the same list of articles, article versions, version histories, and vote and view statistics. - In orgs with multiple article types, the size of your knowledge base temporarily doubles during migration. Your File and Data storage limits are temporarily doubled when migration starts, and reset when you cancel or accept the migration results. During this period, both the Classic and Lightning Knowledge versions of each article are present in your org.
Now that you’ve learned about the Lightning Knowledge Migration Tool, it’s time to plan and sandbox test your migration.

