---
title: "Onboarding mit IT-Betreuungspartner"
description_de: "Übergabe, Inventar und erste 90 Tage — so startet externe IT-Betreuung reibungslos."
description_en: "Handover, inventory, and first 90 days — smooth start with external IT support."
url: /wissen/externe-it-betreuung/ablauf-onboarding
datePublished: 2026-07-07
dateModified: 2026-07-07
author: Tim Friedrich Dekker
primaryQuery: "Wie läuft das Onboarding bei externer IT-Betreuung ab?"
---

# Onboarding mit IT-Betreuungspartner

<AnswerCapsule>
  Gutes Onboarding dokumentiert den IT-Bestand, sichert Zugänge und beseitigt die größten Risiken in den ersten neunzig Tagen — bevor der reguläre [SLA](/wissen/glossar/sla)-Betrieb übernimmt.
</AnswerCapsule>

## Vorbereitung vor Vertragsstart

<AnswerCapsule>
  Domain-Inhaberschaft, Tenant-Admin und Backup-Zugänge müssen geklärt sein, bevor der neue Partner den ersten Handgriff macht.
</AnswerCapsule>

Checkliste: Wer ist Registrar der Domain? Welche Admin-Konten existieren in [Microsoft 365](/wissen/microsoft-365/pillar)? Wo liegen Verträge mit Alt-Anbietern? Gibt es einen [Passwort-Manager](/wissen/glossar/passwort-manager) oder nur Excel?

Beenden Sie Alt-Verträge mit ausreichend Übergabezeit — parallelbetrieb zwei Wochen vermeidet Lücken. Der Ex-Partner soll Tickets und Doku exportieren, nicht Accounts löschen.

Intern benennen Sie einen Owner (GF oder Office), der Erreichbarkeit und Freigaben garantiert. Ohne das verzögert sich jede Phase.

Legen Sie einen Kick-off-Termin mit GF, Owner und Partner fest — Kalendereinladung mit Agenda, nicht nur Mail. Erwartungsmanagement beginnt hier.

Alt-Anbieter schriftlich zur Kooperation auffordern — Fristen setzen, bevor Vertrag endet.

Break-Glass- und Notfallkontakte vor Discovery aktualisieren — nicht erst bei Incident suchen.

## Phase 1: Discovery in Woche eins und zwei

<AnswerCapsule>
  Netzwerk, Cloud, Lizenzen, kritische Prozesse und bekannte Schmerzen werden erfasst — Workshop mit GF und Key Usern, vor Ort oder remote.
</AnswerCapsule>

Der [MSP](/wissen/glossar/msp) zeichnet Server, Switches, WLAN, NAS, M365-Struktur und Drittanbieter-SaaS auf. [Schatten-IT](/wissen/glossar/schatten-it) fliegt auf, wenn Mitarbeitende ehrlich sagen, welche Tools sie nutzen.

Quick Wins werden markiert: fehlende [MFA](/wissen/glossar/mfa), offene RDP, untested [Backup](/wissen/glossar/backup), ehemalige Mitarbeiter noch aktiv. Diese Liste priorisiert Woche drei bis sechs.

Tim Dekker setzt in dieser Phase bewusst auf Transparenz statt Big-Bang-Migration — Stabilität vor neuen Features.

Sammeln Sie vor Discovery alle vorhandenen Verträge: Internet, Telefonie, [M365](/wissen/microsoft-365), [Backup](/wissen/glossar/backup), Firewall — Laufzeiten und Kündigungsfristen vermeiden Doppelbindung.

Key-User pro Abteilung benennen — Discovery wird schneller und vollständiger.

Netzwerk-Skizze auch grob wertvoll — IP-Ranges, WLAN-Namen, NAS-Pfad.

## Phase 2: Stabilisieren in Woche drei bis sechs

<AnswerCapsule>
  [Backups](/wissen/glossar/backup) werden getestet, Patches eingespielt, Admin-Konten bereinigt, Monitoring aktiviert — der Betrieb soll vor Optimierung sicher laufen.
