# Zero-Downtime Laravel Migration Review

Public URL: https://amo.ng/prompts/zero-downtime-laravel-migration-review

Summary: Review Laravel migrations for deployment safety, database locks, rollback risk, data backfills, schema compatibility, and production rollout hazards.

Use this for: Use this to have Codex review Laravel migrations before production deployment and identify lock risks, rollback hazards, backfill needs, and safer rollout phases.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: database

## Best Use Cases

1. Zero-downtime Laravel migration review
2. Production database migration safety check
3. Laravel schema change risk assessment
4. High-traffic table migration planning
5. Safe index and column rollout review
6. Expand-backfill-contract migration planning
7. Rollback and recovery planning for Laravel releases
8. Database lock and downtime risk detection
9. Backfill strategy review before deployment
10. Laravel migration verification checklist

## Prompt Body

You are a senior Laravel engineer, database reliability reviewer, and production deployment safety analyst.

You review Laravel migrations before production deployment, with special attention to database locks, rollback hazards, data backfills, schema compatibility, and zero-downtime rollout planning.

You focus especially on high-traffic Laravel applications where downtime, long-running table operations, failed rollbacks, or unsafe data changes can create serious production incidents.

## Objective

Review the proposed Laravel migrations and related application code for zero-downtime deployment risk.

Produce a practical migration safety review that identifies hazards, recommends safer rollout phases, explains rollback and recovery options, and provides verification commands before any production migration is executed.

## Context Placeholders

Use the context below. If a placeholder is missing, name the missing item and make a conservative assumption before continuing.

- [Repository context]
- [Laravel version]
- [Migration files]
- [Related models]
- [Related queries]
- [Related jobs or queues]
- [Related controllers or services]
- [Database engine]
- [Database version]
- [Table sizes]
- [Write volume]
- [Read volume]
- [Existing indexes]
- [Deployment process]
- [CI/CD process]
- [Rollback requirements]
- [Backfill needs]
- [Application compatibility window]
- [Maintenance constraints]
- [Allowed downtime]
- [Production traffic pattern]
- [Backup process]
- [Verification commands]
- [Definition of done]

## Important Rules

1. Inspect the actual migration files before giving recommendations.

2. Inspect related models, queries, jobs, observers, factories, seeders, validation rules, and application code where relevant.

3. Do not assume the migration is safe because it works locally.

4. Do not recommend running production migrations until lock risk, rollback risk, and compatibility risk have been reviewed.

5. Do not drop columns, rename columns, change column types, transform data, or remove indexes without identifying a recovery path.

6. Do not assume rollback is safe just because a `down` method exists.

7. Do not assume `php artisan migrate:rollback` is safe for production recovery.

8. Do not invent table sizes, traffic levels, database engine behavior, indexes, constraints, or deployment details.

9. Separate confirmed findings from assumptions.

10. If the database engine is unknown, assume a conservative production database and ask the user to confirm whether it is MySQL, MariaDB, PostgreSQL, SQLite, or another engine.

11. If table size is unknown, treat large-table operations as risky until proven otherwise.

12. If the migration touches customer data, payment data, user identity, authorization, subscriptions, orders, logs, or analytics events, flag it as high-impact.

13. If the migration affects public-facing behavior, queues, scheduled jobs, billing, permissions, or authentication, include a human review gate.

14. Prefer expand-backfill-contract rollout phases for risky changes.

15. Recommend minimal code edits only when they reduce migration risk or improve deployment compatibility.

16. Keep the output practical enough for a Laravel developer to act on before deployment.

## Review Process

Follow this process before writing the final answer.

1. Read the migration files.

2. Identify every schema operation in each migration.

3. Identify affected tables, columns, indexes, foreign keys, constraints, and data changes.

4. Inspect related Laravel code that reads from or writes to the affected schema.

5. Identify application compatibility risks during rolling deploys.

6. Identify destructive operations.

7. Identify long-running operations.

8. Identify table-locking or index-build risks.

9. Identify nullable and non-nullable transition risks.

10. Identify default value risks.

11. Identify foreign key risks.

12. Identify unique index risks.

13. Identify backfill needs.

14. Identify rollback hazards.

15. Identify recovery requirements.

16. Recommend a safer rollout plan.

17. Provide verification commands and manual checks.

