Migrating To Lightning

This year again, I was pleased to be accepted as a speaker at London’s Calling (Europe’s largest community-led event for Salesforce professionals) on February the 10th, 2017.

London's Calling 2016

After last year’s talk on Person Account that many of you still mention to me, I thought I would come back with another return on experience: Lightning migration projects.

A strategic move

We’ve done a few of these projects where Lightning is positioned to address a particular need (mobile roll-out) or is the cherry on the cake of a process re-engineering project. It’s rarely the case (read “never so far”) that a customer would contract us for the sole purpose of migrating to Lightning. Still, there’s a strategic reason why a CIO would do so: it’s a common interest shared between the customer and the vendor which makes it a particularly good deal.

  • For the customer, migrating to Lightning means moving to the fast lane. Yes, you can still progress in the slow lane (Classic) but isn’t it the role of a CIO to provide the best tools to the business (Lightning)?
  • For Salesforce, Lightning simplifies the engineering team’s life when it comes to improving the user experience. As a result, more goodness is coming out of the Lightning garage than the Classic one.

A faster way to configure

Another significant benefit of Lightning is the change in configuration paradigm. Designing a solution used to be the matter of two options: declarative vs. programmatic. Well, there’s now a new kid on the block, it’s called componentization and it’s a revolution. I won’t go too much into the details, but components are these little configuration bricks, features that Salesforce doesn’t provide out-of-the-box and that you purchase from the AppExchange for Components. They bridge the gap between the frustration of declarative only and the risk of technical debt coming with programmatic.

Once you understand the big picture, you see that migrating to Lightning is a key strategic move. So much so, that I could understand an executive decision to switch over.

⚠ Wait! There’s a problem. Although Lightning has been around since Winter ’16, it’s still work in progress and is far from being completed. So, you can’t turn the tap on just because it make sense, as you could, in fact, break things!

Suggestions for your rollout

And that’s where my presentation kicks-in. In the below slides, I share resources to identify when is a good time to move to Lightning and how to do it.

In a nutshell…

  1. 🚀 Don’t underestimate the preparation effort
  2. 🌲 Do the Trailhead module LEX Rollout
  3. ⚡ Identify Lightning feature gaps and benefits
  4. 🎁 Consider migrating apps separately
  5. 👧 Consider migrating user types separately
  6. 🍻 Prefer a like-for-like approach
  7. 💋 Drop in some Lightning sexiness
  8. 💐 Include change management in your project
  9. 🚒 Involve your users in a proper UAT

Managing change

I thought I would highlight one side of the project which is often neglected, point 8 above: change management.
On the same day I was presenting at London’s Calling 2017, I attended a session titled “Tackling the ‘We’ve always done it this way’” by the excellent Louise Lockie. I suggest that you check her presentation since correctly managing change is key in any Lightning migrations.

Have a think about it:

  • Your users are not as passionate about Salesforce as you are.
  • Your users are not (yet) as excited by Lightning as you are.
  • Your users are about to have their habits changed by the new UI.
  • Your users will need to relearn how to do things they’ve done for years on Classic.

A successful Lightning migration project is about 50% technical considerations and 50% change management.

I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.

Fab 🐸