The demos and discussions about the new age of Salesforce Lightning have created a buzz everywhere. While this is not a must at the moment, it might be a good time to spend time getting accustomed to the new and amazing features that are currently available only in Lightning.
One of the biggest hurdles to a universal shift from Classic to Lightning is that some organizations are either not ready operationally or just don’t need the functionality enough to make the shift. However, rapid changes in consumer demands and the need to adapt for success is slowly changing that mindset.
One of the first steps would be to make a clear list of goals for the Lightning migration.
-What do you need Salesforce to do that Classic can’t offer?
-What do you want to accomplish?
Internal processes are often forgotten during and after a Lightning migration. It's critical to work with and train all teams involved. Failure to do this will result in moving backwards rather than ahead.
Every team member has their own favorite feature they can't do without. Leaving them out of the process would result in a poor adoption of the system and resistance to change. This would defeat the purpose of the migration.
With the roadmap laid out, it's time to decide what you hope to achieve with Lightning. Working on a clearly outlined guideline for the develpoment team would avoid future risks to your critical processes. Start with the key Lightning functionality you’re pursuing first and then prioritize features from there.
Plan for any unforeseen problems and make sure you have covered any incompatibilities you might have missed with the help of a Lightning Readiness check. This will help yout team build out a robust migration plan.
With the plan in place, it's time to hit the sandbox running. Work with the sandbox to isolate and test any planned changes and eliminate any effects on other developers' work. It will also help you gauge how the new code would affect the target user.
Once you have tested it in the sandbox, recheck with all the key stakeholders that the new Lightning features you’ve prepared and built will meet their goals as outlined at the start. If not, this is a good time to stop and take stock and correct any omissions. This might take time off your critical go-live date, but failure to check your work now might result in further delays or even failure in accomplishing your goals in the long run.
All done? But hang on, it's not yet time to set the town crier to work. Before you launch, start with a test group of pilot users. With multiple individual users in the system, you can work out the kinks in the Lightning migration and ensure that the functionalities match each user group's requirements.
The most important step is to document everything. You need to have a reference document that will outline how the functionality will be released. It would be ideal to create a living document with all team members updating and adding to as needed.
Pat yourself on a job well done so far and share the good news with everyone. It will be a walk in the park to train all users with the detailed reference document you have created. Although, do remember to conduct the training before making the changes live. Your pilot user group would be your strongest ally in getting the functionalities accepted.
With everyone on board with the Lightning version, it's time to revitalize your team efforts and achieve your targets. The living document will ensure all future changes are tracked and you are ready with reference resources in the future.