Turnover Package Checklist: Docs, Baselines, Spares, and Runbooks

A ground station turnover is successful when a new team can operate the station safely, repeatably, and without tribal knowledge. The turnover package is the set of documents, baselines, inventories, and procedures that make that possible. This guide lays out a practical checklist for what to include, how to organize it, and what “done” looks like in day-to-day operations.

What a Turnover Package Is and When You Need One
The Core Structure: How to Organize the Package
Documentation Checklist: What to Include
Baselines and Known-Good Configurations
Spares and Inventory: What to Stock and How to Track It
Runbooks and Operational Procedures
Access, Accounts, and Security Handover
Acceptance Tests and Handover Validation
Common Gaps That Cause Trouble After Turnover
Keeping the Package Current After Handover
Glossary: Turnover Terms

What a Turnover Package Is and When You Need One

A turnover package is the operational “source of truth” for a ground station. It captures how the station is built, how it is configured, how it is operated, and how it is restored when something goes wrong. It is used whenever responsibility changes hands, including:

Commissioning to operations: when a build team hands off to the operations team.
Vendor to owner-operator: when a hosted or managed service transfers ownership.
Team transitions: new operators, new engineers, or new shift rotations.
Network integration: when a station becomes part of a multi-site network.

The goal is not to create paperwork. The goal is to prevent “only one person knows how this works” and to reduce outage duration when incidents happen.

The Core Structure: How to Organize the Package

Organization matters as much as content. If people cannot find the right item during a pass window, it will not be used. A practical structure is simple, stable, and consistent across stations.

A common structure includes:

Overview and site facts: what the station is, what it supports, and where the boundaries are.
Architecture and diagrams: RF chain, control systems, networking, power, and environmental systems.
Baselines and configs: known-good parameters and the way to restore them.
Operations runbooks: normal workflows and exception handling.
Spares and inventory: what to replace and how fast you can recover.
Security and access: accounts, roles, and emergency access procedures.
Acceptance tests: how to prove the station is healthy after changes or turnover.

A good rule is: if you need it during an outage, it belongs in the turnover package.

Documentation Checklist: What to Include

Documentation should focus on what operators and engineers actually use. Long vendor manuals can be referenced, but the turnover package should contain the station-specific facts that are hardest to reconstruct.

Station overview and boundaries

Mission support summary: bands supported, typical pass types, and operational hours.
Interfaces: how the station connects to mission systems and where responsibility changes hands.
Constraints: site limitations, local restrictions, and any operational do-not-do rules.

Diagrams and layouts

RF block diagram: antenna to modem path, including major components and signal direction.
Network diagram: VLANs or zones, critical routes, and backhaul paths.
Power diagram: mains, UPS, generator, transfer switch behavior, and critical loads.
Physical layout: rack layout, cable labeling scheme, and equipment locations.

Operational reference

Contact procedures: how a pass is scheduled, executed, monitored, and closed out.
Alarm list: which alarms matter most and what actions are expected.
Maintenance windows: standard times and required approvals.

Baselines and Known-Good Configurations

Baselines are the fastest path to recovery. They answer “what should this station look like when it is healthy?” and make it possible to detect drift.

Baseline items to capture

Antenna baseline: pointing model version, encoder settings, tracking modes, and limit configurations.
RF chain baseline: converter frequencies, filter selections, attenuation settings, and expected signal levels at key points.
Modem baseline: profiles for common missions, including demod settings and expected lock thresholds.
Timing baseline: reference source, distribution paths, and monitoring thresholds.
Network baseline: IP addressing, routes, firewall rules, and critical DNS/NTP dependencies if used.
Monitoring baseline: what is monitored, alert thresholds, and who receives alerts.

Baselines should include a short “how to restore” note. A baseline that cannot be applied quickly is not a baseline, it is just a record.

Spares and Inventory: What to Stock and How to Track It

Spares strategy is about recovery time. If a part can fail and its replacement lead time is weeks, you need a plan. That plan may include holding spares on site, stocking regionally, or having a rapid ship arrangement.

What to include in the spares section

