It’s important to mention that we split the migration work in tasks for admins and tasks for developers. This post focuses on the lessons learned purely from a developer’s perspective.
In summary, these are the lessons that I learned from my participation on this project:
Lightning Experience Reports
We used the reports generated by Salesforce as our guide on the migration:
- Lightning Experience Visualforce Report
- Lightning Experience Readiness Report
I spent 120% more time on development tasks than the recommended time estimate that was specified in the readiness reports. Unless you are very knowledgeable on all the features in your org, you will need to spend additional time finding the exact elements mentioned in the report, understanding their functionality and then testing them in Lightning Experience.
Time consuming tasks
Surprisingly, the majority of the migration’s development time was spent on replacing custom buttons and links instead of adapting Visualforce pages. This was predominantly due to the fact that in several cases I had to create Lightning components as a solution, which is much more time consuming than simply creating an action.
For all of you interested, a more technical and detailed description of the migration work performed is included in the next sections.
I had to make sure that the Visualforce pages were LockerService compatible. This task involved:
- Making sure that no Visualforce page was using the window object.
I also incorporated the lightning design system to some of the pages by adding the tag <apex:slds />.
In general, the majority of the Visualforce pages worked correctly in Lightning Experience. Although it is important to note that I did not find a suitable alternative for detecting when the user leaves a page. This functionality couldn’t be replicated in Lightning Experience as the use of the window object is required.
Custom buttons and links – URLs
Although these buttons are still visible in Lightning Experience, I had to replace most of them as they were not working as expected.
The main use of the custom buttons and links in our org and their Lightning alternatives that we implemented are as follows:
In general the use of actions to replace some custom buttons and links was fast and easy. The only issue I had was that actions on cases show in the chatter feed and not in the page-level action menu. For this reason I had to redefine a page to include just the minimum required fields on it
In summary, migrating to Lightning Experience takes time and effort. Having said that, the readiness reports that Salesforce provide are a useful guide for the migration as they include a list of the elements that need your attention.
In addition to the benefits that Lightning Experience offers such as a modern design, enhanced functionality and added security, we also found out that the migration was a good opportunity to revisit all the functionality in our org and to redefine some processes and pages. It was also a great exercise of uncovering functionality that we no longer use.