Patterns for Migrating from Visualforce to Lightning Components: Part 3

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide34


Patterns for Migrating from Visualforce to Lightning Components - Slide35

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide36

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.

Once you have completed the mapping of Visualforce Components to Pages, go through the list of components and reverse engineer the markup in each one. Do they use raw HTML, CSS, or JavaScript? Great, you can probably reuse some of that in the Lightning Component. If your custom Visualforce Components  are predominantly using standard Visualforce components in their markup, take note of the type of components being rendered and the data sources for those components.

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide37

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide38

Greenfield Strategy

The Greenfield Strategy presupposes that you are either new to Salesforce, or you are starting over in a new pristine Salesforce org.

Patterns for Migrating from Visualforce to Lightning Components - Slide39

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide40

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.
  • Your organization can train web developers with HTML5, JavaScript, and CSS experience to become Lightning developers.
  • Starting your Salesforce development roadmap with Lightning enables a sort of “catch-up effect” as developers would not need to learn Visualforce first.

Patterns for Migrating from Visualforce to Lightning Components - Slide41

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide42

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide43

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide44

Coexistence Strategy

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide45

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide46

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide47

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide48

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.

Patterns for Migrating from Visualforce to Lightning Components - Slide49

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.
Mike Topalovich Salesforce Technical Architect in Chicago
Mike Topalovich - Salesforce Certified Platform Developer I Mike Topalovich - Salesforce Certified Platform Developer II Mike Topalovich - Salesforce Certified Developer Mike Topalovich - Salesforce Certified Advanced Developer
Mike Topalovich - Salesforce Certified Mobile Solutions Architecture Designer Mike Topalovich - Salesforce Certified Platform App Builder Mike Topalovich - Salesforce Certified Administrator Mike Topalovich - Salesforce Certified Advanced Administrator
Mike Topalovich
Hi, I’m Mike. I help companies like yours do business in new ways with Salesforce.

I am a freelance Salesforce Developer, Architect, and CTO as well as a part time instructor for Salesforce University.

Connect with me today to discuss how I can become a part of your team on an ongoing retainer basis.
Mike Topalovich on EmailMike Topalovich on FlickrMike Topalovich on LinkedinMike Topalovich on RssMike Topalovich on Twitter


  1. Andrew Fawcett

    Great set of articles Mike, loved it, wise words and well structured. Whats your thoughts on the impact of adoption in the absence of a testing framework?


    • Mike Topalovich

      Thank you, Andy. Appreciate the feedback. Here are my thoughts on testing at the moment:

      * I think while unit testing is going to be critical in the long term, at this point in time the stability of the platform makes unit testing almost a moot point…because even though things have been settling down, functionality that may pass one day may fail the next if the framework itself changes. I’m not saying that’s justification for not testing, but I’ve run into so many issues that were not purely JavaScript related that I wouldn’t believe a set of test results at this point knowing the results could be completely different with a tweak to the platform.

      * While I have no knowledge of this (and thus don’t have to throw out a blanket “Safe Harbor” statement), I have to believe that the porting of the testing functionality inherent to the Aura framework will be a high priority on the roadmap.

      * From an adoption standpoint, we’re in the Wild West right now with only the earliest of early adopters truly bought into the Lightning framework, and we know that we’re walking a tightrope without a safety net…so the lack of a testing framework is less of a deterrent than platform stability as we strive to master the new technology. But when the adoption bell curve shifts right and the fast followers start to come onboard and improve on initial design patterns, stability and the ability to test will become more important. If we do not have a testing framework in place by the time enterprises come around, then I would worry about mass adoption. By the time the late majority / laggards come on, we will have solved all of these problems and they will have no knowledge / concern that they ever existed.


      • Andrew Fawcett

        Thanks Mike, could not agree more. Also keeping an eye on the Aura framework… 🙂


  2. Anand Narayan

    Mike, excellent set of articles! Really helps understand the architecture and possible trade-offs.


  3. Rama

    Wow, Great article. I have a question though where I have a scenario where I have to migrate the existing application very heavily customized with jquery on vf pages and along with continuation framework implemented in the controller. The application has performance issues currently. What would be the best strategy to migrate. Would it improve the performance with heavy customization where they are rendering dynamic forms using jquery. Any suggestion from your experience is highly appreciated.



    • Mike Topalovich

      The good news is that you can keep whatever was written in Apex and simply create an interface layer for Lightning by exposing @AuraEnabled methods to retrieve the data that is currently being served to the VF / jQuery solution.

      I would have to imagine that if you push as much as you can to the client side Lightning framework, performance would be better than using Ajax calls to server side methods, but of course there are many unknown unknowns here. In this use case, it sounds like the VF pages + jQuery front-end portion of the solution would have to be completely rewritten as there would be little value in trying to use jQuery in lieu of native framework functionality and custom JavaScript functions.


Leave a Comment

Your email address will never be published or shared and required fields are marked with an asterisk (*).

This site uses Akismet to reduce spam. Learn how your comment data is processed.