What is Salesforce Lightning?
More than just a new, more modern-looking skin, it’s a completely different UI for Salesforce.com (SFDC), it really is mobile ready (if not yet mobile optimized) and it really has completely different technical underpinnings than SFDC’s Classic UI and VisualForce. SFDC’s engineers have put a ton of thought and hundreds of man-years of development effort into the user experience, technical infrastructure, APIs, tools and documentation (both the “Trail Heads” and classic reference docs).
Lightning has gotten significantly faster over the last couple of months, and users updating to Firefox’s Quantum release will find everything very snappy indeed. Chrome users now have a reasonable choice if they want to switch browsers.
Lightning is not to be taken lightly. The features for independent software vendors (ISV), developers, sysadmins and users have not completed their transition, and the majority of the integrator and user community have only sketchy experience with Lightning. So, like any big technology transition (think SunOS to Solaris or MacOS 9 to MacOS X), there are more than a few things to think about – if not wait for – in making the leap.
How to decide when to move to Salesforce Lightning
All the above said, your decision-tree is incredibly simple if you’re a Greenfield implementation of Salesforce (with literally no users, no developers, and no sysadmins steeped in Classic UI): for you, it’s go directly to Lightning (do not pass Go, do not collect $200).
All the latest features are available only there, and it is the future for all SFDC users. Some things you might want (particularly in third-party plug-in apps) might not be fully Lightning enabled yet, but they will be soon. There are conceivable Greenfield situations where Classic might appear more suitable at the moment, but any possible advantage will be negated shortly, and any short-term advantage will be more than wiped out by the extra friction of transitioning to Lightning later. So—you lucky newbies can stop reading this article right after completing this sentence: even if you go Lightning-only from day one, your system administrators will still have to learn the Classic UI and navigate in both worlds for the next couple of quarters. Newbies, get off this bus now.
What is not supported in Salesforce Lightning?
Those simple answers are definitely not true if you’re an existing Classic shop, and the kimchi gets deeper and spicier the more sophisticated your existing system is. Let’s explore why.
First the obvious stuff: What users see
Some of the features users want simply aren’t available yet on Lightning. With each release, this list has gotten shorter and shorter…but every week or so I still discover some niggling detail where Lightning isn’t at parity with Classic. While there’s almost always a work-around, just as often it involves some investment that will be thrown away in 6 or 9 months. Just plan on this—budget for it in your transition proposal.
There are some Classic features that will never be re-implemented…almost always, for good reason. You’ll just have to figure out a substitute and talk any irate users off the ceiling, convincing them that their pet feature (for example, having up to 10 columns in related list displays) was bad for them all along.
We also have to face the fact that some App Exchange goodies (particularly the freebies) won’t make the transition to Lightning. See below for how to cope with this.
And then there’s the subtle stuff: What IT will experience
I cannot say this clearly enough: the coding learning curve is steep and long. Lightning has very powerful new abstractions that will make apps much more responsive and capable, but you’ll have to learn several new techniques before you can deploy your first usable Lightning code. Since there aren’t many Lightning code samples yet, your developers will be wandering in the dark, bumping their heads against strange stack traces for the next several months. Yes, I said months…so put that in your schedule before you promise delivery dates!
Because SFDC needs to operate in three end-user modes (Classic, Lightning browser, and Lightning mobile), there are some really icky parts of the application configuration cycle. The most obvious example is page layouts, which have both profile assignments and app/profile activations. App builders and admins will have to develop some new reflexes and muscle-memory.
That issue goes double for the administrative interface, as there are at least two versions of the Classic setup menu and Lightning completely revises the admin’s navigation model. Guess what: admins will need to be comfortable with both setup UIs because there are still several items that can only be controlled from the Classic side.
Salesforce Lightning migration guide
For all these reasons, it should be obvious that the last thing you want to do is transition your entire organization over to Lightning at once. If you still want to do a full changeover now, that’s a high-sticking infraction and you’re in the penalty box for the next six months (but by then it might be OK).
Almost invariably, you’ll need to run your organization in both Classic and Lightning for quite a while. Plan on that.
Users should be moved to Lightning when there’s a business case for doing so, and some sales manager saying “but it’s so pretty” is not a good business reason. For example, if Account Management needs to be more professional about managing ongoing relationships, Einstein’s InBox feature is demonstrably helpful and will pay off the costs of the transition for that user group only. Typically, all the users who are direct participants in a single business process element (e.g., renewal order generation) need to be moved at once, but lots of other users in the bigger process (e.g., renewal order entry or collections) can stay in Classic without any problems.
Once the transitioning users have been identified, they probably will need a new SFDC profile. They’ll need their own home screen, views, page layouts, dashboards, and lots of new buttons/links. Some dashboard elements will have to be replaced with VisualForce. They’ll also need lots of other things rebuilt or fixed – SFDC’s Lightning Assessment Tool will give you a good starting point for assessing how much.
Of course, some features and App Exchange modules just aren’t there yet. Budget some time for researching and testing alternatives, and explicitly set expectations with users about how long it will take before the replacement feature is ready. To state the obvious, this should be calibrated in quarters, not weeks. The watchword is UPOD.
The key success factor for all your development (both configuration and coding) is test early, test always. When deep into Lightning, things just won’t work the way you assume they do (make sure to test on the target browser version). Some of the changes you make may temporarily confuse browsers, since Lightning caches a lot of state and data to improve performance. You’ll want to publish a cheatsheet for your users telling them how to clear the cache on their particular browser/OS combination.
Do not deploy to anyone (not even pilot users) until you’ve developed and used new training materials. There are so many details that are different (sometimes, browser-specific variations) that you will drastically undercut your credibility if you don’t get users acquainted with the new world first. Little things like page-up / page-down keys and ctrl-F behavior will frustrate uninformed users and admins alike.
A final warning
Once you succeed transitioning one group of users, follow this same rigor for the next groups. You must avoid a mob scene that is a natural result of people seeing a bright shiny object that they aren’t allowed to have yet. A word to the wise: get management on your side in writing on this specific issue before you even start with the first group’s migration.