Salesforce Knowledge gives you the ability to build out a comprehensive Knowledge Base (KB) inside of Salesforce – a collection of articles with relevant information about your products and services, to encourage a self-service model for your customers to solve their own queries. Lightning Knowledge is simply Salesforce Knowledge in the Salesforce Lightning Experience.
As you likely know, making the move from Classic to Lightning can be a major undertaking. But there are many reasons why it’s better to move sooner than later. If your users are using Salesforce Knowledge then that’s just one more thing to tackle during your larger move to the Lightning Experience.
Today, we’ll be taking a deep dive into migrating to Lightning Knowledge, covering what’s changed in the architecture, things to consider before starting your migration, and some gotchas to look out for!
Lightning Knowledge: What you need to know
This blog focuses on the gotchas of a lightning knowledge migration and doesn’t get too in the weeds about Lightning Knowledge features.We have an entire blog post dedicated to just that — Introduction to Lightning Knowledge!
If you’re completely new to knowledge then you should read over my overview to Lightning Knowledge first to understand the functionality. If you’re already familiar with knowledge and looking to make the move to Lightning Knowledge, you’re in the right place! This blog post will focus on some of the major changes in Lightning Knowledge compared to Classic Knowledge and how to handle that transition.
Knowledge Architecture Shift
Lightning Knowledge is one of the major Lightning Experience changes that actually results in a data architecture change. We’ll get into the details in a moment, but the main thing to keep in mind is that Lightning Knowledge now functions more like normal Salesforce Objects (awesome!)
Article Types, now Record Types
In Lightning Knowledge, Article Types are now Record Types. You access and update the object in Object Manager just like with any other SObject. This means you can control page layout assignments, access, and picklist options all based on record type like on other Salesforce objects. But wait – there’s more! You can now write Apex Triggers on the Knowledge Object! If you want to get a little nerdy, Salesforce documentation has a very in-depth review of the Knowledge data model and how it works.
3 Things to Consider Before You Start
There’s a lot to think about when prepping for a Lightning Knowledge migration. Here’s 3 of the things we find most important.
1. Is your org ready for the migration?
Before embarking on the Lightning Knowledge transition, you want to make sure your org and your users are ready for the move. Knowledge changes in the Lightning Experience. As a result, Lightning Knowledge isn’t accessible via Classic. If you still have users that aren’t in Lightning yet then they will lose access to Knowledge articles. If you need help getting your team into Lightning so you can use Lightning Knowledge, Internet Creations can help you get started.
2. What needs manual updating during migration?
The Salesforce Lightning Knowledge Migration Assistant definitely helps a lot with the migration to Lightning Knowledge. However, there’s also some manual work required. Depending on the customization you have in your org, you may need more or less of this manual work. Make sure you review all the items you’ll have to do manually before starting finalizing the timeline and Go Live date so you know you have enough time to do the necessary steps.
3. Your migration timeline
Since Lightning Knowledge is a major architecture change and cut-over from Classic to Lightning, you have to ensure your Go Live plan and timeline are thought through. There are several steps that have to be taken to perform the migration fully in a sandbox and then in production (a sandbox migration is required by Salesforce) and depending on how many things require manual updates you may have a lot to prep. Laying out the major items you’ll have to do and allotting times to them will help you determine a realistic timeline. To help get you started, here’s the basic steps all orgs have to go through.
- Review what you’ll have to do manually. This is more prep work to help you determine project scope and timeline, but it can be fairly time consuming if you have a lot to review. We’ll dive into the details on this next.
- Run through the migration in a sandbox. Full sandboxes are best so you get an accurate dry run of the migration.
- Reach out to Salesforce support to enable the Migration Assistant in production. Sounds simple but it isn’t necessarily that easy. More on this in the “gotchas” section.
- Train your users, especially authors, on how to use Lightning Knowledge.
- Regression test in your sandbox. Including things like public knowledge bases and any processes that rely on Knowledge content.
- Perform the migration in Production. A previously-agreed-upon maintenance window is recommended.
- Smoke test in Production to make sure nothing went wrong!
Feeling a little overwhelmed? Internet Creations can help you with your Lightning Knowledge migration journey.
What Migrates and What’s Manual?
To elaborate a little on #3 up above, let’s review some of the items that won’t migrate automatically. This list can help you build out your own checklist based on our own org’s configuration.
What migrates:
| Item | Notes |
|---|---|
| Related records | The migration assistant moves and consolidates related records, such as links to cases, data categories, votes, views, and Article Feed. |
| Page layouts | These migrate over normally, but admins should confirm they are correct after migration. |
| Compact layouts | These migrate over normally, but admins should confirm they are correct after migration. |
| Custom fields | Custom fields are automatically created on the new Knowledge object based on your previous article fields. But be careful -- there are some “gotchas” surrounding field migration (see below). |
What doesn’t migrate:
| Item | Notes |
|---|---|
| Article numbers | Due to limitations of Auto-Number fields, Article numbers will reset/change during migration. |
| Version History | Version history doesn’t move over to Lightning Knowledge, so be sure to back it up if you need it for retention policies. |
| Article Actions | Admins must reassign article access for publication, etc. after migration. |
| Dependent picklists | If you have any picklist dependencies on Classic knowledge articles, these have to be recreated after migration. |
| Formula fields | Formula fields do not migrate cleanly and need to be audited and corrected after migration. |
Migration ‘Gotchas’ – Look out!
At Internet Creations we’ve done a lot of Lightning Knowledge migration projects, both big and small! We’ve even migrated our own knowledge base, which was over 12 years old, to Lightning Knowledge. We’ve seen a lot throughout these projects and we want to help you learn from our experience!
Getting the Migration Assistant Enabled in Production
The Lightning Knowledge Migration Assistant is enabled by default in sandboxes, so you should have no trouble testing it there. However, you have to ask Salesforce to enable it in Production. This may seem simple, but Salesforce will actually ask you a series of questions that you need to be prepared to answer. We’ve also seen some delays in the past with certain questions stalling projects. Waiting too long to ask Salesforce to enable the tool can cause project timeline issues, so it’s best to prepare in advance!
The questions Salesforce will ask you are listed in this Salesforce knowledge article. It’s recommended you review them and make sure your team is aligned on the answers in advance!
Changing Record Types
This is a sneaky gotcha that, unfortunately, isn’t obviously documented in a lot of Migration Assistant documentation. There’s a restriction on Salesforce Lightning Knowledge articles that prevents you from updating the Record Type from a published article. You can’t even Edit as Draft and change the record type on the daft. You can only update record types on net new articles.
Why is that such a big deal? This means that whatever record type your converted articles are assigned when they are migrated is the record type they’re stuck with! The only way to change them would be to clone it as an entirely new article, change the record type, and then publish fresh. Not only is this tedious, but ratings, related records, etc. won’t move over to the new article.
When you migrate knowledge articles, the Migration Assistant will automatically create new Record Types with names that match the original Article Type names. This is good news if your Knowledge structure isn’t changing with the migration. But this is a major “gotcha!” if you’re planning to reorganize your record types in Lightning Knowledge. Make sure your Classic Knowledge Article Types mirror your desired Record Type format for Lightning Knowledge.
Custom Field API Names
Another migration gotcha surrounds the API names for custom migrated fields. The Migration Assistant is smart and will recreate custom fields on the Lightning Knowledge object and migrate the data from those custom fields over to the new fields. Word of warning though, to avoid the possible error of duplicate API field names, the Migration assistant prefixes the new custom fields with the Article Type name.
For example: You have two article types — News and FAQ. News articles have a custom field called Abstract__c and FAQ articles have a custom field Question__c. When these migrate, they will become News_Abstract__c and FAQ_Question__c, respectively.
File Fields
One feature of Classic Knowledge that doesn’t exist in Lightning Knowledge is the concept of file fields. File is a field type option on Classic Knowledge articles that would allow for the uploading of an image or document to the article. These fields could be used for things like article thumbnails, etc. These don’t exist in Lightning Knowledge, and the files uploaded to these fields are moved to normal Salesforce Files by the Migration Assistant. This is something to be prepared for, especially if you have multiple different file fields for different attachments or are using the file fields in custom code.
API Name References on OLD Salesforce Sites
If you’ve never had a public knowledge base or your knowledge implementation is fairly new (less than 5 years old) then this probably won’t be an issue for you. But if you’re like us — a 12 year old public knowledge base — then heads up! Sometimes old, archived Salesforce Sites that hosted knowledge in the past can still be referencing Classic Knowledge API on the backend. The Migration Assistant can’t help with these old Salesforce Sites, and sometimes Salesforce Support has to get involved to help. This is one of the many reasons it’s so important to do a test run of the migration in a sandbox, so you can uncover these little surprises earlier than later!
Lookup Filters for Knowledge Articles
One final Lightning Knowledge quirk that could surprise you during implementation is that lookup filters are not supported for lookups to Lightning Knowledge. If you have a lookup field pointing to Knowledge, you can put a filter in place but the filter will only error upon save and not actually filter the results being shown, creating a poor user experience. There’s not really a great workaround for this and is just something to keep in mind if you ever have a requirement to filter lookups to Knowledge articles.
Next Steps
So you’re ready to embark — now what? Internet Creations has a highly skilled team of certified consultants, developers, and architects who live and breathe Salesforce. From small company FAQs to global, enterprise-level knowledge libraries to our very own knowledge base for our AppExchange apps, we’re seasoned Lightning Knowledge migrators. We’d be happy to help and perform a free consultation on a possible Lightning Knowledge migration project. Contact us today!
Also, Trailhead has some great content focused on Lightning Knowledge migrations. Read over their content to prepare even more.
Comments: