Transition to Lightning in Four Steps

Learn how to migrate to the Salesforce Lighting UI in four steps. Shell Black in this video presentation discusses how to make the business case to justify the costs to moving to the Lightning Experience (LEX) from Classic. In the four steps Shell covers how to assess the current state of your org, plan out the migration, manage your build sprints and UAT (User Acceptance Testing), and train your end users. He also covers the factors that drive the time needed to complete the project. As you will find, the biggest hurdle to migrating to Lightning is not a missing feature, but Admin knowledge.

View this video on YouTube:

Transcription of the video below with links to additional online resources:

ShellBlack Migrating Lightning Slide 1

Well first off, I want to say thank you for taking your lunchtime with me on the last full day of Dreamforce. How many of you went to the concert last night? Oh, man, you guys are troopers. I’m getting old. All right, so today’s presentation is "Planning Your Migration to Lightning Experience." Part of my duty, as a presenter, is to take you through this slide, the forward-looking statement slide. Formerly known as the Safe Harbor slide.

So basically what it means is, don’t make any purchasing decisions based on any forward-looking statements or anything that I say here. I don’t think I’m going to talk about future release information. But as a publicly held company, we have to present to you this information. So let’s jump into it. I’ll tell you a little bit about myself.ShellBlack Migrating Lightning Slide 2

I’m Shell Black. President of We’re a Salesforce consulting partner. I started doing work with Salesforce back in 2005, as a consultant. I did that for a couple years. I used to teach, also, the five-day admin class. Has anyone taking ADM201? Yeah? A couple of you. Great! I started my company back in 2010. I’m a Salesforce MVP. Been a Salesforce MVP for five years. I have four certifications, and this is my fifth year speaking at Dreamforce. So super excited about that.

I do have a YouTube channel out there called "The ShellBlack Whiteboard." Anybody seen one of my videos? Nice. Excellent. So there’s about 30 videos out there. They’re all about trying to help you get the most out of Salesforce, core concepts, best practices. It’s had over a million minutes watched, which isn’t bad considering there are no cat videos. You can follow me on Twitter @Shell_Black. I’m always posting crazy stuff about Salesforce.

ShellBlack Migrating Lightning Slide 3

All right. So I got one slide about my company. So again, like I said, I started back in 2010. We’re a Salesforce consulting partner. The professional services we offer are there at the top. Financial Services Cloud, Pardot, Migrating to Lightning. You can use us for that as well.

A little bit about the firm. We’ve been pretty fortunate over the last seven years. We’ve got clients in 40 states. We’ve delivered more than 600 projects and we’re about a 32-person firm. Half the team is out of the Dallas/Fort Worth area. But we do have folks on all four time zones, coast to coast. So if we can help you with Salesforce, please let us know. You guys ready to jump into this? Yes.

ShellBlack Migrating Lightning Slide 4

All right, so I thought the best way to introduce this topic is to rewind the tape a little bit, and let you think about how fast we are moving on this Lightning journey. So it was in August of 2015 that Lightning was announced. And then shortly after that was Dreamforce. So Marc Benioff, on a big stage, a big demo of Lightning, first time we all probably saw it. Clean, new UI, KanBan boards. Oh, my gosh, look at those dashboards. We were all blown away.

Shortly after that, in 2016, we all got our hands on it, started playing around with it. I think, maybe let’s be honest, some of us were like, well, if you don’t stay on that sales "happy path" that the demo was on, and you start looking in the nooks and crannies, there was a lot of stuff that wasn’t there. I wouldn’t say "half baked," but the foundation was laid, but it wasn’t really robust enough for a lot of us to really consider it.

So I think a lot of my customers, and a lot of people I talked to, we kind of turned our nose up at it and said, "We’ll see if they keep doing this. We’ll see if this Lightning thing is for real." And we just moved on. Well in 2016, a couple more releases. I wrote a blog post in June of 2016. It was my most socially shared blog post ever. It went…I don’t want to say, "Viral," but it was pretty popular. A little bit of lightning rod, pun intended. But the blog post was entitled "Salesforce Classic is Dead – Get Over It." And basically what I was saying is, if you’re not looking at the signposts, if you’re not looking at the release notes, the Salesforce product team is all in on Lightning. This is not going away. We really need to start taking this a little bit more seriously. And I think a lot of us had kind of said, "We’ll see what really happens with this." But Salesforce was really trying to tell us, pretty early on, they were committed to this platform.

