Swiss Handover Checklist: 6 essentials for construction and software

A complete handover documentation checklist delivers six things: a document register, as-built drawings, operation and maintenance manuals, warranties and certificates, commissioning records, and a signed acceptance protocol backed by training records. Passing acceptance means the operational team can run, maintain, and troubleshoot the asset without calling the original delivery team back in. Miss any of these six, and the handover looks finished on paper while operations quietly struggle behind the scenes.

---

TL;DR:

• Proper organization of documents by function ensures each stakeholder can access the relevant handover materials without wading through unrelated files.

• Deliver provisional documentation 30 days before acceptance to allow review, and provide final revisions within 90 days after acceptance, accounting for correction periods.

• Assign clear ownership for each document type early in the project to prevent confusion, ensure accountability, and streamline approval and verification processes.

• Maintain a comprehensive document type catalog with standardized formats, metadata, and version control to facilitate long-term archiving and easy retrieval.

• Incorporate structured checkpoints such as pre-closing reviews, commissioning, acceptance meetings, and final two-year warranty reviews to avoid late delays and ensure completeness.

---

Master handover documentation checklist grouped by category

A handover package works best when it is organized by function rather than dumped into one folder. Group the documents so each recipient, whether that is facilities management, an operations lead, or a finance officer, can find what they need without wading through everything else.

Administrative documents cover the paper trail of the project itself:

• Project files and correspondence, including change orders and approved variations

• Contracts, subcontracts, and purchase orders tied to delivered work

• Certificates of compliance, insurance, and regulatory approvals

• A contact list for contractors, suppliers, and specialists involved in delivery

• A master document register that indexes every file by type, version, and status

Technical documents describe what was actually built or deployed:

• As-built drawings that reflect the finished condition, not the original design

• Control schematics and wiring or piping diagrams

• Data point lists for building management systems or equipment controllers

• Software repositories, configuration files, and integration diagrams for digital components

Operational documents let the receiving team run the asset day to day:

• Operation and maintenance (O&M) manuals for every major system

• Spare parts lists with supplier references and reorder information

• Service contracts and maintenance schedules already in place

• Manufacturer and contractor warranties with start dates and coverage terms

Construction handover packages should include as-built drawings, O&M manuals, warranties, commissioning records, operator instructions, and a document register as the baseline for long-term operation, according to guidance on defect remediation and handover documentation.

Commissioning and test records prove the systems work as intended:

1. Functional test reports for equipment and integrated systems

2. Measurement and performance reports (airflow, pressure, electrical load, and similar)

3. Commissioning certificates signed by the responsible engineer or contractor

4. Integration test logs for systems that depend on each other to function

Punch list and outstanding defects need their own dedicated section rather than a footnote:

• An itemized list of open defects with location, description, and photo evidence

• Assigned owner and deadline for each item

• Remediation evidence once resolved, including sign-off from the verifier

Delivery evidence closes the loop and protects both sides if a dispute arises later:

• A file manifest confirming what was delivered and when

• Digital signatures or timestamps on final versions

• Clear markers distinguishing provisional delivery from final, revised delivery

That last point matters more than it sounds. A document delivered as “provisional” and later revised needs a version marker that makes the difference obvious, otherwise operations may end up working from an outdated draft months after the real final version existed.

Handover timelines and required submission windows

Documentation always seems to slip in project schedules because it competes with commissioning, punch-list closure, and last-minute change orders. Building submission deadlines into the project plan from day one prevents that slippage.

Provisional documentation should reach the client sufficiently ahead of official acceptance to allow for review and clarification, giving operations time to review, flag gaps, and request clarifications before the handover meeting. Practice guidance from Basel-Stadt’s construction documentation directive sets this window at 30 days for provisional submission and requires the final, revised documentation within 90 days after acceptance.

That 90-day window exists because as-built drawings and O&M content often need corrections discovered during the first weeks of operation, corrections that would be premature to lock in before the asset has actually run.

A practical phase-gate plan builds in four checkpoints:

• Pre-closing review: draft documentation checked against the document register for completeness

• Commissioning and integral tests: functional and performance test records generated and filed

• Acceptance meeting: provisional documentation delivered, punch list reviewed, protocol signed

• Two-year final review: warranty and latent-defect period closes, final corrections logged

Teams that build these checkpoints directly into their Gantt chart or phase-gate structure, rather than treating documentation as an end-of-project scramble, consistently avoid the late-delivery bottleneck that stalls formal acceptance.

Roles, responsibilities and acceptance sign-offs

