Separate the release from the rollout.
A vendor can have one release and many customer situations: different maintenance windows, disconnected hosts, older application versions and different recovery constraints. Treating “version available” as “ready to deploy everywhere” hides that work.
Start with a release definition that does not change between customers: exact image content, allowed configuration, expected starting versions, storage layout, health checks and migration behavior. Then create an installation-specific plan that adds the destination and approved window.
Make the handoffs explicit.
- Vendor preparation: identify and sign the release, document prerequisites and define the expected outcome.
- Customer readiness: verify the destination, available resources, image content and recovery material.
- Permission: approve the exact change for that installation during a bounded window.
- Execution: record that work started before changing the application, then retain the result.
- Acceptance: check health and application data, not just the container exit status.
Assign an owner to each handoff. A short written checklist with named responsibility is more useful than an elaborate process in which everyone assumes someone else checked the backup.
Ask for evidence that answers a question.
A timestamp says when something happened. An image digest says which content was intended. A host identity says where it was allowed to happen. A customer approval says who permitted it. A health check says something specific about the resulting application. None of these replaces the others.
Keep one operation identifier across the approval, execution journal and result. If a network connection breaks after the host starts, that identifier lets you inspect the existing operation rather than create a second one and hope the first did nothing.
Plan the unhappy path before the window.
Distinguish a rejected plan, a disconnected worker, a known failed operation and an unknown outcome. Each needs a different response. An unknown result should stay unknown until the host journal and actual application state can be reconciled.
Write down who may inspect the host, who holds the backup key and which steps could destroy newer data. Recovery that replaces application data requires more care than restarting a service. A database migration may make the old application image incompatible with the current database.
Measure the work you are trying to remove.
For one representative update, record vendor preparation time, customer coordination time, host work and follow-up. Repeat for a successful update and a recovery exercise. Keep the ongoing review effort in your estimate; a tool cannot remove the need to understand a risky migration.
The Shipstead calculator can turn those measurements into a monthly capacity estimate. It does not turn saved minutes into guaranteed revenue or reduced payroll.
Where Shipstead fits.
Shipstead implements a defined signed-package, customer-approval and scoped-execution workflow. It is intended for vendors maintaining a repeatable Docker application on dedicated customer engines. It is not a replacement for arbitrary infrastructure automation or application-specific migration design.
Inspect the workflow, then check the planned scope. Production acceptance remains open; the local implementation is evidence to inspect, not a reason to skip your own application qualification.