- What Visualforce is and how it works architecturally
- Why Visualforce is in maintenance mode and what that means operationally
- The specific scenarios where Visualforce is still the right tool in 2026
- Where LWC has replaced Visualforce and where the migration path is clear
- How to assess the Visualforce technical debt in an existing org
- The migration strategy for high-value Visualforce pages
What Visualforce Is
Visualforce is Salesforce's server-side web UI framework, introduced in 2007. A Visualforce page is an HTML-like markup file (with Salesforce-specific tags like <apex:pageBlock> and <apex:inputField>) backed by an Apex controller class that handles data retrieval and form actions. The page renders entirely server-side — the server produces HTML and sends it to the browser on each interaction.
This server-side rendering model was standard practice in 2007 (think JSP, ASP.NET WebForms). By 2020, single-page application architectures with client-side rendering (React, Vue, Angular — and Salesforce's LWC) had become the dominant approach. The difference matters for performance: Visualforce requires a round-trip to the server for every significant user interaction; LWC handles most interactions client-side, calling the server only for data.
Visualforce is not deprecated in the same way Process Builder is. Salesforce has committed to maintaining it indefinitely. But it receives no new features, no new standard components, and no investment in performance improvements. The Salesforce product roadmap is built around Lightning components and LWC — not Visualforce.
Where Visualforce Is Still the Right Tool
Despite its age, Visualforce retains a genuine advantage in specific scenarios where LWC cannot fully replace it.
PDF generation: Visualforce has built-in PDF rendering — adding renderAs="pdf" to the page tag generates a PDF from the page's HTML output. This is used for quotes, invoices, contracts, and reports. LWC has no equivalent native PDF rendering capability. Organisations that need server-side PDF generation from Salesforce data are effectively locked to Visualforce (or a third-party PDF library) for this use case.
Legacy portal pages: Organisations with Salesforce Sites (the predecessor to Experience Cloud) or old Customer Portal implementations built on Visualforce may have hundreds of pages that would require complete rebuilding to migrate. The business value of migrating these must outweigh the rebuild cost — for stable, low-traffic portals, the answer is often "leave it alone."
Complex form-heavy UIs: Some organisations have complex multi-page form workflows built in Visualforce that work correctly and are rarely modified. The cost of rewriting these in LWC, retesting, and validating may exceed the benefit of improved performance for infrequently-used admin processes.
Where LWC Has Replaced Visualforce
For new development, LWC is almost always the better choice. The scenarios where Visualforce was previously used but LWC now serves better:
Record page customisations: Custom record page layouts with unique UI elements, inline editing panels, related list overrides — all these are better built in LWC as Lightning components that embed in the Lightning record page builder. Visualforce pages used as inline components in Classic record pages have no place in Lightning Experience.
Custom list views and data tables: Lightning Data Table in LWC provides a performant, configurable data grid that outperforms equivalent Visualforce pageBlockTable components significantly. Any new custom list or table UI should be LWC.
Mobile UIs: Visualforce renders poorly on mobile without significant additional styling effort. LWC is designed for responsive rendering across desktop and mobile. Any Salesforce mobile app UI should be LWC.
// Visualforce page with PDF rendering (still valid in 2026)
<apex:page controller="QuoteController" renderAs="pdf"
applyBodyTag="false">
<html>
<body>
<h1>{!quote.Name}</h1>
<table>
<apex:repeat value="{!lineItems}" var="li">
<tr>
<td>{!li.Product2.Name}</td>
<td>{!li.Quantity}</td>
<td>{!li.TotalPrice}</td>
</tr>
</apex:repeat>
</table>
</body>
</html>
</apex:page>
// This PDF generation pattern has no LWC equivalentAssessing Visualforce Technical Debt
When inheriting an existing Salesforce org or conducting a technical assessment, a Visualforce audit is part of understanding the technical debt profile. These are the questions to answer.
How many Visualforce pages and components exist? Query ApexPage and ApexComponent via the Tooling API to get a count. Orgs over 5 years old often have 50-200+ pages, many of which are unused.
What is the usage pattern? Salesforce Event Monitoring (if enabled) logs Visualforce page access. Pulling 90 days of VF page access events identifies which pages are actually being used by users and which are orphaned.
Are they in Classic or Lightning Experience? Visualforce pages in Lightning Experience require the StandardController or a Lightning-enabled Apex controller. Pages built for Classic may render in a compatibility frame in Lightning Experience — functional but not integrated with the Lightning UI.
Migration Strategy for High-Value Pages
For Visualforce pages that are high-traffic, high-value, or business-critical, migration to LWC delivers genuine benefits: better performance, Lightning Experience integration, mobile responsiveness, and access to the latest platform capabilities.
The migration approach that minimises risk is incremental. Replace the Visualforce page one section at a time: start with the innermost, most independent components (a formatted display field, a single action button), build them as LWC components, and embed them in the Visualforce page using the <apex:includeScript> technique or the Lightning Out feature (which allows LWC components to be embedded in Visualforce pages during a phased migration). This avoids a big-bang rewrite and allows regression testing at each increment.
For pages that exist purely for PDF generation, investigate third-party PDF libraries (DocuSign CLM, Conga Composer, or open-source alternatives) that can generate PDFs from Salesforce data without Visualforce. If the PDF layout requirements are simple, a managed package with PDF generation capability may be faster than maintaining custom Visualforce PDF pages long-term.
Key Takeaways
- Visualforce is a server-side HTML rendering framework from 2007 — in maintenance mode, not deprecated, but receiving no new investment. It will run in Salesforce orgs for years, but no new Visualforce should be built.
- Visualforce still has no practical LWC replacement for server-side PDF generation (renderAs="pdf"). This is the primary legitimate use case for new or retained Visualforce pages in 2026.
- For new record page UI, custom data tables, and mobile interfaces, LWC is the unambiguous choice. Visualforce renders poorly in Lightning Experience without the compatibility frame, and is not mobile-native.
- Visualforce audit scope: query ApexPage/ApexComponent count, review Event Monitoring data for actual usage, and classify pages as Lightning-enabled or Classic-only.
- Migration strategy for high-value pages: incremental replacement using Lightning Out to embed LWC components in Visualforce pages during transition, not big-bang rewrites.
- Before deleting any Visualforce page, search all references (page overrides, custom buttons, email templates) — orphaned pages may still be referenced in unexpected places.
Test Your Understanding
1. A client asks whether they should migrate all 120 Visualforce pages to LWC as a strategic priority. What is the most pragmatic advice?
2. Your org generates client proposal PDFs from Visualforce pages with custom branding and complex table layouts. A developer suggests migrating these to LWC. What should you tell them?
3. A developer wants to delete a Visualforce page that hasn't been modified in 3 years, assuming it is unused. What step must be taken first?
Discussion & Feedback