Handover documentation fails most often not because a document is missing, but because nobody was clearly responsible for producing, checking, or accepting it. A compact ownership model fixes that before it becomes a problem.

Five roles cover most handover scenarios:

• Document owner: the person or firm responsible for producing a specific document type

• Submitting contractor: delivers the document into the register on schedule

• Verifier: client or facility management representative who checks content against requirements

• Commissioning lead: confirms test records and functional data are complete and accurate

• Operations trainer: ensures training artifacts pair correctly with the documents they explain

Each sign-off should confirm something specific rather than a blanket approval. The verifier checks that content matches the as-built condition, the commissioning lead checks that test data is genuine and complete, and the operations trainer checks that staff have actually received and understood the material, not just that a session happened.

Unclear ownership for document creation and acceptance is the most common cause of handover failure, and assigning a document type catalog with named owners early prevents the scramble that otherwise hits at project end, according to construction handover checklist guidance.

Pro Tip: Adopt the document type catalog in the kickoff meeting, not the closeout meeting. Assigning an owner to each document type before work starts turns handover into a running checklist instead of a last-minute audit.

Document standards, delivery formats and the document type catalog

File format choices matter more once the project is over and nobody remembers which software created the original file. PDF/A is the standard for long-term archival because it embeds fonts and locks formatting; DWG or PDF works for drawings depending on whether the recipient needs to edit them; CSV or JSON suits data exports that facility management systems will import directly.

Minimal metadata to require on every file:

• Project name and reference number

• Document type (matched to the catalog)

• Version number and date

• Author or responsible party

Some jurisdictions require digital files to be delivered uncompressed, in specified formats, with metadata aligned to a document type catalog, with paper copies required only if the client specifically asks for them, per Basel-Stadt’s documentation directive.

A document type catalog, structured along the lines of KBOB and SIA conventions, organizes deliverables into consistent categories: drawings, technical reports, certificates, contracts, and operational manuals. Mapping your project’s documents to a catalog like this early means nobody has to guess where a given file belongs, and the register practically builds itself as documents come in.

Commissioning, punch list and defect management

Commissioning proves the building or system works as designed, and the records generated during this phase form the backbone of the technical handover file.

1. Test protocols document each functional test performed, with pass or fail results

2. Measurement reports capture quantitative data such as flow rates, pressure, or load

3. Integral test logs record how interconnected systems perform together, not just in isolation

The formal handover process is typically multi-stage, requiring integrative tests, pre-acceptances, and a documented chain of custody for every handover document to ensure a clean transfer to operations, according to the Bauprojektsteuerung acceptance guidance.

The punch list needs the same rigor as the main document set. Each item should carry a priority level, a named owner, a due date, and remediation evidence once closed, whether that is a photo, a retest result, or a signed confirmation.

Pro Tip: Tie punch-list closure directly to warranty retention and final invoicing. Contractors resolve open items faster when the final payment, not just the goodwill, depends on it.

Verification, acceptance protocols and legal checkpoints

The acceptance protocol is the single document that formally transfers responsibility from delivery team to operations, so its contents deserve more care than most teams give them.

A complete acceptance protocol includes:

• The scope of work being accepted, stated precisely enough to avoid later disputes

• The effective date of transfer

• Any outstanding items, referenced back to the punch list

• Signatures from every required party, with names and roles clearly printed

SIA 118-related checklists, commonly used for construction acceptance, recommend a two-year final review period for warranty and latent-defect claims following the SIA 118 acceptance checklist guidance. Tracking this window matters because it is often the only formal recourse available once a defect surfaces after the initial punch list closed.

Keep versioned archives and delivery receipts for every submission, provisional and final alike. These records are the evidence that documentation was delivered on time, in the required format, and accepted by the right person, which matters if a dispute over responsibility ever arises months later.

Training, instruction and operational handover

Documentation without training gets read once and then ignored. Pairing the two means operations staff can actually use what they received.

Different audiences need different formats:

• Facility managers: hands-on workshops covering system operation and troubleshooting

• Maintenance staff: walkthroughs of physical systems paired with the O&M manuals

• Remote or shift staff: recorded sessions and quick-reference cards for offline use

Training artifacts belong in the handover package alongside the technical documents: attendance lists, trainer notes, recorded demo sessions, and quick-start guides all count as evidence that instruction happened and who received it.

Timing training to align with provisional documentation and commissioning means trainees practice with materials that are close to final, rather than learning from a draft that gets substantially revised before the ninety-day final submission arrives.

Records, archiving and maintaining the handover register

Once acceptance is signed, the documentation needs a permanent home. That is usually the facility management system for operational content and a project archive for administrative and contractual records, with digital storage preferred for searchability and paper retained only where explicitly required.

