Strategies for Migrating From Visualforce to Lightning
In Part 3 of the Patterns for Migrating from Visualforce to Lightning Components series, I’ve envisioned five possible migration strategies for transitioning from a page-centric Salesforce Classic and Visualforce experience to an app-centric experience using Lightning Components in Lightning Experience.
For each of the five migration strategies, I lay out at a high level what each would look like from an implementation perspective, as well as call out key considerations that have to be made for each.
Scorched Earth Strategy
The Scorched Earth Strategy is the most ambitious of all of the migration strategies. While it may not be necessary to go the route of completely replacing Visualforce – in some cases Visualforce is still the only available option for certain functionality – if your organization has completely bought into Lightning and wants to make the cutover from Visualforce, this may be your ideal route.
Scorched Earth Strategy: Implementation
To go down the path of the Scorched Earth Strategy, you will have to completely rip out and replace all of your existing Visualforce Pages and Components with Lightning Components and Applications.
Since custom Visualforce Components are somewhat analogous to Lightning Components in that they are reusable building blocks of code, I would recommend starting with them in your analysis or pre-design phase as they may provide some “low-hanging fruit” in your migration effort.
Begin by mapping all existing Visualforce Components to the Pages that reference them. This will not only give you an idea of the dependencies that exist between Pages and Components, but it will help you understand both the construct of the Visualforce Page that you will be redesigning as an application and the mental models that your users have developed in using the legacy Visualforce Page.
Since Visualforce employs a page-centric architecture, you will probably find that most of your pages contain a great deal of markup and probably have several areas on the page that perform specific functions. For each of the functions being performed on a page, try and find where the function begins and ends within the Visualforce code.
Once you have your Visualforce page sliced up into the different functions performed, envision each of the functions and the corresponding UI patterns as standalone Lightning Components. What concepts can you keep? What has to be redesigned from the ground up for Lightning?
After you have rebuilt your custom Visualforce Components and abstracted all Visualforce Page logic and markup as individual Lightning Components, reassemble all of the pieces by composing new top level Lightning Components for each of the top level Visualforce pages being replace. The top level Lightning Component should contain no markup – only references to each of the granular components.
To surface the Lightning Components to users in Lightning Experience, you can either create new top level .app Lightning Apps that contain references to the top level Lightning Components, or you can add the top level Lightning Components to a Lightning Page using Lightning App Builder.
Scorched Earth Strategy: Considerations
Some key considerations for implementing the Scorched Earth Strategy:
- It will take a huge amount of effort to pull this off.
- Your team has to have a deep understanding of developing Lightning Components.
- Successfully implementing this requires either a rapid phased cutover or a flash cutover.
- The migration could potentially be disruptive to your users.
- You may find that you can reuse existing controller logic by abstracting to static methods with the @Auraenabled annotation.
- You will get a rare one-time opportunity to wipe technical debt off the books by refactoring and cleaning up old Visualforce code during the migration process.
The Greenfield Strategy presupposes that you are either new to Salesforce, or you are starting over in a new pristine Salesforce org.
Greenfield Strategy: Implementation
The implementation of the Greenfield Strategy is pretty straightforward:
- Take a Lighting-first development approach from day one and be free from the constraints of Visualforce.
- Build your customizations in a new, pristine Salesforce org.
Greenfield Strategy: Considerations
Some key considerations for implementing the Greenfield Strategy:
- This is a good option for new Salesforce customers as you can start and grow with Lightning.
- There would be very little migration from Visualforce.
- This presents an opportunity to cutover from a cluttered Salesforce org, but cutovers will require a data model redesign and a full data migration.
- Starting your Salesforce development roadmap with Lightning enables a sort of “catch-up effect” as developers would not need to learn Visualforce first.
War of Attrition Strategy
The War of Attrition Strategy is probably the most viable for most organization, as it is more of a gradual evolution than a migration.
With the War of Attrition Strategy, you adopt a Lightning-first approach to development, but rather than migrating existing Visualforce Pages and Components to Lightning Components, you leave them behind until they eventually reach the end of their useful lives and can be removed from the org.
War of Attrition Strategy: Implementation
To implement the War of Attrition Strategy, you have to take a number of steps within your development organization:
- Shift your team’s development focus from Visualforce to Lightning-first.
- Draw a line in the sand and meet new business requirements with Lightning solutions.
- For enhancement requests to legacy Visualforce Pages, evaluating the trade-offs of maintaining the Visualforce functionality as opposed to replacing with Lightning.
- Sunset existing Visualforce Pages and Components as they become obsolete.
- Reuse your existing Apex controller code by refactoring to use @AuraEnabled methods and commenting out Visualforce specific methods after Pages are sunset.
- If your organization wants to move to Lightning Component development but isn’t ready to move to Lightning Experience, use Lightning Components for Visualforce to surface new Lightning Components in Salesforce Classic.
War of Attrition Strategy: Considerations
Some key considerations for implementing the War of Attrition Strategy:
- This, in my opinion, will be the most likely scenario for existing Salesforce customers.
- Rather than throwing your developers into the fire, you can give the development team more time to learn how to build Lightning Components the right way.
- This process will inevitably create Visualforce clutter during the transition period
- Do not undertake the implementation of this strategy lightly – it requires disciplined management of your Salesforce operations.
The Coexistence Strategy is one where Visualforce and Lightning live in peaceful harmony. The best solution is chosen for each business use case, regardless of having to manage the overhead of multiple development platforms within the Salesforce space.
Coexistence Strategy: Implementation
The Coexistence Strategy is less of a migration path and more of an organizational mindset. You simply choose to evaluate both Visualforce and Lightning for new business requirements that cross your desk, and pick the best option for the use case.
Coexistence Strategy: Considerations
Some key considerations for implementing the Coexistence Strategy:
- You will need to have the oversight of a Salesforce Architect to make design decisions and ensure solutions adhere to Salesforce architecture guidelines.
- You could have a potentially inconsistent user experience across your Salesforce applications.
- This type of strategy would require a larger development team as you would have to have multiple skillsets available.
- Having a larger development team enables developer specialization in Apex, Visualforce and Lightning Components, fostering deep focus and expertise
- You will still need to migrate Visualforce Pages to Lightning Components if specific Visualforce functionality is ever deprecated.
Parallel Paths Strategy
The Parallel Paths Strategy is more of a thought exercise than a strategy. I don’t see many organizations adopting this as an approach, but it is interesting to think philosophically about how this strategy might enable a shorter learning curve and a deeper understanding of Lightning within your development team.
Parallel Paths Strategy: Implementation
The implementation of the Parallel Paths Strategy is about as straightforward as it gets: When new business requirements come in, design solutions for both Visualforce and Lightning Components.
Parallel Paths Strategy: Considerations
Some key considerations for implementing the Parallel Paths Strategy:
- You will be creating double work as you will be building and maintaining Visualforce and Lightning solutions in parallel.
- In the end, implementing some form of this strategy could enable a smoother transition to Lightning Components as developers gain confidence with the technology.
- Your developers will get to learn Lightning hands in a lower pressure environment.
- You allows your users the choice of transitioning to Lightning Experience or sticking with Salesforce Classic.