So 2016, as a consultant company, it was a really challenging year for us, because we had to make the decision, "Do we put a customer in Lightning? Do we put a customer in Classic?" And the tipping point for us when we were making that decision was, "Could we keep a group of functional users in one UI, in Lightning?" And if we could, we’d implement them in Lightning. If we couldn’t, and there’d be a lot of flipping back and forth, we went with Classic.

So fast-forward the tape a little bit more. Now we’re into 2017. Pretty much all new clients, at this point, that we’re working with, we’re putting in Lightning. And if you think about it, you cannot go to Salesforce’s website and see any screenshots of Classic. If you’re a new customer, and you made a purchasing decision, you don’t even know what Classic is. All you see is Lightning. It’s what your AE (Account Executive) had shown you. So we felt like, in 2017, it would be disservice really to implement anybody in Classic at this point. Right?

And if you kind of think about it, Classic is a little bit of an island at this point. So you can almost think of Classic, in my mind, as Salesforce version 2015. It’s kind of static. It’s kind of like, "Hey, I’m holding onto Windows XP, man. It’s coming back. I know it is." It’s really the 2015 version of Salesforce. Right? It’s Classic. So you can continue to be cloistered off on that island, hoping that you get saved one day. Right? That someone’s going to bring it all back. "Yeah, it’s going to keep going." It’s not, guys. It’s going to be Lightning.

ShellBlack Migrating Lightning Slide 5

So I bet you’re here to try to figure out, "How do we get there? How do we get the rest of the organization there?" The first thing you have to do is convince leadership this is a great idea. Because transitioning to Lightning cost money. I’m just going to put it out there. It’s expensive. It’s going to have admin time, potentially developers’ time, even take users offline for training. You’re going to have to have subject matter experts help you test it. You might even have to hire a consulting company.

There’s business opportunity. You can be working on other things in Classic, but now we’ve got to focus on this migration project that’s going to take you away from other opportunities. So there is absolutely a cost to this. So you’re going to have to get some signoff, and some buyoff from leadership that, "This is what we want our resources to work on?" So how do you sell this? How do you pitch this to leadership?

So I think the first thing you got to look at, if you stay on the 2015 version of Salesforce, which is Classic, you are no longer receiving anymore innovation for your licenses. You’re paying for it. But you are no longer receiving any innovation. All the innovation is now in Lightning. So part of the value of that license that you pay every year, is innovation that we’re all seeing here at Dreamforce. So you’ll miss out on that. So that’s that opportunity cost.

The second thing, you can kind of look at it from an ROI standpoint, or return on investment is, if we took advantage of some of the new features and some of the new innovation, "How could that impact our company?" Right? Sell smarter, better service, better insights to data. So it could be, "Hey, if we had KanBan boards for our folks, they’d keep their opportunities more up to date. If we had lead scoring. We’ve got these inside sales reps that are juggling three or four hundred leads. Maybe they’re going to call the right people at the right time based on that score." Other features.

It could be, "Hey, we could avoid going out to the AppExchange and buying a third-party app because that’s a native feature inside Lightning." A real quick one. It could be that you can now have calendars, and manage your opportunities on a calendar. Or you maybe you want to see your marketing campaigns or what’s coming up next month on a calendar. You don’t have to buy a third-party app to do that anymore. Right? So think of that.

So if you’re thinking, "Well this all great, but I’m not really good at making business cases. It’s not really my job." Maybe you’re a System Administrator, and that’s not maybe your day job, is to make business cases to leadership. Guess what? Through the power of Salesforce marketing, there’s a pitch deck you can download. Seriously. Salesforce is like, "Let me tell you how to sell it?" So that link, in, it’s how to configure a test org. Here are the demo scripts. Here’s a video on how to do it and here’s your PowerPoint slides. Lightning-in-a-Box, baby. You can go out and pitch it.

And if you’re an organization that’s been thinking, or maybe leadership, or someone saying, "Well we can’t go to Lightning because of X feature," that Salesforce puts in help a roadmap that’ll tell you when that feature’s going to be addressed. So if that feature is not going to be addressed from a year from now, don’t start that Lightning migration in a year from now. Have your Lightning project converge when that feature comes available, so you can get to Lightning as fast possible.

ShellBlack Migrating Lightning Slide 6

