# How to Hand Off an IoT Deployment to the Operations Team > The handover package that keeps an IoT deployment healthy after launch: ownership map, access policies, alert runbook, health dashboard, and a shadow period. ![How to Hand Off an IoT Deployment to the Operations Team](https://tago.io/og/blog/hand-off-iot-deployment-to-operations-team.png) Launch day feels like the end of the project. The devices are reporting, the dashboards are green, the customer signed the acceptance form, and the build team moves to the next job. The people who inherit the system were not in the build. They did not pick the 7.5 threshold on the tank alert, they do not know why twelve devices are tagged "pilot", and the low-battery alert that fires at 2 a.m. goes to an engineer who rolled off in March. Six months later nobody can say how many devices are still reporting. That is how a working deployment rots. Nothing fails; the knowledge that kept it working leaks out one departure at a time. The fix is a handover package and a handover period, prepared before launch rather than assembled from memory after. This is the package we see work for TagoIO deployments, whether the ops team is the customer's staff or the integrator's own support rotation. ![Hand over a package, then shadow for two weeks: the build team passes an ownership map, access policies, alert runbook, health dashboard, documented logic, change process, and monthly review to the ops team, followed by a two-week shadow period where ops runs the system and the build team stays on call until it is removed from alerts and Admin](https://tago.io/images/blog/hand-off-iot-deployment-to-operations-team/handover-package-and-shadow-period.svg) ## Start with an ownership map Most handovers fail on a question nobody asked: who owns each part of the system. Write a one-page table with a named person (not a team mailbox) for each row: - Devices: who adds, replaces and retires them, and who gets called when one goes quiet - Dashboards and the TagoRUN portal: who changes what end users see - Alerts: who receives each Action, who may change a threshold - Users: who creates and removes TagoRUN users and their permissions - Billing and limits: who watches service usage and approves plan changes - Code: who owns the Payload Parser and each Analysis script If a row has no name, the handover is not finished. If every row has the build lead's name, it is not a handover. ## Replace shared logins with real access The most common shortcut at launch is one admin login shared across the ops team. It works for a week and then becomes untraceable: nobody knows who changed the threshold, and when someone leaves you cannot revoke their access without locking out everyone. Create TagoRUN users for the ops team and use [Access Management policies](https://docs.tago.io/docs/tagoio/tagorun/access-management/creating-a-policy) to give each role what it needs: a field technician sees the device list and health dashboard for their sites, a supervisor can acknowledge alerts and edit thresholds through a form, an administrator can create users. Write policies against device tags (site, customer) instead of device IDs, so they still hold when device number 300 is added next year. Keep the Admin console for builders, and keep the Admin user list short and written down. ## Write a runbook for every recurring alert An alert without a runbook is noise with a timestamp. For each Action that notifies a human, write a short entry: what the alert means in plain language, the first thing to check, what to do if the check confirms the problem, and when and to whom to escalate. It gets read at 2 a.m. on a phone, so keep it short. Then route the Actions to match. A [TagoIO Action](https://docs.tago.io/docs/tagoio/actions/defining-actions) can send email, SMS or push notifications to TagoRUN users, or call an Analysis, so an offline-gateway alert pages the on-call technician while a usage warning goes to the billing owner. Review every recipient list during handover, because it almost always still contains the build team. ## Build the device health view the ops team checks daily The build team knows the fleet is healthy because they watched it come alive device by device. The ops team needs that confidence from a screen: a health dashboard, separate from what end users see, showing last report time per device, battery level where the hardware sends it, and a count of devices offline for longer than a defined window. In TagoIO this is usually a Blueprint Dashboard driven by device tags, so one dashboard covers every site, with a table widget sorted by last report time so quiet devices float to the top. Add an Action that fires when a device has been silent longer than its expected interval; that one alert catches dead batteries, moved gateways and forgotten firmware updates. If the view takes more than a minute to read, simplify it. ## Document the logic that lives in code The threshold is 7.5 because the customer's process engineer said 8 was too late and 7 caused false alarms in July. That reasoning lives only in someone's memory unless it is written next to the value. Comment every scaling factor and unit conversion in the Payload Parser. Give each Analysis script a header saying what triggers it, what it reads and writes, and who asked for it. Where thresholds live in device parameters or a dashboard form, keep a table of current values and the reason for each. Write down the naming conventions: how devices are named, which tags are mandatory (site, customer, hardware model, install date), how the parser names variables. Half the fleet tagged `Site A` and the other half `site_a` breaks every policy and Blueprint filter that depends on it. ## Define how things change Deployments do not stay the size they launched at. Someone will add a site, swap a sensor model or ask for a new alert. Without a change process, each of these becomes a call to the build team, and the ops team learns to work around the system instead of through it. The process fits on a page: how to add a device (which Connector and Network, which tags, how to confirm it shows on the health dashboard), how to request a threshold change and who approves it, how to add a TagoRUN user, and what still needs the build team. Keep a change log, even a shared document, so when something breaks in October someone can see what changed in September. ## Schedule a monthly review Costs and limits drift quietly. Devices get added, an Analysis runs more often, fifty users open a dashboard with a long time range, and the profile's Data Input and Data Output usage creeps toward the plan limit. Put a 30-minute monthly review on the billing owner's calendar: check service usage against the plan, confirm the [data retention](https://docs.tago.io/docs/tagoio/devices/data-management/data-retention-feature) setting still matches what the customer needs, count the devices that have not reported in 30 days, and go through open items in the change log. Integrators who keep the operations role themselves already do this as part of a [recurring service](https://tago.io/blog/from-one-time-iot-projects-to-recurring-services); it is the review that keeps a [managed service profitable](https://tago.io/blog/what-a-profitable-iot-managed-service-business-model-looks-like) instead of a slow bleed. ## Shadow for two weeks before you leave The package above is necessary and not sufficient. Documents get read once; habits form by doing. For two weeks after launch, the ops team runs the system with the build team still on call: they handle every alert, add the next device, run the first monthly review. The build team answers questions and, more usefully, fixes what the documents missed while the knowledge is fresh. Close with a short meeting: walk the ownership map once more, confirm every alert has fired in a test and reached the right person, then remove the build team from recipient lists and any Admin access they no longer need. That is when the project is done. ## Handover checklist - Ownership map with a named person per row - TagoRUN users and Access Management policies per role; shared logins removed - Runbook entry for every Action that notifies a human; recipients verified - Health dashboard (last report, battery, offline count) with a silent-device alert - Comments in Payload Parser and Analysis code; threshold table; tag conventions - One-page change process and a change log - Monthly review covering usage, retention and offline devices - Two-week shadow period with a closing meeting [llms.txt](https://tago.io/llms.txt)