Plan the Migration
After completing this unit, you’ll be able to:
- Describe what changes during migration to Lightning Knowledge.
- Decide if your company is ready for Lightning Knowledge migration.
- Plan your migration.
What Changes During Migration?
Before starting, Maria researches the Lightning Knowledge Migration Tool which helps automate the migration process. It supports two kinds of migrations: one for a knowledge base using a single article type and one for a knowledge base using multiple article types. Ursa Major uses two article types, so she focuses on researching migration with multiple article types.
Here’s a table comparing features across article types.
|Feature||During migration||After migration|
|Data model and article types||The migration tool converts article types to record types and consolidates fields in one Lightning Knowledge object. The tool also moves and consolidates related records, such as links to cases, data categories, votes, views, and Article Feed.||Knowledge manages features per record type, including page layouts.|
|Article numbers||Article numbers change due to hard-coded application limitations with the standard auto-number field type.||Use the new article numbers.|
|Files||The migration tool moves files from custom file fields in articles to the standard Files object. You can choose the basic visibility setting to use for all your files after migration. This setting determines if files are visible to all users with access to the article (including guest and Communities users) or only to internal users.||Admins and users view and attach files in the Files related list. If needed, they change visibility settings for individual files.|
|Permissions||Article actions are no longer supported as the method for defining authoring permissions.||Admins set up user profiles and permission sets to control access to articles.|
|Page layouts||Automatically migrated.||Admins check and edit page layouts. Use Page Layout setup to select fields, add actions, and add related lists to page layouts. Assign page layouts per record type and user profile by using page layout assignment.|
|Compact layouts for mobile pages||Migrated.||In Lightning Knowledge, compact layouts work for all pages, not just mobile. They can also be set up per record type.|
The Lightning Knowledge Migration Tool does most of the heavy lifting. But Maria must do some work to set up the Knowledge org before and after migration.
Is Now the Time?
Maria evaluates the existing knowledge base to make sure it’s a good candidate for migration. She has to make sure that migration is possible and that the features the service team uses will work afterward.
She checks to see what features they use and how they implement them. Lightning Knowledge is different from Classic, and if the service team relies on features not available in Lightning Knowledge, migration isn’t a good idea.
To get a solid background, Maria reads the help topics about migration. She plans to read them again as she moves through the process, but she wants to know a lot before she starts.
- Verify AppExchange Apps. Before migration, Maria verifies that the app her team uses is available in Lightning Knowledge. She must test after migration.
- Re-create Items Post-Migration. She’ll have to set them up again after migration. Items that don’t migrate include formulas, dependent picklists, and custom code. She reads Lightning Knowledge Migration Tool Features and Considerations for a full list. Is it possible to re-create them after migration? Yes. Is it too much work for Maria to do that? No.
- Update Customizations. For example, Visualforce pages with formulas and Apex code. Maria decides if she still needs these customizations. If she does, she can take advantage of new methods for customization and build a Lightning component instead.
- Use Supported Features. Maria double checks that her team isn’t using unsupported features. She carefully reads Lightning Knowledge Limitations to make sure.
She runs through the list of limitations and changes with the service team. It’s vital that they understand what will work differently in Lightning Knowledge before they decide. After thoughtful consideration, everyone agrees that they want to migrate.
Make Lists and More Lists
Maria starts to make the first list. She loves lists. She’s been know to add “make a to-do list” to her to-do list. You know, so she can cross it off after she’s done. That’s why she’s grateful to see that the documentation includes a Pre-Migration Checklist.
The first tip on the checklist is a reminder to perform the migration into a full-copy sandbox first. After that, she can test and verify that it’s working perfectly in the sandbox. Once it is, Maria will migrate the production org. She’ll do the migration twice: once in the sandbox org and once in the production org. By the time she migrates to the production org, the migration will go smoothly.
Now she feels like she has enough background knowledge to create her own list.
Here’s her pre-migration checklist for Ursa Major.
|Component||Tasks to perform before migration|
|Customizations that don’t migrate||Ursa Major uses multiple article types, so Maria looks for customizations that reference those article types. Here’s a resource with some common examples.
|AppExchange apps||Check AppExchange apps and make sure that they work with Lightning Knowledge. Ursa Major uses one app from AppExchange, and it’s compatible with Lightning Knowledge.|
|Case and answer settings||To prevent errors during migration:
|Articles||Publish and archive scheduled articles before starting migration.|
|Verify that you’re a Knowledge user||Maria must be a Knowledge user with the Modify All Data permission in the org where she’s running the migration.|
|Stop changes to the org during migration||If users change the knowledge base while the migration is going on, it’s easy for data to be lost or corrupted. In Knowledge Article Actions, Maria removes Create, Edit, Archive, and Delete rights to articles for user profiles other than the admin. When Maria migrates into a sandbox, she can restore those rights in the production org after she finishes the migration. If she’s migrating her production org, she’ll replace those actions with permission sets.|
Now Maria has a much better idea of the scope of work required for the migration.
She also notes that she must put in a request to Salesforce Support to allow her to migrate her production org to Lightning Knowledge. She plans to put in the request right after her sandbox migration. Then she’ll be ready to start production migration about a week later.
Maria is excited to start the migration! Since migration must happen during off-peak hours, she contacts her team to find that after 7 PM on Friday is the best time for them. Maria loves to go out dancing on Fridays, but she’s willing to miss a night for her team.
Now Maria’s made a detailed plan of tasks to complete before starting her migration. All she has to do is wait for Friday night to get started.