Here’s another way to look at it. If you migrate to Lightning, there’s going to be some upfront costs. Right? It’s a reality. Again, it’s the opportunity cost. You’re going to have a team working on this. You could be working on other features. It could be administrators, developers, consulting cost. You have to retrain your people. Again, you’re working on this migration versus other things you could be doing as a company. So yes, there’s an upfront cost. It’s not a full reimplementation as we’re going to see later in the slides, but there is a cost.

ShellBlack Migrating Lightning Slide 7

However, now you are riding the wave of Lightning. And now Salesforce is delivering that innovation three times a year, and you’re now able to take advantage of it. If you’re on Classic, to get new innovation, the burden of innovation is now on your shoulders, if you stay on Classic. So you’re going to have to do some development, or create innovation, get the ROI. Next time you want some innovation, it’s on your shoulders in Classic. You’re going to have to develop it, see that ROI, and then so on and so on.

So again, you can do a lot more. There’s an upfront cost, and it’s more significant, but then you ride the wave, or, innovation is now on your shoulders if you stay on Classic. Again, kind of a way you can pitch this to leadership.

ShellBlack Migrating Lightning Slide 8

So let’s talk about what’s involved. The easiest way I like to look at this is, let’s talk about what’s not impacted by transitioning to Lightning. So breathe in. Breathe out. This is all still there. Not to panic. Be calm. So data, even though it has the word "migration" in it, your data’s not impacted. So there’s no data migration. All the data model that you’ve built out – standard objects, custom objects, all those fields, your sales process, your lead process – still there. All the business logic of the validation rules, the automation rules, the process builders, the workflows, the triggers – still there.

Security, everything wrapped around users about, can you see the record? Organization-Wide defaults (OWDs), sharing rules, permission sets, Role Hierarchy, still there. So it’s not a full migration. All this is still intact.

ShellBlack Migrating Lightning Slide 9

So let’s talk about what you do have to consider. Now the most obvious thing is the UI (User Interface). And as we’ll talk about later in this presentation, admin knowledge is going to be a big piece of this. Because you really need to go back and look at your business, the requirements, and kind of reimagine working in Salesforce. We are very trained as Classic users, to have the two-column layout, related list at the bottom. Get really good at scrolling up and down. Right? They all kind of look the same.

We’ve got a new toolkit, and while I wouldn’t say the gloves are off, you have a lot more flexibility. Maybe you want to use one of the templates that have a three-column layout. Maybe you don’t want people to have to scroll down and see a related list and you want to keep all of the information "above the fold" in the screen, and start using tabs. You can have up to 25 tabs. You have actions, you have global actions, you’ve got Lightning components, you have the highlights panel at the top of the age for the most important fields.

You need to start thinking of Salesforce through the lens of a UI usability expert. And try to think about, "If we were to do this over again in another platform, would we solve these problems the same way or would we solve them differently?" And that is really going to be the value of Lightning, as kind of reimagining working and letting Salesforce be more proactive and taking action on that data and the Lightning Experience (LEX).

Okay. AppExchange Apps. You need to go see what AppExchange apps you have, and make sure they’re Lightning-ready. Also, if you haven’t look at what AppExchange apps are in your org, there’s probably some you need to get rid of. I’m telling you, go uninstall that stuff. Custom code, so if you’ve got JavaScript buttons, Visualforce pages, those JavaScript buttons, you might have to make into an Action. If you have a Visualforce page, for example, you need to go see if that’s going to render properly. And there’s some security containment with Visualforce pages with Lightning. And so it may not function the way you’re expecting, because you wrote this Visualforce page eight years ago, not anticipating Lightning.

Analytics. You’ve now got, what? A 9×9 grid? You need to go back and look at your dashboards and say, "Now that we’ve got this different toolkit," and you’ve also got a new Lightning Report Builder, would you present the information differently? Because now you can have components, or a Lightning metric, that goes across nine columns, that spans the whole thing. You’re not limited to the three-column layout, or two-column layout. So yeah, a lot of this is reimagining working in Salesforce and this is really going to be how you’re going to add value to your organization.

ShellBlack Migrating Lightning Slide 10

So let’s get into the four steps. So these four steps are a framework we’ve put together that really talks about how you tackle this. And the framework will expand and contract based on your footprint with Salesforce. Because if you’re a Professional Edition, and you don’t have custom code… Right? You can’t write custom code in Professional Edition. Then maybe you’re a single group of uses, this framework will still work. It could also work if you’re an Enterprise customer that’s got 50 custom objects, 1,000 users, and you’ve been pounding on it for 10 years.

