Loading

Lightning Knowledge Migration Tool FAQ

Publiceringsdatum: Oct 13, 2022
Beskrivning
Review the Lightning Knowledge Migration Tool documentation and below for frequently asked questions.


Salesforce YouTube videos
Lightning Knowledge Migration Tool
 
Lösning

Why is the 'Lightning Knowledge Migration Assistant' not available in Lightning setup even though the tool is generally available?

See the Requirements to Enable Lightning Knowledge Migration Tool article for more details.
 

How can we start testing the feature?

All customers must carefully read through existing documentation in its entirety, Lightning Knowledge Migration Tool to ensure they're both an eligible candidate and have a full understanding of the tool's features and functionality prior to use.

The migration assistant is only available in sandbox environments by default. Testing and validation for multiple article type migrations must be completed within a full copy sandbox that has been refreshed recently (within or close to the last month).

Please discuss the possibility of provisioning a temporary full copy sandbox license with your Account Team if one is not currently available for this purpose.
 


How do we enable in production?
 

If you have concluded end to end testing to Migrate Multiple Article Type in full copy sandbox and are ready to enable in Production, a review, validation, and approval process is required before enabling. Review the instructions in the Requirements to Enable Lightning Knowledge Migration Tool article to begin this process.

Although testing is recommended for all knowledge migrations, production organizations with only 1 single article type can request to have the migration tool enabled by Support without the requirements for sandbox testing, review, and approval.

Note: There is no SLA for review, approval, and enabling the feature in production. Please begin the process and communicate tentative timelines well in advance of planned dates as the review process for production may take 1 - 2 weeks to complete. New approval requests submitted during weekends or holidays will not be reviewed or processed until at least the following business day. While Salesforce will strive to accommodate requests, there is no guarantee for enabling within prescribed timelines.



Is there any way to find out what articles weren't migrated on the 'Validate your migration' results page?

Documentation indicates, "During migration, a results file called LightningKnowledgeMigrationResultTimestamp.txt is generated in the standard Files object. The admin who started the migration owns this file." Reference: Perform the Migration: Multiple Article Type Orgs

The file containing the articles and article versions that failed to migrate may be found by searching Files via Global Search. The File name(s) should have a format of 'LightningKnowledgeMigrationResult*' which should be used as your search term to locate the files in your org.

Note: The referenced file is generated if articles or article versions were not migrated and only provides the first 1000 record Ids for review and reference. The tool does not include or provide an explanation for why the articles failed to migrate. Unfortunately, these details aren't available to Support and customers must manually review the affected articles for potential discrepancies or issues. If articles and article versions show as successfully migrated the file will indicate this regardless of whether other additional data may have failed to migrate.

If you would like to see additional migration details provided via the tool's functionality, please consider creating or promoting an Idea on the IdeaExchange for visibility and consideration among the larger Trailblazer Community and to track potential feature enhancements.


Can we retain our previous article numbers?

No, if you're performing a multiple article type migration it's not possible to control the change of the Article Numbers when migrating to Lightning Knowledge. You don't have the option to retain old article numbers due to hard coded application limitations with the standard auto-number field type.

Note: For single article type migrations article numbers are maintained and do not change. This is because the migration process does not re-create articles for a single article type migration.


What happens when performing a single article type migration?

It's expected and by design for single article type migrations to exhibit the following behaviors depending on which selections are made in step 4. of the Migrate a Single Article Type documentation:
 
  • 'Assign to a new Record Type called...' - existing Article Type's name is used for object's API Name however, the knowledge object's label is changed to 'Knowledge.'
 
  • 'Manually create new Record Types later' - existing Article Type's name is used for the knowledge object's Label and API Name and it is NOT changed to Knowledge (Knowledge__kav).

After clicking 'Begin' there are no further steps, confirmation pages, or indication of progress provided in the user interface for the tool and it's no longer visible in Setup.

The migration runs in the background and admins only receive an email notification and results file if the migration process includes files. If the single article type migration did not include files and no data was created, then no email notification or results file is generated when the migration is complete.
 

How do we address other data that did not migrate?
 
The tool's current design only provides the articles and versions Ids that were not migrated successfully. Specific details on why articles or other aspects did not migrate are not available. Salesforce Support does not have the ability to provide customers with details on what or why specific data did not migrate. This level of detail is not something that's output by the tool and is not provided via the tool's current functionality.

The migration tool does not guarantee a 100% success rate and some data not migrating is not necessarily indicative of an unexpected issue that can be directly addressed via specific changes to your org or through modifying the tool itself. The tool's intent is to provide a means to help customers with their migration to Lightning Knowledge and is not a guaranteed end to end solution. If you're not satisfied with the results, cancel the operation in order to try again ensuring you've followed all recommendations in the tool's available documentation and are using a recently refreshed full sandbox.

Potential migration failures require customer side intervention to carefully review and ensure that the results are satisfactory for their unique requirements. It's each customer's responsibility to review the migration results and perform their own analysis to determine whether they would like to proceed or not. The tool is provided as is and is not intended to be a full solution and is instead, only a means of assisting customers with their migration to Lightning Knowledge.

Manually checking and verifying data to accept or cancel the results of the migration based on the tool's available details or on customer's behalves is not within the scope of Support's offerings.


