Check out our 10 point best practices method to plan a smooth migration that will seem tailor made just for you.
The demos and discussions about the new age of Salesforce Lightning have created a buzz everywhere. Statistics show that with Lightning, you can save up to 25% of the time developers spend building customizations. You can also boost productivity and save up to 10 hours per employee per week. 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 the teams involved. Failure to do this will result in moving backward 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 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 development 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 your 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.
“Rewind and start again. You need to work out all the kinks at this stage before getting everyone on the new system. Correcting errors at a future stage could be next to impossible.”
time saved on building customizations
time saved per week per employee
Ask us anything. From basic questions to complex queries.
We’re ready to talk to you : 470-395-0200
or drop us line at