Given a Scenario, describe the considerations when migrating from Knowledge to Lightning Knowledge

...

Overview This blog covers the advantages of Lightning Knowledge over Classic Knowledge and about the Lightning Knowledge Migration process using Lightning Knowledge Migration tool (Beta feature). This describes in detail about the migration process that involves planning, pre-migration tasks, sandbox migration, production migration, validation, and post-migration tasks. It even details some strategies related to testing the migration.

Capabilities of Lightning Knowledge Lightning knowledge has several features which work differently and it is important to consider before planning and migration from Classic knowledge.

  • Article types are mapped to record types in Lightning knowledge.
  • All the fields from different article types are consolidated into a single object.
  • New articles authoring permissions are granted in user profiles and permission sets and article actions with public groups are no longer used.
  • Files from custom file fields in Classic Knowledge articles are moved to standard files object.
  • Fields, actions and related lists are available for Lightning knowledge page layouts.
  • Standard actions that can be controlled in page layouts are used for authoring articles.
  • Standard Record Home (configurable with Page Layouts and App Builder) page.
  • Unified Standard Object Home with Listviews
  • Standard Search: Knowledge in Global Search.

Limitations of Migrating to Lightning Knowledge

  • The following items are not migrated
    • Undeployed article types.
    • Soft-deleted records
    • Articles with a Scheduled for Publish and Schedule for Archive status and a past due date
    • Article Feed Posts that show article changes (published, edited).
    • Promoted Search Terms
    • Approval process history
  • The migration tool only supports orgs with 200K or fewer custom files.
  • Admins must manually assign permissions. Changing from Article Actions with Public Groups to using profile permissions or permission sets is not part of the migration tool.
  • Following Metadata does not migrate
    • Article Type Metadata
      • CRUD
      • Validation Rules
      • Communications Channel Mappings
      • Fields Sets
      • Compact Layouts
      • Audit Trails
    • Field Metadata
      • Formula Fields
      • Required Field Flags in the Field Definition
      • FLS per Field
    • Feed Tracking does not migrate to Lightning unless there is an old article type with feed tracking enabled.
    • Code that uses Field Sets
  • The following customizations are not functional after migration:
    • 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 set, compact layouts, and so forth
    • If reports point to old article types, point them to new object and record types after migration.

Migration Process The following high level steps are followed to migrate Knowledge from Classic to Lightning

  • Plan your Migration
    • Assemble complex mapping ideas using a spreadsheet or organizational tool. This gives you a sense of how to map your knowledge base in Lightning.
    • Print a few articles in advance so you can compare them afterward and verify a successful migration.
    • Update ownership of knowledge articles versions with Inactive Owners.
    • Inspect custom elements before and after the migration to ensure that they moved to the new Knowledge object
    • Perform a company-wide announcement to stop any knowledge base activities during production roll out.
    • Perform Pre Migration Activities as per the below Considerations
      • Deploy any undeployed articles types.
      • Identify unwanted article types and hard delete them.
      • Change metadata setting on article types and default article type setting to None.
      • Get rid of page layouts that are not needed.
      • When mapping fields from multiple article types into one record type, fields must meet certain definitions like length and decimal must be specified to numeric data types (percent, number, currency).
      • Required field flags, deleted fields, field dependencies and default values for picklists or checkboxes are not migrated.
      • Soft-deleted fields are retained for 30 days.
      • During migration stop activities like creation, editing and voting on articles and to stop many of these cited activities during migration, remove Create or Edit rights to Knowledge for user profiles other than the Admin.
  • Perform the migration from Classic to Lightning Knowledge in sandbox org.
    • A full copy sandbox should be used for testing migration to ensure a successful migration. Other types of sandboxes if used cannot give proper test results because of data descripancies.
    • Set up and run the data migration.
    • Switch from Classic to Lightning Knowledge.
    • Validate the migration results. (NOTE Validation is only required for multiple article type orgs.)
    • Accept the migration results.
    • Run through the post-migration checklist.
  • Perform the migration from Classic to Lightning Knowledge in production org.
    • Single Article Type Orgs
      • In Single Article Type orgs, Lightning knowledge migration tool allows mass-assigning a record type to all articles.
      • Articles can be assigned a record type called “Knowledge” or new record types can be manually created later.
      • No Validations are performed for single Article Type orgs.
      • A migration can be accepted or rolled back.
      • Post Migration Checklist Verification
        • Change the label of old article type to Knowledge. Change API name if there are no references to it from communities, sites, apex etc.
        • Check page layouts if fields and related lists are proper. Add required actions.
        • Check Compact layouts if fields are properly listed.
        • Check CRUD permissions on the Knowledge object.
        • Verify and set Permissions
          • Set up record type permissions
          • Set up CRUD per user
          • Manage Authoring permissions per user profile or Permission sets per User.
          • Set up validation rules to restrict certain users or user profiles to modify articles of certail record types.
          • Set up and check approval process routing.
        • Community Dispatcher: Communities has a different routing mechanism, which doesn’t go through the Knowledge dispatcher. After articles are migrated to the new Knowledge object, the Knowledge dispatcher can route to the correct record without changing the URL. Communities uses an old record ID in the record to use for routing. Since Communities has a different dispatcher, Lightning Knowledge provides mapping for the URL redirect.
    • Multiple Article Type Orgs
      • Mapping is one of the most important steps in the migration. Tab through each of the Article Types and make New Field selections. Fields map to the same New Field name by default.
      • After mapping fields migration can be initiated. The timeline is dependent on the volume of articles.
      • When migration is completed, summary page appears under Activation. At this point migration can be cancelled or continued with next steps.
      • The feed component and feed posts don’t appear immediately after migration. After activating the new Knowledge Object, the feed component on articles disappears temporarily while the feed posts migrate. Then the feed component reappears.
      • Review the Data Migration Summary under Validation. In the example, there are green check marks indicating 100% migration. Yellow warning flags (not present in this migration) appear beside data that didn’t migrate.
      • If the migration summary shows that some articles did not migrate, a file named LightningKnowledgeMigrationResult.txt will be generated. This file will report up to 1000 failed migrated article IDs. It can be found under the Files tab. The admin who started the migration owns this file. If all articles and article versions were migrated successfully, the file will not be generated even if related data such as Data Category or Feeds failed to migrate.
      • After validating the results in the Data Migration Summary we have options to cancel or Accept the migration.
      • After successful migration validate that no apex code, communities, sites, data flows, process automation, are referencing old article types.
* Post Migration checklist
    * review each setup options for Knowledge in Object Manager to verify mappings
    * Reset picklist dependencies as Picklist options migrate but mappings won't
    * Add FLS
    * Redefine formula fields as needed
    * **Validation Rules** may require changes as Article Types have now been consolidated into one object.
    * Check page layouts if fields and related lists are proper. Add required actions.
    * Check Compact layouts if fields are properly listed.
    * **Communication Channel Mapping:** Set up fields to insert into the email per Record Type.
    * **Workflow and Approval Processes**: it may be needed to adjust the Workflow and Approval Process criteria to look at Record Type.
    * **Process Builder Processes**: Make sure that Processes now reference the new Knowledge object.
    * **Customizations:** Inspect custom elements after the migration and ensure that they moved to the new Knowledge Object.
    * Check CRUD permissions on the Knowledge object.
    * Verify and set Permissions
        * Set up record type permissions
        * Set up CRUD per user
        * Manage Authoring permissions per user profile or Permission sets per User.
        * Set up validation rules to restrict certain users or user profiles to modify articles of certail record types.
        * Set up and check approval process routing.
    * **Community Dispatcher:** Communities has a different routing mechanism, which doesn’t go through the Knowledge dispatcher. After articles are migrated to the new Knowledge object, the Knowledge dispatcher can route to the correct record without changing the URL. Communities uses an old record ID in the record to use for routing. Since Communities has a different dispatcher, Lightning Knowledge provides mapping for the URL redirect.

References

...