Who receives the migration summary email?

All active users who are assigned a profile with the 'Modify All Data' permission in the org where the tool is being run will receive migration summary emails. There is no way to change this behavior and it's hard coded functionality of the tool.

If admins are not receiving emails be sure to check the email address specified on your user record to ensure it's valid and set your Email Deliverability to at least "System Only." For more details see Guidelines for Configuring Deliverability Settings for Emails Sent from Salesforce. 


Why is the migration taking so long?

Completion time depends on the size of the knowledge base you’re migrating and how many other processes are running at the same time.

There is no expected time frame or SLA for migration completion and the process may take several days to upwards of over a week plus depending on the size and degree of customizations of your Knowledge base.

The migration processes are a closed system and it's not possible for Support or the Product team to speed up or decrease processing time. However, if you believe that an unexpected issue may be occurring please log a case with Salesforce Support to check your migration's current status.


Why am I seeing, 'Article types are not in the correct states for Cancel' or 'The article type Knowledge is not in the correct status.' when trying to cancel my migration?

These errors are known to occur when the old article types or the new article types have been manually changed during migration. For example, if article types were deleted or their deployment status have been manually changed in setup during the migration.

Review your org's Setup Audit Trail in order to manually undo any Knowledge setup related changes in order to try the cancel again. See Monitor Setup Changes for more details.

If article types were deleted during the migration no workaround is available and it's necessary to refresh the sandbox and start over with a clean slate. If refreshing is not possible, Contact Support to see if it may be possible to manually reset the migration.


Why is cancelling my migration taking so long?

There is no approximation, estimate, or SLA on how long an undo process may take as the degree of knowledge customizations and the underlying process are variable. It's not uncommon for the undo to take several days to upwards of over a week or more to complete.

If you're waiting for the undo to complete for a long period of time:

1) Check Setup Audit Trail to ensure that no changes have been made to Knowledge. As per the documentation, "WARNING Do not make any updates to the Knowledge Object in the Object Manager before accepting or canceling the migration. If you do, Cancel stops working." Reference: Migrate Multiple Article Types.

If changes are found in the setup audit trail, you may need to reverse them in order for the undo to successfully complete.

2) Check whether you may have received an email notification with the subject, "The Knowledge migration UNDO operation failed"

If your org has created dependencies on the new Knowledge__kav object this will prevent the undo process from completing. Review the Email which should provide details on the dependencies preventing cancellation.

Once those dependencies have been removed you may need to manually hard delete the Knowledge__kav article type that was created during the migration process before the undo can proceed.

Navigate to Object Management Settings in Lightning Experience or in Classic open Setup, enter 'Knowledge Article Types' in the Quick Find box, then select the 'Knowledge Article Types' setup section.
 
  • If either location contains a 'Knowledge__kav' object in an undeployed status manually delete and then hard delete it so the undo process may be able to finish. See Delete an Article Type for instructions on deleting the 'Knowledge__kav' object and then in Article Types setup, locate the 'Deleted Objects' list and click 'Erase' to permanently remove or hard delete the object.
 
  • You can monitor the status of the hard delete job by Monitoring Background Jobs. The corresponding entry 'Job Type' should read: 'Cleanup of custom entity data when a custom entity definition is hard deleted.' Once those job status show complete, the undo should finish. There may be unexpected circumstances where the job status shows complete however, the hard deleted Knowledge object is still persisting. If you expect this may be the scenario, please log a Case to investigate further, ask Support to reference the Internal Information section of this article and provide permission for Support to manually run the process to purge the lingering Knowledge object.
 
3) If your migration included files, the cancel process may need to wait for the scheduled physical delete job to run against your organization to effectively purge the files created as a part of the migration process.
 
  • If you're unable to wait for the physical delete to process naturally or are unable to proceed with cancelling, please log a case with Support to investigate further. Support can verify whether an unexpected issue may be occurring or if the process may be waiting on physical delete. Support may initiate a manual physical delete if you provide and document explicit permission to initiate one against your org.
 
We can’t start migration until you’ve resolved these errors: You can’t migrate an article type called “Knowledge” when starting the migration assistant.

This error occurs if your org has an existing Classic Knowledge Article Type with the Label and Object Name, "Knowledge" see the article Error 'You can’t migrate an article type called “Knowledge”' on Lightning Knowledge Migration Tool for more details.
 
 
Why are we receiving a 'This custom object is used by another feature.' message when trying to Accept the migration?

We can’t complete the migration for the following reasons:

Cannot complete this operation. This custom object is used by another feature. Remove the usage and try again. <ReferenceHere>

The error is received when the migration process is unable to delete your old article types due to existing references. Customers may use the Developer Console to search '*__ka' and '*__kav' to find potential Apex code referring to old article types. More details are outlined in the bullets under step 13 in the Migrate Multiple Article Types documentation.

Note: Metadata analysis to list all references is not within the scope of Support's offerings. This process needs to be completed by customers.

If a Developer can verify that all related references have been deleted but you're still seeing the dependency message and unable to delete the old article types, please log a case with Salesforce Support to investigate whether a script may be required to manually remove lingering Apex dependencies that may be unexpectedly persisting in the background.
Knowledge-artikelnummer

000385080

 
Laddar
Salesforce Help | Article