</AnswerCapsule>

Restore-Test mindestens einer kritischen Datenquelle — mit Protokoll. Ohne Test ist [RPO](/wissen/glossar/rpo) eine Schätzung.

Ticket-Kanal und Erreichbarkeit werden an alle Mitarbeitenden kommuniziert: Portal-Link, Telefon, was ist Notfall. [First-Level-Support](/wissen/glossar/first-level-support)-Regeln schriftlich.

[Dokumentation](/wissen/it-betrieb/it-dokumentation) startet im Wiki: Netzplan, Lizenzmatrix, Kontaktliste, Notfallkette. Nicht perfekt, aber auffindbar.

Fotografieren oder dokumentieren Sie Serverraum und Verteiler — auch wenn der Partner remote arbeitet, braucht er Orientierung für Vor-Ort-Einsätze.

Patch-Fenster mit GF abstimmen — Freitag 18 Uhr ist nicht für jedes KMU ideal.

Monitoring-Alerts testen — falscher Alarm ist besser als keiner.

## Phase 3: Optimieren in Monat zwei und drei

<AnswerCapsule>
  Security-Baseline, Geräte-Richtlinien, [Onboarding-IT](/wissen/glossar/onboarding-it)- und [Offboarding](/wissen/glossar/offboarding)-Checklisten, Review mit Geschäftsführung.
</AnswerCapsule>

[Conditional Access](/wissen/glossar/conditional-access), Geräte-Compliance, [Patch-Management](/wissen/glossar/patch-management)-Fenster — abgestimmt auf Ihre Risikotoleranz, nicht auf Enterprise-Maximum.

Review-Meeting: Budget-Verbrauch, offene Projekte, Roadmap nächstes Quartal. GF bestätigt Prioritäten — der Partner setzt um.

Danach regulärer Betrieb laut [Betreuungsvertrag](/wissen/externe-it-betreuung/betreuungsvertrag): monatliche Reports, quartalsweise Sicherheits-Check optional.

Erstellen Sie eine Liste ehemaliger Mitarbeitender mit noch aktiven Konten — Quick Win mit hohem Security-Impact in Woche eins.

Security-Baseline schrittweise — Big-Bang-MFA am Freitag erzeugt Montags-Stau.

Roadmap-Backlog priorisieren — nicht alles in Monat zwei erledigen wollen.

## Rollen während des Onboardings

<AnswerCapsule>
  Partner liefert Technik und Protokolle; interner Owner liefert Zugang, Entscheidungen und Mitarbeiter-Kommunikation.
</AnswerCapsule>

RACI vermeidet Reibung: Wer genehmigt Änderungen am Wochenende? Wer spricht mit dem Alt-Anbieter? Wer informiert das Team über neue Passwort-Regeln?

Bei Kanzleien: Partner-Tickets dürfen keine Mandantennamen enthalten, wenn nicht nötig — vorab vereinbaren.

[IT Security Expert](/externe-it-betreuung) bindet Onboarding an feste Meilensteine mit Abnahme durch den Owner — kein endloses „wir schauen noch“.

Definieren Sie Wartungsfenster mit dem Team — niemand will Überraschungs-Neustarts am Monatsende. Kommunikation verhindert „IT hat wieder was kaputt gemacht“-Narrative.

RACI schriftlich an alle — intern und beim Partner.

Kanzlei: Ticket-Richtlinie ohne Mandantennamen im Betreff.

## Typische Stolpersteine vermeiden

<AnswerCapsule>
  Fehlende Admin-Rechte, blockierender Ex-Partner und unentdeckte Insellösungen verzögern jedes Onboarding um Wochen.
</AnswerCapsule>

Häufigster Fehler: Neuer Vertrag unterschrieben, aber Domain liegt beim Webdesigner von 2015. Klären Sie Eigentum vor Kick-off.

Zweiter Fehler: Kein Zeitfenster für Mitarbeiter-Fragen — dann umgeht das Team den neuen Kanal und ruft weiter den Freelancer an.

