Salesforce: Classic to Lightning Experience Migration

It has been four releases since Lightning experience was first launched by Salesforce. We could see gaps being closed release after release. Lightning experience is maturing & becoming more meaningful. Coming Winter ’18 (Oct 2017), Lightning experience is expected to be on par with Classic & many new modern day CRM features would be available exclusively in lightning alone.

With all these developments, Migrating from Salesforce Classic to Lightning experience trend has already began. In the next year or two, we could see more & more customers opting for Lightning migration.

Based on my experience working on classic to lightning migration projects, I have put together a checklist which could be used during initial assessment & solution design. I would like to share the checklist items in this article,

Custom/Visualforce Components:

• Analyse the UI components used in the Visual force pages & check for the availability of equivalent component in Lightning Design System (LDS) referring this link
• Check for the usage of the third party Java script (JS) frameworks and decide if those frameworks are supported in Lightning. Lightning doesn’t support all JS frameworks and the list of supported JS frameworks can be found in this link
• Custom pages can also be developed using UI development apps such as SKUID, Grid Buddy, etc.. check the availability & impact of using these kind of tools in Lightning. For Instance Grid Buddy is not yet compatible with lightning. In such scenarios we may have to look for equivalent lightning ready apps or develop custom lightning solution using LDS
• Salesforce classic’s Custom Java Script Buttons functionality is not supported by Lightning. Refer to this link to find the alternatives in Lightning Experience
• Custom components developed using lightning & are added to Record detail page will only appear in Desktop Experience but doesn’t appear in SF1 app. For the customers with similar requirement & the need for custom component to work in both Desktop & SF1 app, we need to plan an additional effort of 5 to 20 % (based on complexity) to make the component work in SF1 app using Lightning Actions.
• If some of the existing visual force functionality can’t be migrated to Lightning, we can take an approach of making Classic pages look like Lightning. This option should be exercised only for the must have features which can’t be migrated to Lightning due to the current limitation of LDS

Standard Extensions:

• Check if the customer is using Salesforce Classic Mobile app which will retire on Dec 1st 2017. Review the app, based on the business requirements & customizations decide if the app can be converted to/created as SF1 or Custom Mobile app (Mobile SDK) solution
• Check for the Communities, type (partner or customer), customizations and the business requirements. These are to be recreated using Salesforce Lightning Bolt community framework
• Open CTI functionality, is supported in both Classic & Lightning experience but there are some functional differences which are listed in this link.

Admin/Config:

• At present, all the Standard objects available in Classic are not present in Lightning. List & Review the list of Standard Objects which are currently used by the customer, ensure the availability of these objects in Lightning & plan the next steps accordingly
• Lightning Record Home pages at present are quite simple & only shows couple of List views. If the customers org. Record Home Page has multiple views (Config./Customization’s) these views won’t be switched to lightning automatically. We may have to consider developing custom Record Home Page app in this scenario
• Calendar Sharing and Ownership is not supported in Lightning yet. This is a major limitation for the customers in need of this frequently used feature
• If the customer is using any apps, see if these apps in the app exchange are available in lightning ready mode. If not do the following & decide,
  1. Check the time frame by which the existing app will be made lightning ready
  2. Check for similar solutions in app exchange which performs the same functionality
  3. Considering developing a custom Lightning solution to meet the similar requirements

Generic:

• Refer to roadmap to see if missing functionalities are coming in the upcoming release. Design solution considering road map & appraise customers accordingly. The current road map can be found here
• Be familiar with the Limitations & known issues in Lightning. The current list is available in this link

Classic to Lightning Migration activity can range from simple to quite complex. Based on the modules implemented in the project, we may have to cover multiple functional areas. In this blog, I have only covered the functional areas which were part of my projects. Though this checklist is not exhaustive it serves as a good reference to understand the approach & the key areas to be focused during Migration assessment & solution design phases.

Do share your feedback & migration experiences 🙂

.. Prashanth N ..