# Reservation to Booking Migration Plan
## Overview
This document outlines the complete migration strategy from the deprecated `Reservation` entity to the `Booking` entity across the entire codebase.
**Current Status**: Both `Reservation` and `Booking` models use the same `bookings` database table, making this primarily a code refactoring task.
**Affected Files**: 171 files across the codebase
---
## Phase 1: Model Analysis & Preparation
### 1.1 Compare Models
- ✅ Both use `bookings` table
- ⚠️ Need to merge all methods/relationships from Reservation into Booking
- ⚠️ Need to ensure all scopes, accessors, mutators are preserved
### 1.2 Key Files to Analyze
- `app/Models/Reservation.php` (429 lines)
- `app/Models/Booking.php` (471 lines)
**Action Items**:
1. Copy all unique methods from Reservation to Booking
2. Copy all unique relationships from Reservation to Booking
3. Copy all unique scopes/accessors/mutators
4. Ensure all constants are preserved
---
## Phase 2: Core Controllers Migration
### 2.1 High Priority Controllers (35+ matches)
1. **CheckoutController.php** (35 matches)
- Update all `Reservation` references to `Booking`
- Update route names
- Update view variables
2. **PaymentController.php** (26 matches)
- Update payment processing logic
- Update MyPos integration
- Update fiscal receipt generation
3. **ReservationController.php** (9 matches)
- Rename to `BookingController.php` OR merge with existing BookingController
- Update all methods
- Update route bindings
### 2.2 Medium Priority Controllers
- `ReservationCancellationController.php`
- `VenueSpotController.php`
- API Controllers in `app/Http/Controllers/Api/`
---
## Phase 3: Filament Resources Migration
### 3.1 Main Resources
1. **ReservationResource.php** (28 matches)
- Already have BookingResource
- Need to merge unique features
- Update navigation
- Update permissions
2. **ClientReservationResource.php** (23 matches)
- Create ClientBookingResource if needed
- Update client panel navigation
### 3.2 Resource Pages
- `CreateReservation.php` → Merge with `CreateBooking.php`
- `EditReservation.php` → Merge with `EditBooking.php`
- `ListReservations.php` → Merge with `ListBookings.php`
- `ViewReservation.php` → Merge with `ViewBooking.php`
### 3.3 Widgets
- `ReservationCalendarWidget.php` (50 matches) → `BookingCalendarWidget.php`
- `ReservationsStatsOverview.php` → `BookingStatsOverview.php`
---
## Phase 4: Services Migration
### 4.1 Service Classes
1. **ReservationService.php** (10 matches)
- Rename to `BookingService.php` OR merge with existing
- Update all method signatures
- Update all type hints
2. **ReservationCancellationService.php** (10 matches)
- Rename to `BookingCancellationService.php`
- Update all references
3. **MyPosService.php** (8 matches)
- Update reservation references in payment processing
### 4.2 API Services
- `ReservationApiService.php`
- API Handlers in `app/Filament/Resources/ReservationResource/Api/Handlers/`
---
## Phase 5: Routes Migration
### 5.1 Web Routes (`routes/web.php`)
```php
// OLD
Route::get('/reservations/{reservation}', [ReservationController::class, 'show'])->name('reservations.show');
// NEW
Route::get('/bookings/{booking}', [BookingController::class, 'show'])->name('bookings.show');
```
### 5.2 API Routes (`routes/api.php`)
- Update all `/api/reservations/*` to `/api/bookings/*`
- Maintain backward compatibility with route aliases if needed
### 5.3 Route Names to Update
- `reservations.index` → `bookings.index`
- `reservations.show` → `bookings.show`
- `reservations.store` → `bookings.store`
- `reservations.update` → `bookings.update`
- `reservations.destroy` → `bookings.destroy`
- `reservations.updateAttendance` → `bookings.updateAttendance`
---
## Phase 6: Views & Blade Templates
### 6.1 Livewire Components
1. **reservation-scanner.blade.php** (22 matches)
- Rename to `booking-scanner.blade.php`
- Update all variable names
- Update Livewire component class
2. **venue-plan.blade.php** (28 matches)
- Update reservation references
3. **ReservationPayment.php** (Livewire class)
- Rename to `BookingPayment.php`
### 6.2 Email Templates
- `new-reservation-notice-to-admin.blade.php` → `new-booking-notice-to-admin.blade.php`
- `reservation-canceled.blade.php` → `booking-canceled.blade.php`
- `reservation-confirmed.blade.php` → `booking-confirmed.blade.php`
### 6.3 PDF Templates
- `pdf/reservation.blade.php` → `pdf/booking.blade.php` (or merge with existing)
### 6.4 Checkout Views
- `checkout.blade.php` (5 matches)
- Update all form fields and variables
---
## Phase 7: Notifications & Mailables
### 7.1 Notifications
- `ReservationPaymentRequestNotification.php` → `BookingPaymentRequestNotification.php`
### 7.2 Mailables
- `ReservationPaymentRequestNotification.php` (Mailable) → `BookingPaymentRequestNotification.php`
---
## Phase 8: Policies & Permissions
### 8.1 Policies
- `ReservationPolicy.php` → `BookingPolicy.php`
- Update all policy methods
- Update Filament resource authorization
### 8.2 Permissions
- Update permission names in seeders
- Update role assignments
---
## Phase 9: Database & Seeders
### 9.1 Seeders
- `ProductSeeder.php` (38 matches)
- `SettingsSeeder.php` (5 matches)
### 9.2 Migrations
- No table changes needed (both use `bookings` table)
- May need to update foreign key constraint names if any reference "reservation"
---
## Phase 10: Configuration & Settings
### 10.1 Config Files
- Check `config/` directory for any reservation-specific settings
### 10.2 Filament Pages
- `ReservationSettings.php` → `BookingSettings.php`
- `ReservationPayment.php` → `BookingPayment.php`
- `ReservationScanner.php` → `BookingScanner.php` (or keep as is since it scans bookings)
---
## Phase 11: Testing & Validation
### 11.1 Manual Testing Checklist
- [ ] Create new booking
- [ ] Edit existing booking
- [ ] Cancel booking
- [ ] Process payment
- [ ] Generate fiscal receipt
- [ ] Scan QR code
- [ ] View calendar
- [ ] Client panel booking creation
- [ ] Email notifications
- [ ] PDF generation
### 11.2 Database Validation
- [ ] Verify all bookings still accessible
- [ ] Verify relationships intact
- [ ] Verify no orphaned records
---
## Phase 12: Deprecation & Cleanup
### 12.1 Mark Reservation Model as Deprecated
```php
/**
* @deprecated Use App\Models\Booking instead
* This model is kept for backward compatibility only
* Will be removed in version 2.0
*/
class Reservation extends Model
{
// Add deprecation notice to constructor
public function __construct(array $attributes = [])
{
parent::__construct($attributes);
\Log::warning('Reservation model is deprecated. Use Booking model instead.', [
'trace' => debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 5)
]);
}
}
```
### 12.2 Create Model Alias (Temporary)
In `config/app.php`:
```php
'aliases' => [
// ...
'Reservation' => App\Models\Booking::class, // Temporary alias
],
```
---
## Implementation Strategy
### Recommended Approach: **Gradual Migration**
1. **Week 1**: Merge Reservation model methods into Booking model
2. **Week 2**: Update core controllers and services
3. **Week 3**: Update Filament resources and widgets
4. **Week 4**: Update views, emails, and notifications
5. **Week 5**: Update routes and test thoroughly
6. **Week 6**: Mark Reservation as deprecated, monitor logs
### Alternative Approach: **Big Bang Migration** (Risky)
- Update all files in one go
- Requires extensive testing
- Higher risk of breaking changes
- Not recommended for production
---
## Backward Compatibility Considerations
### Option 1: Route Aliases (Recommended)
```php
// Keep old routes as aliases
Route::get('/reservations/{reservation}', function($id) {
return redirect()->route('bookings.show', $id);
})->name('reservations.show.deprecated');
```
### Option 2: Model Alias
Keep Reservation model as an alias to Booking for 6 months
### Option 3: Facade Pattern
Create a Reservation facade that proxies to Booking
---
## Risk Assessment
### High Risk Areas
1. ⚠️ Payment processing (MyPos integration)
2. ⚠️ Fiscal receipt generation
3. ⚠️ Calendar widget (50 matches)
4. ⚠️ Client panel reservations
### Medium Risk Areas
1. Email notifications
2. PDF generation
3. QR code scanning
4. Venue plan integration
### Low Risk Areas
1. View templates
2. Seeders
3. Configuration files
---
## Rollback Plan
1. Keep Reservation model for 6 months minimum
2. Use feature flags for gradual rollout
3. Monitor error logs for Reservation usage
4. Keep database backups before major changes
5. Use Git tags for each phase completion
---
## File Priority Matrix
### Critical (Update First)
- `app/Models/Reservation.php`
- `app/Models/Booking.php`
- `app/Http/Controllers/CheckoutController.php`
- `app/Http/Controllers/PaymentController.php`
### High Priority
- `app/Filament/Resources/ReservationResource.php`
- `app/Services/ReservationService.php`
- `routes/web.php`
- `routes/api.php`
### Medium Priority
- Filament widgets and pages
- Email templates
- Livewire components
### Low Priority
- Seeders
- Test files
- Documentation
---
## Next Steps
1. **Review this plan** with the team
2. **Create a backup** of the entire codebase
3. **Set up a feature branch** for the migration
4. **Start with Phase 1**: Merge Reservation methods into Booking
5. **Test each phase** thoroughly before proceeding
6. **Document all changes** in CHANGELOG.md
---
## Questions to Answer Before Starting
1. Are there any external integrations that reference "reservation"?
2. Are there any mobile apps or APIs that depend on reservation endpoints?
3. What is the acceptable downtime window?
4. Should we maintain backward compatibility? For how long?
5. Are there any scheduled tasks/cron jobs using Reservation?
---
## Estimated Timeline
- **Gradual Migration**: 6 weeks
- **Big Bang Migration**: 2 weeks (+ 2 weeks testing)
- **Recommended**: Gradual migration with 6-month deprecation period
---
## Success Criteria
- [ ] All 171 files updated
- [ ] All tests passing
- [ ] No Reservation references in new code
- [ ] Backward compatibility maintained
- [ ] Documentation updated
- [ ] Team trained on new naming
- [ ] Monitoring in place for deprecated usage
---
*Last Updated: 2025-10-22*
*Status: Planning Phase*