We all read many articles about the benefits of Lightning Migration: new awesome features exclusively in Lightning, a great user experience, enhanced user productivity, customization and personalization possibilities for business teams, custom lightning components developments possibilities, an opportunity to reengineer business processes, great apps or components on the Appexchange, Einstein features, App builder configuration tools, increased collaboration, and so on.
There is a collection of articles listing and describing in detail those benefits by typing “why to migrate to lightning” in your favorite search engine. And the list of reasons to migrate keeps expanding with Salesforce efforts to bring new features in their Releases.
Why should you move from Classic to Lightning?
In my opinion, last year has been fatal to Classic with Spring 18, Summer 18, and Winter 19. I think the Spring 19 coming will bring the coup de grace. I do not see any excuse not to migrate (except maybe if you have a 15 years-old org with many many VF pages, apex code, and custom features, and no good practices applied, then you should start on a brand new fresh org :-) ).
The feature gap no longer exists or is really insignificant compared to the benefits. The ROI of migrating is shorter and shorter (immediate in many aspects), and above all end users are in demand to move to a platform that is an accelerator, an assistant, and not a constraint for their day-to-day job.
I met many users complaining about Classic. Not only because it’s an old-style UI, but also because all the clicks and scrolls give them headaches, navigation brain knots, wrist tendonitis by manipulating their mouse, and increase their stress (I am not joking).
In addition, it also implies difficult onboarding for new users. I let you imagine the consequences on the business and HR teams whether you are a Sales or Customer Service rep. There is no discussion about migrating or not, if you haven’t done it, rush into it for the sake of your users and your business.
Ressources on Lightning Migration
Articles exist on how to convince your management to give you the budget to do it, I do not worry they will agree. Salesforce and the community put at our disposal many tools to facilitate it, here are some: Lightning Transition Toolkit, Lightning Usage App, Convert attachments and Google Docs to files, the “move actions and buttons easily when transitioning to lightning”, etc, etc … the Lightning Now group in Trailblazer community can also help you and of course this great Trailmix, among others.
When you are a Salesforce Admin, with a several years old org in classic, with regular new requests from the business teams, daily issues to solve, you never or rarely have time to clean unused fields, page layouts, refactor your profiles and permission sets, workflow rules, process builders, validation rules and so on.
Normally, you are often forced to procrastinate it. Of course, if you are a champion and applied best practices from the beginning you don’t have to do it. You can migrate in the blink of an eye and it’s probably already done :). But in most companies, I had the opportunity to work with, they had an old Salesforce org, several admins and service providers succeeded one another.
Without properly documenting what they have done, without cleaning their desk before going to another customer, without filling the description fields, and leaving much useless dust in your org. The technical debt has increased and the org became less scalable, the time to market for new features is less and less acceptable for end users. Also, you find lots of orange and red flags when running the Optimizer.
The solution?
Migrating to lightning is THE opportunity to clean up your org, like the spring cleaning you give to your house once a year, reconfigure all rooms, optimize storage, make it feng shui, and modernize the decoration! It’s also the opportunity to come back to standard features because you developed them before Salesforce released it as out-of-the-box.
Let’s migrate to Lightning and seriously improve your Org!
Once you make the decision to move to Salesforce Lightning, you can start the migration. I would recommend you insert the following list of actions in your lightning migration plan. This is not an “All or Nothing list”, you have to adapt it and sequence it according to your lightning roll out Strategy (big Bang, phased, parallel, or whatever J ). Here we go:
1 – Launch analysis of fields usage for all objects having many custom fields
Config WorkBook and Field Footprint are great tools to perform this analysis. Organize workshops (well prepared) with key users, and question the utility of all custom fields based on this analysis. Flag those to be deleted or merged.
2 – Review all page layouts with key users
Organize efficient workshops, and question yourself about their relevance and merging possibilities. You can use FLS to diminish the number of page layouts to manage.
3 – Review workflow rules and process builders
See if you can optimize and factorize them, maybe delete some, and review their trigger conditions to improve performances when you migrate to lightning. Replace any profile or record type label reference by IDs, and implement custom permission when possible. Read this great article to understand Why we should use Custom Permissions.
4 – Review all validation rules
as for workflow rules and process builders, replace profile and record type labels by IDs and use Custom Permission (to allow exception bypass for example).
5 – Try to replace custom code (Apex triggers) with Flows
Which can be called by Process builder, global, or object specific actions when relevant. It’s much simpler to maintain and you do not need Test Classes to deploy. You can deactivate them in one click instead of a deployment for triggers. Of course, it’s not mandatory, as Triggers offer possibilities not available in Flows (special dedication to my developer friends J ).
6 – Review all lists views
Including private list views built by users in order to: merge duplicate ones, delete useless ones, and make public with appropriate sharing settings the useful ones which were private. Winter 19 brings that useful Classic feature to Lightning.
7 – Get rid of unused Installed Packages!
They pollute your org and your users if you do not use them.
8 – Review all custom features
And search if Salesforce has released it in one of the releases after you implemented it. If yes, take the time to implement it if it fulfills the initial needs. You might benefit from improvements in the future and get rid of custom functionality to maintain.
9 – Reports & Dashboards :
– Build a report on reports to review Last Run dates.
– Identify unused reports to be deleted.
– You can also do the same with Dashboards by listing the Reports on a . dashboard and their last run date (Last refresh date does not exist unfortunately). Here is how you can do it for dashboards
– Review Reports and Dashboard folders sharing settings. Besides, Summer 18 brought the Sub-folder feature to better organize them. Config WorkBook allows you to download in excel all folder permissions. It makes it easier to have the whole picture and design a good tree view with appropriate sharing settings
10 – Last but not least: Refactor your Roles, Profiles and Permission Sets
– Again, you can use Config WorkBook to download in Excel the full existing configuration of your profiles and permission sets. You can also use it to compare profiles and see differences in terms of OLS, FLS and user permissions. The is also a great Update functionality for OLS and FLS, you will gain tremendous time and avoid errors.
– Review the model of your roles, profiles and permission sets. Paul Cooper has done a brilliant diagram to illustrate the way Salesforce works. Remember that simple is beautiful, roles should be grouped together based on the necessary access level to data based on sharing rule requirements.
Use a minimum of profiles, they should be linked to the job (Sales, HR, Customer Service, Marketing, Finance …) and the Permission Sets should be linked to the function or responsibility (Sales Manager, Sales Rep, HR Manager, CFO, CMO, CSM …). Following this practice will allow you to keep the number of Profiles and Roles low. Also, prefer to open doors, rather than to close them.
The best practice is to set the minimum of rights to the Profile and OWD and use Role Hierarchy, Sharing Rules and Permission Sets to open the doors. And finally, try to be generic, permission sets must be reusable and created only if necessary. For example if all users need to have CRUD access to accounts, create only one PS, not four. Or one PS for CRU and one for Deletion right as it can be a more sensitive right
Those steps need to be planned
Again, there is no rule on when and how to perform them. It depends on the lightning migration project organization, its size, the number of users to migrate, and your rollout plan/strategy. I believe it should be a prerequisite to a lightning migration (Profiles and Permission Sets refactoring for sure). However, some steps can be performed alongside the configuration of your new lightning Apps, Pages and Components.
When you are done with that cleaning, it is also important (non-negotiable actually) to get a proper documentation. Try to build and maintain the data model of your org.
ALL description fields (objects, fields, profiles, PS, workflow rules, flows, validation rules, process builders, apex triggers and classes, approval processes, and so on ..) must be filled with a readable and understandable description. Anyone in the Salesforce team (admin, app builder, developer, product owner …) should be able to understand why that field exists, what that process builder does, and what rights that permission gives, only by reading that description. While you are cleaning, do not forget to fill in the empty descriptions.
Of course, by doing that cleaning and refactoring with the lightning migration there is a chance to slow down the migration project. It’s a long work, but it’s worth it. You can start that cleaning during the migration and finish it afterward. Be rigorous in your migration plan and take the time to optimize the sequencing and parallelization of all the tasks. Your Org will become flexible, scalable so that it can adapt easily to your evolving and growing company.
Want to learn more? Read our article about how to Manage nested Object in your Lightning Web Components?
