Rehearsal

Rehearsal is the stage most projects skip and most incidents come from. The app runs on the Rehearsal Server, real AWS infrastructure configured the way production will be.

What you rehearse

• The data migration. Import from the old system with realistic volume, and do it more than once. The first run always teaches you something.
• The journeys. The people who will use the app walk through their real work, not a demo script.
• Security posture. Access, secrets, network boundaries, and what is exposed publicly.
• Running cost. What this will cost per month at your actual usage, before it is your production bill.
• Backups and restore. Prove a restore works while nothing depends on it.

Realistic data, safely

Rehearsal wants production-shaped data, which means production-shaped risk. Sensitive fields are masked when data is copied down, so the rehearsal is realistic without spreading personal data into a second environment.

When a Rehearsal Server is overkill

Not every project needs one. When you move from Build to Rehearsal you choose how the project runs, and a small project with nothing costly riding on it can skip the separate Rehearsal Server: its Live Server serves Rehearsal too, and going Live switches it over. Some projects can’t skip it. A project where a day of downtime would be costly, or a change that alters existing data, needs a Rehearsal Server first.

Skipping it now doesn’t lock you in. You can add a Rehearsal Server later from the Architecture page. Sapilon shows the steps involved before anything starts.

Signs you are ready to leave

• The migration has run cleanly end-to-end, timed, with a rollback you have actually tested.
• No open findings you would be uncomfortable explaining after an incident.
• The monthly cost estimate is one you have accepted.
• Everyone knows what happens to the old system on the day.

Next: Live · Promoting between stages