Dritter Fehler: Migration und Onboarding parallel. Erst stabil, dann umziehen — sonst wissen Sie bei Incidents nicht, welche Umgebung gilt.

Halten Sie wöchentliche 15-Minuten-Status-Calls in den ersten sechs Wochen — kurz, strukturiert, mit Protokoll. Danach reicht monatlich.

Domain-Ownership vor Kick-off prüfen — häufigster Showstopper.

Keine parallele Migration während Stabilisierung — eine Wahrheit pro System.

## Kommunikation an das Team

<AnswerCapsule>
  Mitarbeitende brauchen eine kurze Anleitung: wie Ticket erstellen, was ist Notfall, wer interner Ansprechpartner — am besten am Kick-off-Tag.
</AnswerCapsule>

Willkommens-Mail mit Screenshots, nicht mit zwanzig Seiten PDF. Link zum Portal, Telefonnummer, Erwartung an Antwortzeiten.

GF signalisiert Unterstützung: neue Regeln ([MFA](/wissen/glossar/mfa), [Passwort-Manager](/wissen/glossar/passwort-manager)) gelten für alle inklusive Chefs — Vorbildwirkung.

Nach zwei Wochen kurze Umfrage: drei Fragen zur Erreichbarkeit. Früh korrigieren spart Monate Frust.

Messgrößen festlegen: MFA-Quote, Backup-Test bestanden ja/nein, Anzahl offener Admin-Konten — objektive Abnahme statt Bauchgefühl.

Kick-off-Mail am Tag eins — Link, Telefon, Erwartungen.

GF nutzt gleiche Regeln — Vorbild für [MFA](/wissen/glossar/mfa) und [Passwort-Manager](/wissen/glossar/passwort-manager).

## Abnahme und Übergang in den Regelbetrieb

<AnswerCapsule>
  Nach neunzig Tagen sollten Inventar, Backup-Test, MFA-Quote und Ticket-Prozess dokumentiert abgenommen sein.
</AnswerCapsule>

Abnahmeprotokoll mit GF: Was ist erledigt, was ist Backlog, was ist Projekt? Backlog darf existieren — muss nur priorisiert sein.

Regelbetrieb heißt: keine Sonderbehandlung ohne Ticket, aber weiterhin feste Review-Termine. Onboarding endet, Beziehung bleibt.

Vertiefung: [Anbieter auswählen](/wissen/externe-it-betreuung/anbieter-auswahl), [IT ohne Abteilung](/wissen/externe-it-betreuung/ohne-it-abteilung), Glossar [Onboarding IT](/wissen/glossar/onboarding-it).

Planen Sie Schulungs-Slots für [MFA](/wissen/glossar/mfa) und [Passwort-Manager](/wissen/glossar/passwort-manager) ein — technische Fixes scheitern ohne fünf Minuten Erklärung für Nutzer.

Archivieren Sie Onboarding-Dokumentation revisionssicher — bei Prüfung oder Wechsel sparen Sie Wochen Rekonstruktion.

Abnahme mit GF unterschreiben — Backlog mit Priorität und Datum.

Regelbetrieb heißt: Tickets auch für kleine Wünsche — Gewohnheit formen.

## Zeitplan und Meilensteine für die ersten 90 Tage

<AnswerCapsule>
  Ohne Kalendertermine verzögert sich Onboarding — feste Meilensteine mit GF-Abnahme halten alle Seiten accountable.
</AnswerCapsule>

Woche 1–2: Discovery abgeschlossen, Inventar liegt vor, Quick-Win-Liste priorisiert. Woche 3–6: Backup-Test bestanden, MFA-Rollout gestartet, Monitoring aktiv. Monat 2–3: Security-Baseline, Offboarding-Checkliste, Review mit GF.

Jeder Meilenstein bekommt einen Owner und ein Datum — nicht „irgendwann im ersten Quartal“. Verspätung früh kommunizieren, Scope anpassen statt still verzögern.

