The migration is rarely a like-for-like rewrite — Visualforce and LWC have different paradigms. The strategy:
Inventory phase:
- List every Visualforce page in the org (Setup -> Visualforce Pages).
- Categorise: simple display pages, controller-heavy interactive pages, PDF generators, embedded utilities.
- Identify which can be deprecated (replaced by Lightning Record Pages, Path, or out-of-the-box features) vs which need a real LWC equivalent.
Per-page rewrite:
- Simplify scope. Visualforce pages often pile multiple features onto one page. Each LWC component should do one thing well.
- Decompose — split the VF page into a parent LWC plus child components for distinct concerns (header, list, form, footer).
- Replace controller logic:
- Standard controllers -> Lightning Data Service
getRecord/updateRecord. - Custom controllers ->
@AuraEnabledApex methods called via@wireor imperatively. - Visualforce-specific tags (
<apex:pageBlock>,<apex:dataTable>) -> Lightning Base Components (lightning-card,lightning-datatable).
- Replace remoting and AJAX -> async/await on imperative
@AuraEnabledcalls. - Replace ViewState — LWC has no ViewState. State lives on the client; you store in component reactive properties.
- Replace inline styles -> SLDS classes or scoped CSS.
- Test in Lightning Experience — VF pages worked in Classic; LWC is Lightning-only.
Deployment strategy:
- Run side-by-side — keep VF page live while LWC is built and tested.
- Use the App Builder to swap which page renders for users. Switch a profile at a time.
- Telemetry — log usage of the VF page; deprecate when usage drops.
What can't easily migrate:
- VF Email Templates — keep these on VF; new templates can be Lightning Email Templates but old ones don't auto-convert.
- PDF rendering (
renderAs="pdf") — no direct LWC equivalent. Keep VF or use external PDF services. - VF embedded in legacy custom buttons — depends on the button.
Tooling:
- VS Code extensions for editing both VF and LWC side by side.
- Salesforce Migration Workbook (Salesforce documentation) — patterns for common VF -> LWC translations.
Migration is multi-quarter for VF-heavy orgs. Phase by user impact: rewrite high-traffic pages first.