Version control matters as much in the archive as it did during delivery:

• Store one authoritative version per document, with prior versions clearly marked as superseded

• Require the same metadata fields (project, document type, version, date, author) in the archive as during delivery

• Set a retention period that matches warranty and latent-defect windows, not just internal policy

Closing the archive formally means confirming the register is complete, every punch-list item is closed or tracked separately, and operations has acknowledged receipt of the full package before the project team disengages.

Software and digital project handover: what construction checklists miss

Construction-style checklists rarely mention the items that make or break a software or platform handover. A codebase without documented deployment steps is functionally undocumented, no matter how thorough the O&M manual looks for the physical building around it.

Digital handovers need their own line items:

• Repository access, including permission levels and branch protection policies

• CI/CD runbooks describing how builds deploy and roll back

• Deployment credentials, transferred through a secure process, not a shared spreadsheet

• Environment inventories covering staging, production, and any third-party services

• Monitoring and alerting documentation, including who gets notified and how

For software projects, deployment runbooks, repository access, environment inventories, and monitoring guides are easy to miss when a construction-focused checklist gets reused for a digital handover, since neither format was built with the other in mind.

Senior continuity from initial scoping through to handover reduces the rework that happens when the people who understand the original decisions leave before those decisions get documented. When the same engineers who scoped the project also write the runbooks and data-migration notes, acceptance goes faster because there is no gap between what was built and what got explained.

Pro Tip: Ask for backup and restoration procedures as a standalone document, tested at least once before handover, not just described in a paragraph inside the main runbook.

Ampersand’s approach to handover for websites, apps and platforms

Most software handovers fail for the same reason construction handovers do: the people who built the thing are gone before the people running it fully understand it. Ampersand keeps senior engineers involved from the first consultation through to handover, so the runbooks, environment inventories, and deployment documentation come from the people who made the original decisions, not a summary written after the fact.

For teams managing a legacy system migration or a new web or mobile app build, that continuity shows up directly in the handover package: documented runbooks, a knowledge-transfer session with the actual builders, and a clear path to ongoing support through the Run & improve or Run & monitor plans rather than a one-time document drop. The Run & monitor plan runs 750 CHF per month for teams that want monitoring and support to continue past the handover date.

If a project needs senior technical leadership through the transition itself, Ampersand’s fractional CTO support covers that gap without a full-time hire. Check current pricing and plans to see which arrangement fits your handover.

Authoritative templates, standards and guidance

The checklist items and timelines above draw on established construction and project handover practice:

• Basel-Stadt’s construction documentation directive sets the 30-day provisional and 90-day final submission windows and digital delivery norms

• Construction handover and defect-remediation guidance covers required document types and the document type catalog approach

• SIA 118 acceptance checklist guidance details the two-year final review period for warranty claims

• Bauprojektsteuerung acceptance guidance explains the multi-stage integrative test and custody chain for handover documents

Sources

• Richtlinie Bauwerksdokumentation (Basel‑Stadt)

• Bauabnahme

• Bauprojektsteuerung Merkblatt - Abnahmen (HOCH Merkblatt)

FAQ

What documentation is required at handover?

A complete handover requires as-built drawings, O&M manuals, warranties, certificates, commissioning records, and a document register, according to construction handover guidance. For software or platform projects, add deployment runbooks, repository access details, and environment inventories to that same package.

How do I prepare a handover checklist?

Start with a document type catalog that groups deliverables into administrative, technical, operational, and commissioning categories, then assign an owner to each document type before work begins. Build submission deadlines into the project schedule, following the practice of delivering provisional documentation at least 30 days before acceptance and final documentation within 90 days after, per Basel-Stadt’s directive.

What is a handover document?

A handover document is any record that transfers knowledge, responsibility, or operational capability from a delivery team to the party who will run the asset going forward. That includes technical records like as-built drawings and O&M manuals, administrative records like warranties and certificates, and the acceptance protocol that formally confirms the transfer.

What are the key principles of a clean handover process?

The core principles are completeness, clear ownership, and timely submission: every document has a named owner, every deliverable maps to a document type catalog, and provisional versions arrive early enough for review before final acceptance. A multi-stage process with a documented chain of custody, as outlined in acceptance process guidance, reduces disputes over what was delivered and when.

Recommended

• Repa Immobiliare: Getting a property portfolio off paper, with software that never goes online.

• MVP, Web & Mobile App Development Zürich

• Atelier Crincoli: A goldsmith’s whole workshop in one system, so no piece and no deadline goes missing.