[IT Security Expert](/externe-it-betreuung) strukturiert Onboarding mit schriftlicher Meilenstein-Liste — Sie sehen Fortschritt, nicht nur Aktivität.

Nach Tag 90: Übergang in [SLA](/wissen/glossar/sla)-Betrieb nur mit unterschriebenem Abnahmeprotokoll — sonst bleibt Onboarding ewig offen.

## Onboarding beim Anbieterwechsel

<AnswerCapsule>
  Wechsel ist kein Neustart von null — aber fast so aufwendig wie Erstbeauftragung, wenn die Übergabe schlecht läuft.
</AnswerCapsule>

Fordern Sie vom Alt-Anbieter: Admin-Liste, Netzplan, Backup-Konfiguration, Ticket-Export — schriftlich mit Frist. Ohne das startet der Neue blind.

Parallelbetrieb maximal zwei Wochen — danach eine Wahrheit für Support und Monitoring. Doppelstrukturen verwirren Mitarbeitende und Techniker.

Kommunizieren Sie intern: neuer Kanal, neuer Ansprechpartner, alte Nummer ab wann tot. Verhindert, dass niemand mehr weiß, wen man anruft.

Details zur Anbieterwahl: [Anbieter auswählen](/wissen/externe-it-betreuung/anbieter-auswahl), Exit im [Betreuungsvertrag](/wissen/externe-it-betreuung/betreuungsvertrag).

## Dokumentation und Wissensübergabe

<AnswerCapsule>
  Onboarding scheitert oft nicht an Technik, sondern daran, dass Wissen im Kopf des Technikers bleibt — Wiki und Tresor sind Pflicht.
</AnswerCapsule>

Mindestinhalt nach 90 Tagen: Netzplan, Geräteliste, Lizenzmatrix, Backup-Jobs mit Restore-Protokoll, Admin-Liste, Notfallkette, Partner-Kontakte.

Passwörter und Secrets nur im [Passwort-Manager](/wissen/glossar/passwort-manager) — nicht im Wiki. Verlinkung reicht.

Partner liefert monatlich Status zu Dokumentationslücken — nicht als Vorwurf, sondern als Backlog mit Priorität.

Vertiefung: [IT-Dokumentation](/wissen/it-betrieb/it-dokumentation) im Betrieb-Cluster.

## Sonderfälle: Kanzlei, Makler, [Personaldienstleister](/wissen/branchen/personaldienstleister)

<AnswerCapsule>
  Regulierte oder wechselintensive Branchen brauchen angepasste Onboarding-Schwerpunkte — nicht das Generic-SMB-Script.
</AnswerCapsule>

Kanzlei: Mandantenvertraulichkeit in Tickets, Admin-Trennung, Abstimmung mit Steuerberater-Workflows. Makler: E-Mail-Schutz und Phishing-Prozess früh. [Personaldienstleister](/wissen/branchen/personaldienstleister): [Onboarding-IT](/wissen/glossar/onboarding-it) und [Offboarding](/wissen/glossar/offboarding) automatisieren vor Fancy-Tools.

[IT Security Expert](/externe-it-betreuung) kennt diese Profile — Onboarding-Checklisten sind darauf ausgerichtet.

Key-User pro Fachbereich einbinden — Discovery wird vollständiger und Akzeptanz steigt.

Nach 90 Tagen: branchenspezifische Risiko-Review — nicht nur technisches All-Clear.

## Onboarding-Checkliste zum Abhaken

<AnswerCapsule>
  Diese Punkte sollten nach 90 Tagen grün sein — sonst ist Onboarding nicht fertig, nur pausiert.
</AnswerCapsule>

Inventar vollständig und abgenommen. Backup-Restore protokolliert. [MFA](/wissen/glossar/mfa) für alle produktiven Nutzer. Keine ehemaligen Mitarbeiter aktiv. Admin-Konten bereinigt. Ticket-Kanal von Team genutzt. Notfallkette dokumentiert. Partner-[SLA](/wissen/glossar/sla) kommuniziert.

