General Manager
If I were receiving a newly integrated service, I would ask the project team to sit beside the people who will run it and watch them use the handover pack.
Give the receiving team a controlled failure to investigate. Can they find the relevant alert, identify the affected transaction and work out who needs to act? Or does every answer still come from the engineer who built the integration?
That exercise tells me more about the handover than the number of documents in the folder.
A systems integration handover should establish that the receiving team has the knowledge, access and tested procedures needed to operate the agreed service. Documents support that outcome. The acceptance process should include a demonstration that they can be used.
Begin with the actual workflow. For example, a customer order leaves one system, passes through an integration service and creates a record in another. State which parts each team supports and where responsibility changes.
Include the business effect of failure. A delayed order and a duplicated order may use the same connection, but they require different responses. The service owner should know which failures can wait and which need immediate attention.
Keep the scope concrete enough that someone can tell whether an incident belongs to this service. Record dependencies on identity, networks, certificates, queues and external providers where they apply.
I would also name the person authorised to accept the handover. Attending a demonstration should not accidentally make someone responsible for risks they have no authority to accept.
Use an agreed test environment or an approved, controlled exercise. Define safeguards and stopping conditions before introducing a fault. Do not create a production incident just to make a handover look thorough.
The project team can observe and answer questions, but the receiving team should perform the relevant actions with its own approved access. Shared administrator credentials would hide a problem the exercise is supposed to reveal.
| Exercise | What I would ask to see |
|---|---|
| Investigate a failed transaction | Find the record across the connected systems and explain where it stopped |
| Respond to an alert | Show who receives it, how they acknowledge it and when they escalate |
| Recover an interrupted flow | Follow the procedure, then reconcile the source and destination records |
| Handle a duplicate or retry | Demonstrate the agreed behaviour without creating an extra business transaction |
| Make an approved change | Find the dependency, apply the change safely and explain the reversal route |
| Transfer a support issue | Provide the evidence another team or supplier needs to investigate |
These are example exercises. The checklist should be adapted to the service and its risks, not treated as a certification.
Suppose the connection is restored after a queue has built up. The dashboard shows a healthy service, but some records may still be missing, delayed or duplicated.
I would ask the team to reconcile the business records as part of recovery. What left the source? What reached the destination? What needs to be retried, and what must not be retried because it has already completed?
The runbook should explain those distinctions in the language of the workflow. A generic instruction to restart the connector does not tell an operator how to establish whether the customer order is now correct.
Record the outcome of the exercise, including any manual work required. If recovery depends on a particular person recognising a pattern from memory, put that knowledge into a usable procedure and repeat the test.
Few handovers arrive without unresolved items. The issue is whether the receiving team knows what those items mean.
For each exception, record the consequence, the temporary arrangement, the responsible owner and the date it will be reviewed. A known alerting gap needs a specific monitoring arrangement. A missing recovery test needs a stated restriction or an agreed plan to complete it.
Some gaps should prevent acceptance. The organisation needs to decide that threshold before the final meeting, particularly where failure could affect sensitive information, payments or essential operations.
Microsoft's operational security checklist provides a useful reference for reviewing access, monitoring and operational controls in Azure environments. It does not replace service-specific acceptance or the receiving team's own requirements.
Keep the accepted scope, the tested configuration, the exercise results and the remaining exceptions together. Name the location of the current runbook and the owner who must maintain it.
Set a review after the initial operating period. The first ordinary change, failed transaction or support escalation may reveal assumptions that were missed during the project. That review should update the operating material, not simply repeat the handover presentation.
This is how I want to frame Altaius's systems integration work: the service has to make sense to the people who inherit it. Before I called the handover complete, I would want to see them use the pack successfully while the project team is still available to correct it.
