Preparing a production baseline before a major cutover
A practical checklist for capturing application behaviour before a high-stakes release so impact afterward is measurable.
Major releases attract optimistic forecasts. A baseline study is deliberately boring: it records how the applications behave now so later conversations have a shared “before.”
Capture a normal week, not a quiet hour
One quiet Sunday afternoon is a weak baseline. Prefer several weekdays that resemble the traffic you expect after cutover, including at least one peak window your operators recognise.
Name fragile paths early
Every application has a path that already wobbles — a report job, a partner API, a rarely used admin action. Documenting it before cutover prevents false blame afterward.
Freeze the signal list
Agree the signals in writing before the release. Adding new charts during the war room makes comparison impossible because nobody shares a definition of “worse.”
Separate change tickets from hopes
List the deployments and config changes that will ship. Keep product hopes in a different paragraph. Impact review is about what landed, not what the roadmap intended.
A Production Baseline Study at AutoDeploy HQ usually finishes one to two weeks before the cutover and leaves a short brief your release owner can reopen the morning after.