Edith Valencia-Martinez, Salesforce Certified Developer, recounts her experience of migrating to Salesforce Lightning Experience and the key lessons learnt along the way.
Recently I was part of the team that migrated Desynit’s Salesforce org to Lightning Experience. By participating in this project, I learned some lessons that I would like to share in this post.
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
These reports were very helpful as they included a prioritized list of the elements that required our attention. They also suggested alternatives for the functionality that is not supported in Lightning Experience. The only thing to be aware of is that the use of actions of type flow is not suggested in the reports. This feature is useful for replacing Javascript buttons and is much faster than developing a Lightning component for each as is suggested in the report.
Time estimations
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.
Visualforce pages
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.
- Updating the Javascript jquery libraries versions to a LockerService compatible one.
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 – Javascript
Javascript’s buttons and links are not supported on Lightning Experience, for this reason I had to replace them all. The main use of the Javascript buttons in our org and their Lightning alternative that we implemented are as follows:
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.
