Skip to main content

Salesforce Lighting Migration: Plan for Success

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:
  1. Enable Lightning Experience
  2. Configure Lightning Experience
  3. Document all Salesforce processes
  4. Create training and support materials
  5. 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 ✅

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:
  • 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:
  1. Now you know exactly what you have to accomplish to fully migrate to Lightning
  2. 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.


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:
  1. The quality of your documentation
  2. 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 ✅


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!

Other Relevant Posts

Use the samples here to get a head start on building your Record Pages.

Understanding why they'll switch back to Classic is the first step in keeping them in Lightning.


Popular posts from this blog

SOQL from the Command Line

SOQL and the Command Line go together better than peanut butter and jelly. Here's why.
Once upon a time, I got tired of running Salesforce Reports to get miscellaneous data. I found Workbench and started using their interface to run SOQL queries. This was great for a while, but I knew there was a better way.

Pro-tip with Workbench: If you set a browser bookmark after your query runs, you can return to that bookmark and it will re-run your query!

Enter the SFDX Command Line Interface (CLI). Get ready to take your productivity into hyperdrive! 🚀🚀🚀
sfdx force:data:soql:query If there's one command you learn, this is the one. All you have to do is pass a query string into the -q parameter and you're in business. Check it out:
-r | --resultformat This is my 2nd favorite thing. How often do you need to export a csv from Salesforce? And how annoying is it to make throwaway Salesforce reports each time? Yeah, it's the worst.
-r to the rescue! Just add "-r csv" to …

Why should I use SOQL?

You need data, fast!
Whether it's exporting a csv or answering a question, SOQL can get you the result much faster than creating a Salesforce report.

My top 3 reasons to use SOQL are:
Get data fastGet answers fastFlexible access Get Data Fast How often do you find yourself making a throwaway report to check what is happening in the system? For example, you updated your Lead routing and want to see if it's been assigning Leads as you expect. Well you could make a report, run it and review the results. Or you could run a SOQL query.
The benefits of running a SOQL query in this case is that you can retrieve different data sets much quicker. In a Salesforce report, you are stuck with the Report Type you selected when creating the report. With SOQL, you can traverse object relationships in a much more natural way. Get Answers Fast Have you ever been in a meeting and someone asks a data question that no one has the answer to? Well SOQL comes in handy here because you can run a quick …