## Common Migration Risks to Check

Review for these specific hazards:

1. Adding a non-null column without a safe default.

2. Adding a column with an expensive default on a large table.

3. Changing a column type in place.

4. Renaming a column that live code still reads.

5. Dropping a column before all code paths stop using it.

6. Dropping or changing an index used by production queries.

7. Adding a unique index before duplicate data is cleaned.

8. Adding a foreign key to a large existing table without checking bad rows.

9. Running data backfills inside the migration transaction.

10. Running large updates in one query without batching.

11. Running slow migrations during normal traffic.

12. Using Laravel schema methods that behave differently across database engines.

13. Depending on `doctrine/dbal` behavior for column changes without confirming compatibility.

14. Creating indexes in a way that blocks writes.

15. Combining schema changes and data transformations in one migration.

16. Combining expand and contract steps in one release.

17. Relying on rollback for irreversible data transformations.

18. Breaking old code during a rolling deployment.

19. Breaking queued jobs that still expect the old schema.

20. Breaking scheduled tasks, reports, exports, or API consumers.

## Safer Rollout Patterns

Use these patterns where appropriate.

### Expand Phase

Add new nullable columns, new tables, new indexes, or compatibility code without removing old schema.

### Dual-Write Phase

If needed, update application code to write to both old and new fields while reads remain compatible.

### Backfill Phase

Backfill existing records in safe batches using a command, job, queue, or controlled script rather than one dangerous migration.

### Read-Switch Phase

Switch reads from old schema to new schema only after backfill verification passes.

### Contract Phase

Remove old columns, old indexes, old code paths, and compatibility logic only after the new path is stable.

### Cleanup Phase

Remove temporary commands, flags, logging, and compatibility code after production verification.

## Output Format

### 1. Executive Summary

Provide a short summary of:

1. Overall migration risk level.
2. Whether the migration appears safe for production.
3. Main hazards found.
4. Whether zero-downtime deployment is realistic.
5. Recommended decision.

Use one of these decisions:

1. Safe to deploy as written.
2. Safe with minor changes.
3. Requires phased rollout.
4. Requires backfill plan before deployment.
5. Not safe for production as written.
6. Not enough information to decide.

### 2. Migration Inventory

Create a table with:

1. Migration file.
2. Affected table.
3. Operation.
4. Columns or indexes affected.
5. Data affected.
6. Risk level.
7. Notes.

### 3. Migration Risk Assessment

Assess each risk area:

1. Table lock risk.
2. Long-running operation risk.
3. Data loss risk.
4. Rollback risk.
5. Backfill risk.
6. Application compatibility risk.
7. Queue and job compatibility risk.
8. Index risk.
9. Foreign key risk.
10. Unique constraint risk.
11. Deployment-order risk.
12. Maintenance-window risk.

Use this scale:

1. Low.
2. Medium.
3. High.
4. Unknown.

Explain every high or unknown risk.

### 4. Unsafe or Risky Operations

List any operations that should not be run as-is in production.

For each one, include:

1. File.
2. Operation.
3. Why it is risky.
4. Production impact.
5. Safer alternative.
6. Whether code changes are needed.

### 5. Safe Rollout Plan

Provide a phased rollout plan.

Include:

1. Pre-deployment checks.
2. Expand migration.
3. Compatibility code changes.
4. Backfill approach.
5. Verification after backfill.
6. Read-switch or behavior-switch step.
7. Contract migration.
8. Cleanup.
9. Final verification.

If a phased rollout is not needed, explain why.

### 6. Backfill Plan

If data backfill is needed, provide:

1. What data must be backfilled.
2. Estimated risk based on known table size.
3. Batch size recommendation.
4. Whether to use an Artisan command, queued job, scheduled job, or manual script.
5. Idempotency requirements.
6. Progress tracking.
7. Retry behavior.
8. Failure recovery.
9. Verification query or check.
10. When it is safe to continue to the next phase.

If no backfill is needed, say so.

### 7. Code Compatibility Notes

Review whether old and new code can run safely during deployment.

Check:

1. Models.
2. Fillable or guarded fields.
3. Casts.
4. Accessors and mutators.
5. Validation rules.
6. Controllers and services.
7. Jobs and queues.
8. Scheduled tasks.
9. Events and listeners.
10. API resources.
11. Tests.
12. Factories and seeders.

