Migration Strategy

Principle

The Laravel application remains the behavioral reference until parity for a migrated slice is demonstrated. The target platform is built incrementally rather than through an unverified big-bang rewrite.

Stages

1. Freeze legacy census — routes, controllers, models, jobs, integrations, configuration and runtime dependencies.
2. Freeze foundation vocabulary — tenant/business-unit/capability/site/plan contracts.
3. Create target schemas and API contracts for the first migration slice.
4. Implement platform control plane and tenant isolation before tenant-owned business data.
5. Migrate a narrow vertical slice (e.g. legacy properties + enquiries) end to end.
6. Differential test Laravel vs target for request validation, price/availability semantics, side effects and customer behavior.
7. Expand vertical/capability coverage while preserving the parity matrix.
8. Migrate public frontend to managed Site Engine.
9. Migrate admin/provider workflows to tenant console.
10. Cut over integrations/jobs with reconciliation and rollback procedures.
11. Production cutover by tenant/site/domain, not by hope.
12. Retire Laravel only after all active parity rows are accepted or explicitly retired.

Data migration principles

• Preserve stable business identities and legacy references for reconciliation.
• Run migrations idempotently where possible.
• Record source row identity, target identity, migration version and validation status.
• Reconcile counts and financial/booking totals.
• Never infer tenant ownership silently; first tenant mapping must be explicit.