Plan the Migration

Learning Objectives

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 how the Lightning Knowledge Migration Tool 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 Experience Cloud 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 to Migrate?

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.

Create a Pre-Migration Checklist

Maria starts to make the first list. She loves lists. She’s been known 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. When 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
Article types	Check for undeployed and unneeded article types. She doesn’t find any, so she checks off this item. Implement needed metadata changes. The metadata is in good shape, so she checks off this item, too. In Knowledge Settings, change Default Article Type to None.
Permissions	Determine what permissions each Ursa Major user needs. Plan how to set up profiles and permission sets for after migration.
Page layouts	Delete unneeded page layouts. Her team uses all their page layouts, so there’s nothing to delete. Make a list of representative articles so she can compare those articles in the production org to the migrated articles in the sandbox. List fields hard-coded to the page in Knowledge in Salesforce Classic. She’ll add them back after migration. After migration, Salesforce assigns pages via record types instead of article types. She notes who accesses which page so she can set that up after migration.
Fields	Formulas and dependencies don’t migrate. Picklists have some migration limitations, too. She makes a list to recreate. Make a list to update which fields are required in Fields and Relationships. Redefine validation rules. In Classic, validation rules are defined for only one article type. In Lightning, define them for one or more record types. By default, all fields from article types are created as new fields in the new Knowledge object. But fields from different Classic article types can be combined into one field in Lightning Knowledge. Map fields that perform the same function and have the same field type together during migration. Ursa Major’s Knowledge in Salesforce Classic has rich text fields called Details for both article types. Maria wants to consolidate those fields during migration. To make the mapping clear, she creates a spreadsheet.
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. 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 permissions (per Article Type) Applications that use metadata APIs on features like field sets and compact layouts Reports that point to old article types
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: In Case Settings, under Allow user to create an article from a case, set the default article type to None. In Answer Settings, under Allow users to create an article from a reply, set the default article type to None.
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. 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.

Plan the Migration

Learning Objectives

What Changes During Migration?

Is Now the Time to Migrate?

Create a Pre-Migration Checklist

Resources