Guide: Handover
From proof of concept to routine operation: the technical handover
A proof of concept has shown that an idea holds up, and now needs to move into routine operation. What separates the two states is less extra code than extra knowledge that has to be written down. Six artefacts make up a technical handover, and the best time to start building them is already during the pilot.
AI-GENERATED Short answer
A proof of concept is ready for routine operation once six artefacts exist: an architecture description, operations documentation, an access rights concept, a data model with migration history, named contacts, and a recovery plan. Together they turn a working application into one others can run, change, and restore. Without them, a PoC stays tied to its builders.
01
What separates an application that works from one that is operable?
An application works when it produces correct results under normal conditions. It is operable when people who did not build it can start it, change it, monitor it, and restore it after a failure. The first state is a property of the code; the second is a property of code, documentation, and organisation together.
A proof of concept answers one question: does it work at all? That is its purpose, and it is allowed to take shortcuts to get there. Routine operation asks different questions: what happens at night when the disk fills up? Who changes a business rule while the original developer is on holiday? How does the application come back after the server fails? The series From Prototype to a Production-Ready Application makes clear that these questions mostly never come up in a PoC, not out of carelessness, but because they play no part in proving feasibility.
The gap matters more now that AI tools speed up building. The DORA report from Google Cloud (2025) finds a positive correlation between AI use and software delivery throughput, but still a negative correlation with its stability. Built faster does not mean run more stably. The handover is the point where that gap gets closed.
Working or operable
| Criterion | Works | Operable |
|---|---|---|
| Start | Runs on one person's machine or account | Can be rebuilt from the repository by following instructions |
| Errors | Noticed when users report them | Detected before users report them, and reach a responsible role |
| Changes | Made directly in the live environment | Go through version control, a test environment, and traceable delivery |
| Database | Tables adjusted by hand as needed | Every schema change sits in the history as a migration |
| Access | Everyone involved is an administrator | Roles with limited rights, administration kept separate |
| Knowledge | Inside the heads of the people who built it | In artefacts that can be read without those people |
02
What is the path from a PoC to routine operation?
The path runs through five stages: feasibility in the proof of concept, a pilot with real users, hardening, technical handover, and routine operation. Each stage ends with a question that should be answered before the next one starts. The handover artefacts do not appear at the end; they grow from the pilot onward.
- 01Proof of conceptDoes it work at all?
- 02PilotDoes it help real users?
- 03HardeningDoes it withstand errors and misuse?
- 04HandoverCan others run it?
- 05Routine operationDoes it stay under control?
Proof of concept
Proves feasibility with little structure. Shortcuts are allowed, but should be noted so it stays clear later which parts are deliberately provisional.
Pilot
Real users, often real data, a limited group. From here on, basic operating rules apply: credentials kept outside the code, schema changes as migrations, a backup of the data.
Hardening
Enforce access rights server-side, handle error paths, write logs without personal data, bring dependencies to a maintained state.
Handover
The six artefacts exist and have been read by someone who was not involved in building it. A department built an app covers how IT decides on approval.
Routine operation
Monitoring, backups, updates, and the access concept run as part of daily life. Running an application in-house covers what that means over the long term.
03
Which artefacts belong in a technical handover?
A technical handover needs six artefacts: an architecture description, operations documentation, an access rights concept, a data model with migration history, a list of contacts defined by role, and a recovery plan. Each one answers a question that would otherwise land on the person who built the proof of concept.
Architecture description
What is the system made of, and why built that way?
Components, data flows, external services, and the key decisions with their reasoning.
Operations documentation
How does it run day to day?
Start, stop, configuration, dependencies, monitoring, and known failure patterns with their fixes.
Access rights concept
Who is allowed to do what?
Roles, rights per role, the connection to user management, and the path for administrator access.
Data model with migration history
What does the data look like, and how did it get that way?
Schema with the meaning of each field, and every change as a traceable, repeatable migration.
Points of contact
Who do you ask?
Business, technical, and operational responsibility defined as roles, each with a backup.
Recovery plan
How does it come back after a failure?
Recovery sequence, backups, target values for downtime and data loss, and the date of the last test.
Architecture description: decisions, not just boxes
A diagram of components is the easy part. The decisions behind it are worth more: why this database, why the language model runs locally or connects through an interface, why there is a queue. Without reasoning, such decisions in operation either never get questioned or get reversed out of ignorance. A lean format is short decision notes, one per decision, sitting in the repository next to the code.
Operations documentation and the recovery plan: written for the worst moment
Both documents get read when something is wrong, often under time pressure and by someone who rarely touches the application. They should therefore be short, concrete, and written as instructions to act on. For target values, the BSI Standard 200-4 (BSI, 2023) offers two terms: the required recovery time objective (RTO) and the maximum tolerable data loss, the recovery point objective (RPO). A recovery plan with no documented test describes a hope. Only a recovery actually rehearsed shows whether those values are achievable. Module CON.3 in the IT-Grundschutz Compendium (BSI, 2023 edition) explicitly requires such tests.
Data model with migration history: the artefact most often missing from a PoC
In many proofs of concept, the database was changed directly: a column added, a type adjusted, a table created by hand. That works as long as there is exactly one database. Once test and production are separate, nobody can be sure any more which schema applies where. A migration history stores every change as a script in version control, so any state can be reproduced. If the history cannot be reconstructed, a documented starting state as the first migration is a clean way to begin.
Access rights concept and points of contact: responsibility that outlasts a staff change
In a PoC, everyone involved often has full rights, because building goes faster that way. The access rights concept separates roles, sets out who administers the system, and describes how access is revoked when someone leaves. Module ORP.4 in the BSI's IT-Grundschutz Compendium (2023 edition) offers a structure for this. Points of contact are recorded as roles, not as names, so the list still holds after a change of staff.
04
Why is a PoC without these artefacts not a candidate for routine operation?
Without the artefacts, knowledge of the structure, operation, and data sits solely with the people who built the proof of concept. Every incident, every change, and every audit then turns into a question for them. That holds up as long as those people are available, and ends abruptly once they are not.
Code quality changes little about that. Even a cleanly written PoC with no migration history cannot reliably be brought into a second environment, and even an elegant architecture with no recovery plan sits idle after a failure until someone reconstructs how it all fits together. Conversely, a plain PoC with complete artefacts can be a good candidate, because its weaknesses are visible and therefore plannable.
A simple test makes the situation concrete: ask someone who was not involved in building it to set up the application in an empty environment using only the existing documentation. Every question they need to ask marks a missing or incomplete artefact. The same applies to automations and data scripts; From an n8n workflow or Streamlit script to an operable application goes into more detail.
Decision path
Is the proof of concept ready for handover?
Four questions that point to the next sensible step.
All questions and results as a list
- Is the PoC already used by real users in their daily work?
- Yes, continue with: Can an uninvolved person set it up again using the documentation?
- No, Result: Run a pilot first
- Can an uninvolved person set it up again using the documentation?
- Yes, continue with: Has a restore from backup actually been rehearsed?
- No, continue with: Are all schema changes stored as migrations in version control?
- Has a restore from backup actually been rehearsed?
- Yes, Result: Prepare the handover
- No, Result: Rehearse the recovery
- Are all schema changes stored as migrations in version control?
- Yes, Result: Catch up on documentation
- No, Result: Stabilise the data model
- Result: Run a pilot firstWorth discussing: which limited group of users will trial the PoC day to day, and which basic operating rules apply from the first real data record onward. Without usage experience, there is no basis for deciding what should actually be operated.
- Result: Prepare the handoverWorth discussing: who reviews the six artefacts, who takes on operational responsibility, and which open points get recorded as conditions.
- Result: Rehearse the recoveryWorth discussing: which target values for downtime and data loss apply, and who runs the restore through in full at least once. The result belongs in the recovery plan.
- Result: Catch up on documentationWorth discussing: exactly where the uninvolved person got stuck. That is precisely where parts of the architecture description or operations documentation are missing.
- Result: Stabilise the data modelWorth discussing: whether the migration history can be reconstructed, or whether a documented starting state as the first migration is the cleaner path. As long as that stays open, any second environment remains a risk.
05
How do you keep production in mind during the pilot?
Keeping production in mind during the pilot does not mean building the pilot like a production system. It means getting the few decisions right early that are hard to correct later, and deliberately noting every other shortcut taken. That covers credentials, migrations, roles, log contents, and where the data is stored.
| Can be missing in the pilot | Should already be right in the pilot |
|---|---|
| High availability and load balancing | Credentials kept outside the code |
| Automated delivery to multiple environments | Schema changes as migrations |
| Fine-grained role models | Separation between use and administration |
| Sophisticated monitoring | Logs without personal data |
| Complete documentation | A short note for every architecture decision |
Checklist
Pilot self-check: is production already accounted for?
For the team building the pilot. The list stores nothing.
iiterate Technologies GmbH develops AI applications and custom software, from architecture through implementation to operations, and hands them over with source code and documentation. Services gives an overview.
Frequently asked questions
How do a proof of concept, a pilot, and an MVP differ?
A proof of concept checks technical feasibility, often without real users. A pilot trials a solution with a limited group of real users in their daily work. An MVP is the smallest version of a product already meant for productive use. In practice the terms get used loosely, so what matters is which question each phase is meant to answer.
Can a proof of concept move straight into routine operation?
That is possible once the six artefacts exist and hardening is complete. Often, though, the handover review shows that individual parts should be rebuilt, especially the data model and access rights. Whether patching up or rebuilding makes more sense depends on how much of the PoC rests on traceable decisions and how well its data can be migrated.
Who creates the handover artefacts?
In substance, the team that built the proof of concept, since that is where the knowledge sits. They are best read and reviewed by the people taking over operations. That division of labour is the real test: whatever the receiving side understands without needing to ask has genuinely been handed over. Everything else is still knowledge locked inside individual heads.
How detailed does operations documentation need to be for a small application?
Short enough that it actually gets read during an incident, and concrete enough to follow without prior knowledge. For a small internal application, a few pages are often enough: how it starts and stops, where configuration and logs live, what dependencies it has, which failure patterns are known, and what to do about each one.
Does this also apply to AI applications with language models?
Yes, with additions. The architecture description records which model is used, in which version, and whether it runs locally or connects through an external interface. The operations documentation describes how a model switch happens and how a change in answer quality can be noticed. For RAG systems, that includes how the search index gets rebuilt.
Read on
Sources
- 01 Announcing the 2025 DORA Report: State of AI-assisted Software Development Google Cloud, 2025 · cloud.google.com
- 02 BSI-Standard 200-4 Business Continuity Management: Glossar und Abkürzungsverzeichnis Bundesamt für Sicherheit in der Informationstechnik (BSI), 2023 · bsi.bund.de
- 03 IT-Grundschutz-Bausteine (Edition 2023), darunter ORP.4 Identitäts- und Berechtigungsmanagement Bundesamt für Sicherheit in der Informationstechnik (BSI), 2023 · bsi.bund.de
- 04 CON.3 Datensicherungskonzept (Edition 2023) Bundesamt für Sicherheit in der Informationstechnik (BSI), 2023 · bsi.bund.de
Let us talk about your project
Whether it is a prototype, an internal tool or an AI application: describe briefly what you are building or want to take into production.