Big architectural migrations (years-long) require deliberate strategy.
Pattern: strangler fig.
Don't rewrite the whole monolith at once. Build new components alongside old; migrate users gradually; eventually retire old.
Named after the strangler fig tree, which grows around its host until the host dies.
Phases:
1. Assess.
- Inventory current architecture.
- Identify components.
- Categorize by complexity, business value, technical debt.
- Estimate migration effort per component.
2. Define target.
- New architectural pattern.
- Standards.
- Reference architecture.
- Success metrics.
3. Pilot.
- Migrate one small component.
- Validate the approach.
- Iterate based on lessons.
4. Sequence.
- High-value, low-complexity first (quick wins).
- Or critical-path-blocking-other-work first.
- Build dependencies into sequence.
5. Build incrementally.
- New work in new architecture.
- Old work continues in old architecture.
- Coexistence during transition.
- Both serve users; gradually shift load.
6. Migrate.
- Component by component.
- Test each migration thoroughly.
- Rollback capability.
- Communication to users.
7. Decommission.
- When new replaces old completely, remove the old.
- Final cleanup; archive learnings.
Specific Salesforce migrations:
Aura -> LWC:
- Build new components in LWC.
- Replace Aura components one at a time.
- Coexistence: Aura parents can host LWC children; mostly the other way around.
- Test compatibility under Lightning Web Security (different from Locker).
Process Builder -> Flow:
- Migrate to Flow tool for simple cases.
- Manual rewrite for complex.
- Test side-by-side.
- Deactivate Process Builder after validation.
On-prem -> Salesforce:
- Phased rollout by user group / function.
- Parallel running before legacy decommissioned.
- Data migration with reconciliation.
Monolith -> microservices (less common in Salesforce; more in Heroku side):
- Strangler fig pattern.
- New microservices alongside monolith.
- API gateway routes traffic.
- Each microservice independently deployable.
Architecture during migration:
- Anti-corruption layer — adapter between old and new architectures. Old logic doesn't pollute new.
- Feature flags — toggle which architecture serves which users.
- Telemetry — track usage of old vs new; quantify migration progress.
Communication:
- Stakeholder updates — progress against milestones.
- User communication — when migration affects them.
- Team training — on new architecture.
Common pitfalls:
- Big-bang migration — too risky for serious orgs.
- No clear target — rebuild without knowing what.
- Migration never ending — components linger forever.
- Quality regression — new architecture is buggier than old.
- Loss of institutional knowledge — devs leaving during migration.
Senior architect insight: major migrations take longer than estimated. Plan for 1.5-2x your initial estimate. Maintain both old and new systems through the transition; this is the cost.
The senior framing: migrations are projects with no immediate business value. They're investments in future agility. Communicate this; protect the budget.