Live
In short
Live is production: the new system takes over, the old one is retired, and the same governed workflow keeps shipping changes with versioning, monitoring and backups behind them.
Live is the Live Server: real users, real data, on production AWS infrastructure. Going live is not the end of the project. It changes what a mistake costs, which changes how changes are made.
What is different in Live
- Every change is versioned and restorable; going back creates a new version rather than erasing history.
- Monitoring and alerting are on, and incidents have somewhere to be recorded.
- Backups run on a schedule, and restores are drilled rather than assumed.
//!SAFEreview matters more than it did in Design, because the diff you skim is now running against customers.
Shipping after go-live
The workflow does not change: ask, review the diff, verify, promote. What changes is the discipline around it. Proving a change on Rehearsal before it reaches Live is the habit that keeps the app boring.
Changes reach users through the Publish page. Publish to the Rehearsal Server first; each publish becomes a numbered release. When you then publish to Live, the page offers the release the Rehearsal Server is running by default, so Live gets exactly what you tried. Publishing the latest changes straight to Live is still possible, and the page warns you that they haven’t been through Rehearsal. See the servers for the details.
Retiring the old system
Plan the cutover explicitly: what stays readable for how long, who has access to it afterwards, and how long you keep the ability to fall back. A retired system that is still quietly serving one department is not retired.
Staying current
Sapilon keeps the project aligned with evolving templates and dependencies through upgrade-aware diffs, so the app does not slowly rot into a rewrite. Updates land under the same ownership zones as everything else.