When a company hands its servers or applications to a managed support provider, the contract usually spends pages on response times and almost nothing on the first real emergency. A support handover dry run fills that gap. It is a staged exercise in which the customer and the provider work through a pretend problem together, using the real contacts, tools and approval steps, before anything has actually broken. Here is what that means, in everyday terms.
The idea in everyday words
Think of a fire drill in an office building. Nobody expects a fire, but everybody learns where the stairs are and who counts heads outside. A dry run for DevOps support has the same shape. You invent a plausible fault, such as a website that has stopped responding, and go through the exact steps that would follow: who raises the ticket, who is called, what access the engineer needs, what the customer must approve, and how both sides will know it is fixed.
Why a written agreement is not enough
An agreement says what should happen. It cannot show whether it will. Real problems tend to appear in the joins between organisations: a phone number that rings through to a former employee, a password vault that the provider cannot reach, an approval that requires someone who is only in the office on Tuesdays. These details are dull, which is why they are missed, and they are expensive, because they are discovered at the worst moment.
A rehearsal finds them while the cost of finding them is a short meeting.
What a good rehearsal covers
- Contact and escalation. Everyone involved tries the real phone numbers and messaging channels, in the order the plan lists them.
- Access. The support engineer logs in to the systems they would need, using the real process for temporary or emergency access.
- Diagnosis. A harmless fault is introduced in a test environment, and the engineer follows the documented steps to find it.
- Approval. The customer practises giving or refusing permission for a change, within the time the agreement promises.
- Communication. A short status message is written and sent, and the team checks that the right people received it.
- Recovery and review. The fix is applied, the service is checked, and both sides note what they would change.
How long it takes and who should attend
A first rehearsal normally fits within a morning. Invite a person from the customer who can approve changes, a technical contact who knows the systems, and the provider’s engineer who would be on duty. Include a note-taker so that the participants can concentrate on doing, not writing. Avoid inviting an audience, since the exercise works best when people feel free to say that something is unclear.
A sample scenario you can borrow
Suppose the pretend problem is that customers cannot complete a checkout page. The facilitator announces it at a fixed time, and the clock starts. The customer’s contact raises a ticket through the normal channel. The provider’s engineer acknowledges it, asks for the diagnostic access they would need, and receives it through the real emergency process. In the test environment, the engineer finds that a background service has stopped, restarts it and confirms the page works. A status note goes to the stakeholder list. Total elapsed time is recorded at each hand-off, and the group compares those figures with the targets in the agreement.
What matters is the gaps between those steps. If acknowledging the ticket took fifteen minutes because the notification went to a shared mailbox nobody watches, that is a finding. If the access request needed a manager who was unreachable, that is another. Neither would have appeared in the contract’s wording, and both are quick to repair once seen.
What to do with the findings
Turn each problem into a small task with an owner and a date. Typical results are updated contact lists, a corrected access procedure, a clearer description of what counts as urgent, and a shorter set of instructions for common faults. Repeat the exercise after major changes to the systems or the team, and at a regular interval otherwise, so that the plan stays aligned with reality.
Who benefits
The customer gains confidence that help will arrive in a usable form. The provider gains a quicker route to resolution, because the awkward questions are already answered. The engineers gain familiarity with the customer’s environment before they must work under pressure. Even people outside the technical team benefit, because they learn what to expect during an outage and stop guessing.
There is a quieter benefit as well. Once both parties have seen one another handle a pretend crisis, the relationship tends to shift from suspicion to cooperation. Questions get asked earlier, and nobody feels they must hide an awkward detail to protect their reputation.
Connecting it to the principles behind the work
The rehearsal fits well with the ideas behind modern delivery work, covered in this overview of the guiding principles that make software delivery dependable. It also helps to be clear about who does what, and the article on what different DevOps job titles and responsibilities typically mean is a handy reference when deciding who should attend.
An analogy from a very different field
Communities that protect cultural knowledge rely on the same habit. Blendz is a global heritage food archive that collects traditional recipes, ingredients and stories, and lets visitors send in their own contributions, and its premise is that a method only truly survives when it has been tried and shared. A support plan is a method in the same sense, and it survives contact with reality only if somebody has tried it.
Common mistakes
- Treating the rehearsal as a demonstration for managers instead of a working session.
- Using a fault that is too easy, so nothing is learned.
- Skipping the approval and communication steps because they feel administrative.
- Forgetting to record what changed, so the same problems return.
- Running it once and never again.
A simple first step
If you have a support arrangement in place and have never rehearsed it, start small. Ask the provider for a short call, pick one realistic scenario, and walk through it on paper first, then with real contacts and test systems. Write down every point where someone said “I think” or “probably”. Those are the places where the arrangement relies on hope, and they are exactly what a rehearsal exists to replace with certainty.