Backlog mit Priorität und Datum beim GF — offen ist ok, unpriorisiert nicht.

Schulung [MFA](/wissen/glossar/mfa)/[Passwort-Manager](/wissen/glossar/passwort-manager) durchgeführt — nicht nur technisch erzwungen.

Abnahmeprotokoll unterschrieben — Übergang in Regelbetrieb offiziell.

## Remote-Onboarding und Vor-Ort-Mix

<AnswerCapsule>
  Viele [MSP](/wissen/glossar/msp)s arbeiten remote-first — das funktioniert, wenn Vor-Ort klar vereinbart ist.
</AnswerCapsule>

Discovery remote per Video und Screen-Share spart Reisekosten — Serverraum-Fotos und Fotos von Patchpanels vom Team anfordern. Vor-Ort sinnvoll bei Netzwerk-Totalausfall, Rack-Umordnung oder Erstbesuch Vertrauen.

Kick-off vor Ort plus laufender Betrieb remote ist gängig — Reiseklausel im [Betreuungsvertrag](/wissen/externe-it-betreuung/betreuungsvertrag).

Zweitstandorte und [Homeoffice](/wissen/glossar/remote-arbeit): gleiche Checklisten wie Hauptstandort — sonst entsteht Insellogik.

Tim Dekker: Remote spart Zeit, ersetzt aber nicht dokumentierte Übergabe vom Alt-Anbieter.

## Erfolgsmessung nach Onboarding

<AnswerCapsule>
  Zahlen schlagen Gefühl — vier KPIs für die GF nach 90 Tagen.
</AnswerCapsule>

MFA-Quote der produktiven Nutzer. Backup-Restore erfolgreich ja/nein mit Datum. Durchschnittliche Ticket-Reaktionszeit im ersten Monat. Anzahl offener kritischer Risiken aus Discovery — mit Priorität.

Trend wichtiger als absoluter Wert — Verbesserung gegenüber Vor-Partner oder Vor-Onboarding.

Misslingt ein KPI: Ursache klären (Prozess, Partner, intern) — nicht pauschal kündigen.

Regelbetrieb startet erst nach dokumentierter Abnahme — nicht nach Bauchgefühl.

Onboarding ist investierte Zeit — sie zahlt sich in jedem späteren Incident aus, wenn der Partner Ihre Umgebung bereits kennt.

Planen Sie intern genug Zeit für Freigaben in den ersten Wochen — der schnellste technische Partner scheitert an wartenden Entscheidungen.

Discovery-Workshop: Key-User aus jeder Abteilung einladen — in zehn Minuten pro Person fallen [Schatten-IT](/wissen/glossar/schatten-it) und Schmerzpunkte auf, die Monate allein im Serverraum verborgen bleiben.

90-Tage-Plan in Kurzform: Tage 1–14 Discovery und Quick-Win-Liste; Tage 15–45 Backup-Test, MFA-Rollout, Monitoring; Tage 46–90 Security-Baseline, Offboarding-Prozess, GF-Review. Jede Phase endet mit schriftlicher Abnahme durch den Owner — nicht mit „passt schon“.

Beim Anbieterwechsel: Alt-Anbieter schriftlich auffordern, Admin-Export und Ticket-Historie innerhalb von zehn Werktagen zu liefern; Parallelbetrieb maximal zwei Wochen. Kick-off-Mail am Tag eins mit neuem Kanal — alte Freelancer-Nummern sonst weiter genutzt.

Dokumentieren Sie nach Woche sechs eine Kurz-Zusammenfassung für die GF: größte Risiken behoben, größte Risiken offen, nächste drei Maßnahmen mit Datum. Diese Seite reicht als Abnahme-Grundlage, bevor der Regelbetrieb startet.

Halten Sie während Onboarding wöchentlich fünf Minuten Status — nur drei Bulletpoints: erledigt, blockiert, nächster Schritt. So erkennen Sie Verzögerungen früh, ohne stundenlange Projektmeetings.

<ServiceCta />