Critical spares list: items that can stop operations (power supplies, converters, cables, network modules, storage components).
Recommended quantities: how many to stock and why (failure rate, lead time, and mission criticality).
Storage conditions: temperature, humidity, and handling notes for sensitive parts.
Compatibility notes: firmware versions, connector types, and “works only with this model” constraints.
Swap procedure reference: link the spare to the runbook steps for replacement and verification.

Inventory tracking that stays usable

Inventory should be easy to update and easy to audit. Keep it focused on what affects operations: part identification, location, quantity, and status.

Location tracking: shelf or bin identifiers so parts can be found quickly.
Status tracking: new, tested, in-use, returned, or quarantined.
Rotation practice: periodically test spares and rotate where aging matters.

Runbooks and Operational Procedures

Runbooks are the day-to-day backbone of a station. They should cover both normal operations and the common failures that cause missed contacts. Good runbooks are written for speed and clarity, not for completeness.

Operational runbooks to include

Pass execution: step-by-step checklist for setup, acquisition, monitoring, and closeout.
Data delivery: how data is packaged, validated, and transferred to downstream systems.
Alarm response: what to do for top alarms, with timeboxed troubleshooting steps.
Fallback modes: how to operate in degraded mode when a component is down.
Maintenance: routine inspections and calibration checks that prevent bigger incidents.
Disaster recovery: what to do when the site or core systems are unavailable.

Runbook quality checks

Time realism: can the steps be completed within the required recovery window?
Tool realism: do the steps rely on systems that might be down during the incident?
Decision points: does the runbook tell operators when to stop and escalate?
Verification: does it include clear checks to confirm the station is back to normal?

Access, Accounts, and Security Handover

Access handover is one of the most common turnover failure points. If the new team cannot reach the right systems safely, they will create unofficial workarounds. The turnover package should define access clearly and include emergency paths that are controlled and auditable.

Access items to capture

Account roles: operator, engineer, admin, and read-only accounts with clear boundaries.
Access paths: how to reach control networks, monitoring, and data delivery systems.
Credential rotation plan: how and when credentials are changed during turnover.
Emergency access: controlled “break glass” procedure with logging and post-use review.
Vendor access: who approves it, how it is enabled, and how sessions are recorded.

The access section should also spell out what is forbidden: shared passwords, direct internet exposure of control systems, and unmanaged remote desktop access.

Acceptance Tests and Handover Validation

A turnover package is not complete until it is validated. Validation means proving that the new team can operate the station using the package, and that the station meets expected performance for the missions it supports.

Practical acceptance tests

Connectivity tests: confirm remote access, monitoring visibility, and data delivery paths.
Timing tests: confirm stable reference distribution and correct time tagging.
Pass rehearsal: execute a controlled pass from schedule to delivery, including normal closeout.
Alarm injection: validate that monitoring detects issues and runbooks guide response.
Recovery drill: restore a known-good configuration from baseline and verify outcomes.

Acceptance should produce a short record: what was tested, what passed, what failed, and what needs remediation. That record becomes part of the turnover package.

Common Gaps That Cause Trouble After Turnover

Many problems after turnover come from the same missing pieces. Knowing them helps you spot issues early.

Missing baselines: teams cannot tell whether the station is healthy or drifting.
Unclear ownership: no one knows who to call for power, backhaul, or specific hardware.
Runbooks without verification: steps exist, but no clear way to confirm success.
Hidden dependencies: operations rely on an undocumented external service or a personal workstation.
Untracked spares: parts exist but cannot be found, or are untested and fail when needed.
Access confusion: accounts exist but do not have correct permissions, leading to unsafe workarounds.

The turnover package should explicitly address these gaps. If any are present, they tend to show up during the first incident.

Keeping the Package Current After Handover

Turnover is not a one-time event. Stations evolve. If the turnover package is not maintained, it becomes misleading. The easiest way to keep it current is to tie updates to existing operational processes.

Practical maintenance habits:

Update after changes: every approved configuration change should include a baseline update if it alters “known good.”
Update after incidents: every major incident should produce a runbook improvement and evidence expectations.
Quarterly review: check spares, access lists, and diagrams for drift.
Ownership assignment: one role owns the package even if many contribute to it.

The best indicator of success is simple: when a new operator joins, they can learn the station using the package and run a safe pass without guessing.