ShippedRollbacks
When a release causes trouble, use the build you already shipped. Review compatibility and restore a previous application release.
Restore an existing build
Choose a recorded release from the application’s history rather than rebuilding old source with today’s dependencies. Shipped uses the retained application artifact and compatible configuration, checks the service, and switches traffic through the deployment workflow. That gives you a concrete release to inspect and a result you can follow in the portal or through your agent.
Check what has changed around the code
An older application must still work with the current database schema, secrets, and connected services. Review compatibility before restoring it. Database migrations that remove a column or change a record’s meaning can make an old build unsafe, so design migrations with a recovery window or choose a forward fix when reverting the application would cause more damage.
Keep code recovery separate from data recovery
Rolling back code does not remove records created by the newer release, undo sent email, or reverse a third-party transaction. Investigate those effects separately. If data must be restored, use a deliberate data recovery procedure that accounts for current writes, then verify the application and its integrations against the state that will remain.
A little more detail
Questions about Rollbacks?
Does rollback run my database migrations backward?
No. An application rollback restores a compatible application artifact and configuration. Reversing or restoring database state is a separate operation and may not be safe after new writes have occurred.
Can I always restore any release in history?
The artifact must still be retained and compatible with the application’s current dependencies and state. A recorded release is useful history, but it is not a guarantee that every older version can safely run forever.
From your workspace to the web