Table of contents
Subscribe to our newsletter
We loved this post from Brett Barlow so much, we just had to share it! Hear how Brett tackled the Salesforce Lightning migration over at Postmates and how you can do the same! You can view Brett’s original post here.
In April 2018, I led the Salesforce Lightning Migration at Postmates . This is how I would do it over again if I could.
Define goals
The goals of a Lightning Migration are:
- Enable Lightning Experience
- Configure Lightning Experience
- Document all Salesforce processes
- Create training and support materials
- Lightning Experience is adopted
Easy enough right? Let’s go though the plan to see how we accomplish each one.
Enable Lightning experience
Just turn it on right? Well, kinda.
Although it may be controversial, I recommend turning it on and hiding the option from all users. This can be done by removing the Lightning Experience User permission from your custom profiles.
And yes, turn it on in production.
Why? You’re going to turn it on anyway. Salesforce has declared this as the path forward, so you either turn it on now or wait until they flip the switch for you.
Plus, turning this on ahead of time will make deploying from a sandbox much easier. Trust me.
Goal #1 Enable Lightning Experience – check!
Learn the basics
Before you get in there and start messing with stuff, take some quality time and learn the product. My recommended sources of learning are:
- Trailhead
- Specifically the Make the Move to Lightning Experience trail. Do this first.
- Release Notes
- While it may see odd to learn from the Release Notes, the Salesforce product teams are constantly pushing out new features for Lightning. Have a read through these to see what catches your eye
- Documentation
- It goes without saying, but there’s no substitute for looking at the docs
Write down ALL of your Salesforce processes
I know I sound like a crazy person, but you need to write out ALL of your Salesforce processes. By write out, a simple list containing the names of the processes your users do in Salesforce will work.
You’ll probably have stuff like: Log Calls, Send Contracts, etc.
Is your list really long? Probably.
Is it going to be easy to finish everything? Probably not.
Should you finish everything before going live? No.
The value of doing this exercise comes in two parts:
- Now you know exactly what you have to accomplish to fully migrate to Lightning
- You will know exactly which processes are still done in Classic. This means anytime someone has a question about if a feature is in Lightning or Classic, they can go to this document and find out.
Identify your champions
Having buy-in from business users and management is key to a successful rollout. I recommend selecting people who are already good with Salesforce and excited about new features.
Your champions will also be key in providing you feedback as you build things out. You’ll want to show them what you’ve built and iterate on it until it’s just right.
Start building something
Pull something from your list of Salesforce processes. It doesn’t matter where you start, but make sure it’s something simple. The most important thing is that you’re able to get your hands dirty.
The goal here isn’t to make it perfect. Start building this right in production and spend no more than ~3 hours on each item. If it’s taking longer than that, see if you can break the process up into smaller parts. Update your list of Salesforce processes if you end up breaking things up.
Show and tell
Once you have something ready to show, schedule a demo. Be ready for a lot of questions during the first few of these. People can go a little cross eyed when they first see Lightning.
After the demo, analyze the feedback you received. You should try and understand if what you’ve built will work for those who saw it. While it doesn’t need to be perfect, it needs to provide a good user experience. Continue making tweaks and doing demos until you receive positive feedback.
Documentation
Remember that long list of Salesforce processes we made at the beginning? Time to cross something off the list right!? Wrong.
Instead you should add documentation for the process. I’d recommend adding the following for every process you complete:
- Summary
- Step-by-step directions
- Screenshot or video
If the process is complex, I’d also add a FAQ and information on where to log bugs or ask additional questions about the process.
The goal of your documentation is to make it as self-service as possible. When launch day comes, everyone should have everything they need by going to this document.
I recommend organizing your documentation by team, with a section for shared processes. This will enable someone to come to the doc, find their team, find the process they had a question about and resolve their question by themselves.
When to go live?
I recommend going live when you have all major processes for one team migrated to Lightning. Don’t move a team to Lightning if they will constantly be switching back and forth. Some switching is okay, but too much and people will get discouraged.
The biggest takeaways you will see from getting your first team into Lightning are:
- The quality of your documentation
- Making an ally or an enemy
You’ll know pretty quickly how good your documentation is. When you launch, you’re bound to get a lot of questions. You should direct them to the documentation every time . Don’t waste your time answering the same question over and over. If you don’t have it documented, add it to the docs in a way that everyone can find the answer.
You will make many allies if people are starting to use Lightning and having a great experience with their new processes. This positive momentum is crucial for Lightning to roll out in other teams.
If the new processes are painful, you will need to listen to where the pain is coming from and address it ASAP. Iterating on painful processes needs to be your first priority after going live. If there is too much pain for too long, you will make enemies. People will switch back to Classic and it will be more difficult to get this team to adopt Lightning.
Once you have built (or re-built) everything needed for a team to go live, you have completed goals 2, 3 and 4 for that team. You should move on to goal #5 for this team, but continue on goals 2, 3 and 4 for other teams.
Goal #2 Configure Lightning Experience ✅
Goal #3 Document all Salesforce processes ✅
Goal #4 Create training and support materials ✅
Monitoring adoption
Monitoring the usage of Lightning is key to a successful implementation. I recommend using the Lightning Usage app to monitor adoption. This app comes with all Salesforce orgs and is accessible via the App Launcher. If you don’t see it, check your profile settings.
My favorite features of this app are:
- Daily active user stats
- Information on when people switch to classic and where they switch from
- Load times of most commonly viewed pages
By monitoring these dashboards, you can work to understand what is preventing people from adopting Lightning. I recommend to document the concerns and your responses to them so you can share this with other teams.
Goal #5 Lightning Experience is adopted ✅
Summary
That wasn’t too bad, huh?
Well, I guess it does seem like a lot.
And, will probably take a while.
But you got this! Follow this plan and your implementation will be successful!
Remember, start by learning Lightning. Don’t dive in before doing your homework.
Once you have a good grasp of it, write out all of your Salesforce processes and group them by team and then into a section of shared processes.
Build, demo and iterate on each one until you have created a good user experience.
Add documentation for each process so that anyone who is confused can get clarity on what the new process is. This will be key so that you’re not overwhelmed by a ton of questions on launch day.
Go live when you have built and documented all processes needed by a single team. During go live, focus your energy on any processes that are now painful for that team.
After going live, use the Lightning Usage app to monitor adoption.
Good luck!
About the Author
Brett Barlow is a self-taught, San Francisco-based Salesforce Engineer who has worked on the Salesforce platform since 2014. He currently holds 10 Salesforce Certifications, is a Dreamforce speaker and has worked on 15 Salesforce implementations. Read more tips and best practices from Brett on his blog here .