So we’ll talk about these phases of the project and this framework, but then, as I go through it, we’ll talk about how this will expand and contract based on the organization. Fair enough? Everybody’s still with me. Everybody’s still awake. All right.

ShellBlack Migrating Lightning Slide 11

So the assessment stage is really about taking an inventory of what’s in your org. And so you’ve probably seen it. You can’t miss it if it’s in setup. We’ve got the Lightning Readiness Assessment tool. Really good. It’s going to tell you what’s compatible, what features you’re using that’s not available, do you have any code issues. That’s step one. I also like to run the Optimizer report. And if you haven’t looked at the Optimizer report, it’s a great housecleaning report for a system administrator. It’ll tell you, "Here are Custom Profiles that are not being used. Here are workflow rules that are inactive, just hanging out there."

One thing I like about the Optimizer report, because we’re talking about revisiting the UI, is it will give you some field utilization data that says, "Of these custom fields that you have, and standard fields, out of 100 records, what percent of those fields are being used on a record." And it’ll tell you, "Okay, maybe we created a bunch of fields four years ago, and nobody knows what they’re for anymore and they’re not being used." There was a great app on the AppExchange called "Field Trip" that did something very, very similar. But you can get that information now from this Optimizer report.

The next thing is going through and taking an inventory of the features by functional group. And this is going to play into the next step. But looking at what features are used by sales, marketing, back office, compliance, legal, corporate communications, whatever group functional of users. Again, getting that inventory of AppExchange Apps. Which ones have Lightning-ready versions. Technical debt. So technical debt, what I mean by that is custom code. It could be JavaScript buttons, Visualforce, those types of things.

And then the other thing I would look at is reviewing your roadmap for Salesforce. Because even if you’re in the planning stages now, what I don’t want you to do is start heaving on more technical debt and more AppExchange apps that aren’t Lightning-ready. Because maybe, based on your planning, you’re not going to go live for nine months to a year. Well don’t buy an AppExchange solution today that you’re going to sign up for a year contract for, that you’re on the hook for. And don’t sit there and make a Visualforce page that you haven’t tested in Lighting.

So don’t heave onto the problem because you got to do business today. So when you’re thinking about that assessment, also think about what’s on your current roadmap for Salesforce as an organization. Does that make sense? Yeah.

ShellBlack Migrating Lightning Slide 12

All right. So we’ve got our inventory. We know what we have to go touch and that we’ve got to go address. The next thing is just breaking down the work by the teams, assemble the team. Again, depending on the size of your organization, the team could be a sole System Admin working in Professional Edition for a small company. And that may be the team. If you’re a large Enterprise client, that could be leadership, an executive sponsor, someone from corporate communications, someone from training, a team of admins, a team of developers, maybe a consulting company. It could be a very large team. It could be the subject matter experts that are being representative of those departments that’ll be impacted. So again, depending on your organization, that concept will kind of expand and contract.

Communications strategy. Again, if it’s a small company, you’re probably having water cooler conversations with the users and leadership. If you’re a big company, they’re going to want to get ahead of this initiative and communicate this, not only to leadership, the key stakeholders, but also those end users when that’s coming. So depending on your company, the corporate communications piece could be a bigger piece.

So I talked, in that earlier slide, about looking at the inventory. And I would look at it as a matrix of, "Here’s the features that we use." And then across, look at it by functional groups, maybe sales, operations, back office, compliance, marketing, customer service. And then start to look at which will be the easier groups to go-live. Because you can flip these by functional group. You don’t have to big bang and take everybody live at once. So you might say that, "Hey, at least this group can go-live this quarter. This group, we can do two groups this quarter." But if you start matrixing out the features and the work you have to do, features, customer code and AppExchange apps, against those functional groups, it’ll help you prioritize how to eat the elephant, how you tackle this.

Because a launch date, for you, could be a number of things based on your organization. Again, if you’re a small Professional Edition org. I’m not trying to pick on Professional Edition, it was just easier. But if you’re a small Professional customer with a dozen users, a launch date could be everybody. "We’re just going to do it all. It’s going to be big bang, that’s our launch date."

If you are a large Enterprise customer, a launch date could be the first functional group and the pilot, and then the rest of the group. And then the next launch date is the next pilot for the next functional group, until you get through all the functional groups. So again, taking this model, expanding it in and out.

