When I spoke to business owners, tech leads and admins of Classic orgs that are considering Lightning but are hesitating to make the jump, they have a common sticking point.
The time and effort to make the shift seems too daunting.
I can certainly sympathize. In a given week, there often is not enough time to keep up with current demands, let alone contemplate a gap analysis, cost/benefit analysis, budget impact, etc to make a shift.
However, the benefits of moving are quite compelling thou we don’t need to get into them here. There are other posts for that.
Of course there is “The Hard Way” to migrate to Lightning. To do this:
- Perform a Gap Analysis
- Create a Backlog
- Estimate Budget
- Identify Stakeholders and Department willing to pay for such budget
- Identify Resources
- Plan out Project Timeline
- Pause M&E
- Begin Project….
- End Project 9 months later after blood, sweat and tear.
- Phew, we made it to Lightning
- There’s got to a be an easier way….
There are easier ways than “The Hard Way” to do a cut over that might work for your org and company.
1. Role a new Org and then migrate users
Using this strategy, you will literally abandon your old org. First you have to speak with Salesforce and negotiate the cost for a brand new org. Then you can either develop business rules from scratch, do partial migration of metadata from the old org and/or migrate some departments one at a time.
This strategy is particularly good for orgs with an old code base, usually written by a long since departed consulting company, that has a ton of technical debt. This methodology is nice because you can build your business logic from scratch which can often be much more simple than the convoluted way it is written today. Also it can be easier to sell to Sales Managers because they will get to streamline the process, get better reports and not have to live with the mess they had become resigned to.
And its probably going to be much faster to do, sometimes on an order of magnitude.
2. Migrate user profiles over time, migrating the first users with no impact and then last users with the most amount of modifications
You always have the option to migrate some user profiles over to Lightning and not others. This allows you take Department by Department and move them over a period of time. This way you can bake the cost of migration into development and admin requests by that department.
This way is particularly good for companies who are just not going to bite the bullet for a full transition. You can insist that you have to move as Salesforce is moving in this direction and give them plenty of time to do the actual development work.
3. The Surprise Method
This is a fun and techy solution and might even make you look like a Super Hero. Using this method, you identify all the items holding you back from a Lightning Migration. Then start factoring these changes in with every release. Soon enough, you will have resolved all issues between you and an easy cutover to Lightning. Pop your head into the main business stakeholder and let them know, “Hey, we’re ready to cutover to Lightning if you’d like a way better UI with compelling new features for your Sales or Service process.” Once the business starts getting hooked on the new UI, you can start advising them on how they can better use Lightning features for the business.
This way can be good if you have full control over the development cycle AND you don’t have any major dependencies on objects that are not easily supported in Lightning, e.g. Quotes. Though even then, there are work arounds that are not too bad.
These are a few thoughts and strategies to get the wheels turning on how implementing Lightning might not be as bad as you may have thought. It might even earn you some serious company awards!