Explain any compatibility issue.

### 8. Rollback and Recovery Plan

Do not rely only on the migration `down` method.

Provide:

1. Whether rollback is safe.
2. Whether rollback can cause data loss.
3. Whether a database backup is required.
4. Whether the application can continue running if rollback is partial.
5. Recovery steps if the migration fails midway.
6. Recovery steps if the backfill fails.
7. Recovery steps if the application deploy must be reverted.
8. Human approval gates before destructive rollback.

### 9. Recommended Migration Edits

If edits are needed, describe the minimal safe changes.

For each recommended edit, include:

1. File.
2. Current issue.
3. Recommended change.
4. Why it reduces risk.
5. Whether it changes application behavior.

Only recommend code edits that are necessary for migration safety.

### 10. Verification Commands

Provide commands and checks for:

1. Static review.
2. Laravel migration status.
3. Migration dry-run or SQL preview where possible.
4. Test suite.
5. Database checks.
6. Backfill verification.
7. Post-deployment verification.
8. Rollback readiness.

Use commands appropriate to the repository.

If a command depends on missing project details, mark it as a suggested command and ask the user to confirm.

### 11. Production Deployment Checklist

Create a checklist for the release owner.

Include:

1. Backup confirmed.
2. Maintenance constraints confirmed.
3. Table sizes checked.
4. Indexes checked.
5. Migration reviewed.
6. Application compatibility checked.
7. Queue workers considered.
8. Backfill plan reviewed.
9. Rollback plan reviewed.
10. Monitoring prepared.
11. Human approval received.
12. Post-deployment verification completed.

### 12. Human Review Gates

List the points where a human should approve before proceeding.

Include review gates for:

1. Destructive schema changes.
2. Customer data changes.
3. Payment or billing data changes.
4. Authentication or authorization changes.
5. Large-table operations.
6. Irreversible transformations.
7. Contract or cleanup migrations.
8. Production rollback.

### 13. Final Recommendation

End with:

1. Recommended decision.
2. Required changes before deployment.
3. Safest deployment sequence.
4. Highest-risk unresolved assumption.
5. Next action for the developer.

## Verification

Before finalizing, confirm that:

1. Every migration file was reviewed.

2. Every affected table was identified.

3. Destructive operations were flagged.

4. Long-running or locking operations were flagged.

5. Backfill needs were identified.

6. Rollback risk was assessed.

7. Application compatibility was reviewed.

8. Safe rollout phases were recommended where needed.

9. Verification commands were provided.

10. Missing assumptions were listed.

## Final Instruction to Begin

Begin now.

If migration files, database engine, table sizes, or deployment constraints are missing, ask for them first.

If enough context is available, inspect the repository and produce the full zero-downtime Laravel migration review in the requested markdown format.

## Variables to Replace

1. Repository context
2. Laravel version
3. Migration files
4. Related models
5. Related queries
6. Related jobs or queues
7. Related controllers or services
8. Database engine
9. Database version
10. Table sizes
11. Write volume
12. Read volume
13. Existing indexes
14. Deployment process
15. CI/CD process
16. Rollback requirements
17. Backfill needs
18. Application compatibility window
19. Maintenance constraints
20. Allowed downtime
21. Production traffic pattern
22. Backup process
23. Verification commands
24. Definition of done

## How to Use

Paste this prompt into Codex while working inside the Laravel repository. Add the migration file paths, database engine, table sizes, deployment process, rollback expectations, and any maintenance constraints. Use the output before running production migrations, especially when changing high-traffic tables, adding indexes, backfilling data, or removing columns.

## Example Use Case

A Laravel app needs to add non-null columns and indexes to a high-traffic orders table. The team uses this prompt in Codex to review the migration, split the rollout into expand, backfill, and contract phases, check rollback risk, and prepare verification commands before production deployment.

## Tags

1. laravel-migrations
2. zero-downtime
3. database-safety
4. codex
5. deployment-risk
6. rollback-plan
7. schema-changes
8. backfill-strategy
9. production-safety
10. database-locks
11. expand-contract
12. laravel
13. mysql
14. mariadb
15. postgresql
16. verification
17. release-safety

## Dates

Published: 2026-07-01
Updated: 2026-07-01