Sandbox testing and deployment. I feel like I’m picking on Professional Edition. But if you have Professional Edition, you have no way to do a change set. What I mean by "change set" is, any custom code or configuration work that you’ve done in Sandbox, with Professional Edition, you have no way to move those changes from a Sandbox environment to Production. So essentially, you have to recreate everything by hand anyway. So again, I know people are like, "Really?" Like, "Yeah, that’s what Professional Edition does." There’s no change sets.

So you can do testing and a whole bunch of stuff, but you have to manually recreate that. So again, if it’s a single group of sales users, you might just do all the work in production, clone the Sandbox, train them, and then set them free. Obviously, if you are an Enterprise customer with a lot of functional groups, and a lot of custom code, you’re definitely going to be working in the Sandbox. Make sense?

ShellBlack Migrating Lightning Slide 13

Okay. So we’ve got our inventory, we’ve broken down the work, we’ve got our team together, we’ve got our dates of launch plans and stuff. We know how many build cycles we need. Here comes the heavy work, time to get it done. Get ‘er done! So depending on the object that you’re working, I recommend starting with your standard objects first – Leads, Accounts, Contacts, Opportunities, Cases, and then your Custom Objects. But depending on how much of your business process is wrapped around an object, you might have a two-week sprint on Contacts, but it might take you two months to get through Opportunities because you have a bunch of business rules, and quoting, and approval processes, and products, and quote templates, and a bunch of stuff you have to tackle. Maybe you have an app that’s heavily embedded into Opportunities.

So you have to look at that and say, "Okay, not everything’s going to be a one-week or two-week sprint." Again, expand that in and out based on your business processes, and what your business does.

Custom code. A lot of…well not a lot of decisions. But again, because you can do things differently just because you have something in Visualforce, and you know that it doesn’t work, you can either refactor and recode that Visualforce page. Or maybe you go to a Lightning component and then maybe you can have that kind of modularized where you can have that in other areas of your Lightning implementation.

So again, think about what you can do, because you’re going to have some options with that. You’re going to have to go through adjust your custom code, redo your dashboards, communication templates. Get in the Sandbox, get your Admins to do their work, developers to do their work, get the subject matter experts (SMEs) that are representing those functional groups, have them run through their use cases and make sure you haven’t missed your requirement. Right? That’s really the proof in the pudding, is getting them in there and saying, "Okay, is this going to support the way we work." Man, I feel like I’m blazing through this.

ShellBlack Migrating Lightning Slide 14

Okay. Step four, training and deployment. Last year at Dreamforce, I did an entire session on training end-users on Lightning. So in the chatter group of this session, I put a link to the video, last year. So you could go see it if you want to really understand tools, techniques, tips and tricks, and training end-users on Lightning. This was a good summary slide that I liked. And if you look at the left-hand part of that slide, what I’m saying here is, "Lightning training is not new user training." When you’re training people in Lightning, they already know the dictionary definitions of what a Lead is, what’s an Opportunity, they know how to login.

And they know how to do their job. They know how to convert a Lead. They know when to get an approval process. You’re not teaching them how to do their job or how to use Salesforce, you’re really, on the right-hand side, is really telling them, "Where did it go?" Who moved my cheese? Think back to the first time you looked at Lightning, logged in and just absolutely disoriented you were. Were you just frustrated because like, "Where did it go?" And you’re clicking, and you’re trying to figure it all out.

If you don’t train your end users, as soon as they find the little switch back to Classic, they’re out of there. I guarantee you. They’re going to hightail it to the hills. Why not? Right? So part of training users on Lightning is to let them know it’s all there. A lot of times, instead of that scrolling up and down, I like to say, "Click to reveal." Because it’s very clicky versus scrolly. Is that a verb, scrolly? Sure. It sounds great.

So first, just let them breathe. Let them know that it’s all still there. We’ve just rearranged the data a little bit different. And then you need to put a little sizzle in the steak, and show them all the cool things you can do. "Well there’s Kanban Boards, your dashboard. Check out what this new global action does, and how cool that is." So then you have to start bringing the value of the platform, the value of Lightning to let those users be like, "Okay, this is going to be a great way to work." All right. Make sense.

ShellBlack Migrating Lightning Slide 15

So we have training. Our users are trained. You typically will train them in a Sandbox so they don’t mess up your data in production. Make sure they’re all ready to go before you go live. The next thing you got to do is, "light the rocket." We got to take all that work we’ve done, in a Sandbox typically, package it up in a change set, push that into production. So that could be code, that could be configuration changes. And if you’re really good at change sets, you’ll know that you really need to start keeping a list of everything you’ve done, because it’s real easy to forget something.

And that’s what I’m talking about with a smoke test or a sniff test. Because it is really easy to forget one little piece of configuration in the change set. And so what a smoke test is, what I’m really saying is, go into production before you start flipping profiles and exposing the UI, you just want to do one more round of run through your use case to just make sure that you didn’t forget something in that change set. Because it’s so easy to forget something in a change set, if you’ve worked in that kind of environment and deployment strategy before.

So again, just quick smoke test. Make sure everything’s good, let the users go-live. Adoption is going to be key, guys, to make this project a success. You want to support those users post-go live. You want to make sure that this is going to show the value that you pitched to leadership. So a Chatter Group is always good where you can keep updates on what’s going on. "Hey, we found a bug. We’re working on it." Keep people informed. You can do office hours. And what I mean by "office hours" is schedule a series of conference call bridges where someone call in and get some help, a GoTo Meeting, Monday, Tuesday, Wednesday, or Monday, Wednesday, Friday, whatever, that, "Hey, if you’ve got a question and need some extra one-on-one time, that’s available."

I don’t know if you guys have found this yet, but there’s a Lightning Adoption Tracker App. And you can run reports in dashboards to see if your people are actually in it and using it. So that basically says, "Here’s all the folks that have access to it. Here’s all your users and are they actually in Lightning?" Which is pretty cool if you want to bust somebody. "You’re not in it. Get in there!"

ShellBlack Migrating Lightning Slide 16

All right. So the question I always get asked as a consultant is, "Well this sounds great. But how long will it take?" And as a consultant, I must tell you – "It depends." That’s consulting, right? So there was a session last year that Dell put on that I attended, and in the Chatter Group, put a link to the video so you don’t have to go searching for it. Because there’s only 2,000 sessions this year, right? So I put a link to the video. But basically, Dell said…there were describing their journey to Lightning, and it was going to take them 18 months to get a pilot group of salespeople on Lightning. A pilot, 18 months, because of all the technical debt. Wide, deep footprint, large enterprise client.

Just because I like picking on Professional Edition. So if you’re Professional Edition, and you have a single group of users, a half dozen or a dozen, you might be able to bang all this out in a month on top of your day job. It may not be that significant if you’re fairly out-of-the-box using standard objects. So again, it could be a multi-year journey for a big Enterprise customer, or it could be a month or more. So again, it depends on if you have dozens and dozens of custom objects and you’ve got a wicked good System Administrator that’s been banging in functionality for the last half dozen years, there’s going to be a lot to look at. Make sense?

ShellBlack Migrating Lightning Slide 17

Boom. So I would challenge you and say, "The biggest hurdle going to Lightning is not the feature that you’re missing – it’s knowledge." Your biggest hurdle converting to Lightning is Admin knowledge. In just seven releases, we’re talking 2015, it was just two years ago, we’ve had 3,621 pages of release notes. Three thousand six hundred and twenty-one pages of release notes. I calculated them all. I went back and looked, and my jaw hit the floor too. That is a lot to catch up on if you’ve had your head in the sand for the last two years, and not paying attention to what’s going with Salesforce.

Me included, I’ve been using Classic since 2005. There’s a lot. So there’s days of webinars and release readiness videos, just a couple hundred trailhead badges, "We’ll have this knocked out in a weekend." I mean there’s a lot of trailhead badges you can get. I would look at the Lightning Experience Specialist super badge. We have our consultants take that. It’s a really good one. The Lightning Experience Rollout Specialist, the new Trailhead Community, which used to be the success community. Rebranded now the Trailhead Community.

The Lightning Now! Community group with a big apostrophe, and I put a link to that in the Chatter Group for you. That is an awesome group. Those are some great resources, birds of a feather, everybody in the same boat, trying to make this happen, trying to help each other out.

ShellBlack Migrating Lightning Slide 18jpg

So all that said, a lot to learn. Again, I think to get the maximum out of the Lightning UI is really knowing that toolkit, how to leverage that, that is what’s going to bring the value of Lightning. Okay. But if you need help, you can go to and we do have the four steps we just talked about kind of expanded out in more detail than what I could cover today. It’s free on our website. You can do that. The ebook’s called "The Salesforce Secret Formula Migrating from Classic to Lightning."

ShellBlack Migrating to Lightning Thank You

This entry was posted in Lightning. Bookmark the permalink.