Pascal Danovski
Principal IT ConsultantMicrosoft Infrastructure & Collaboration
Technische Tiefe ist für mich kein Gegenstück zu klarer Kommunikation.
Ich begleite komplexe Microsoft-Infrastruktur- und Migrationsprojekte dort, wo Architekturentscheidungen bis in die tatsächliche Umsetzung tragen müssen. Mein Schwerpunkt liegt auf den Abhängigkeiten, die ein Projekt erst dann sichtbar macht, wenn man nicht nur auf das Diagramm schaut.
Wie ich arbeite
Architektur ist erst dann gut, wenn sie durch die Umsetzung trägt.
In Projekten geht es selten nur um die richtige Zielarchitektur. Entscheidend wird, ob Migrationsreihenfolge, Identitäten, Mailflow, Berechtigungen und Verantwortlichkeiten auch unter Zeitdruck zusammenpassen.
Komplexe Migrationen scheitern selten am Verschieben von Daten. Kritisch werden Identity, Domains, Koexistenz, Reihenfolge und der Zustand am ersten Tag danach.
Ich arbeite deshalb bewusst nah an der Umsetzung: technische Abhängigkeiten früh einordnen, Entscheidungen begründen und die kritischen Phasen bis Cutover und Übergabe fachlich begleiten.
Arbeitsprinzipien
Vier Dinge, auf die ich in komplexen Projekten achte.
Keine Leitbildsätze. Diese Punkte entstehen aus den Phasen, in denen ein Projekt technisch oder organisatorisch besonders leicht an Klarheit verliert.
Architektur und Umsetzung zusammen denken.
Ein Zielbild muss zur realen Reihenfolge von Workloads, Identitäten, Migrationsschritten und Betriebsübergaben passen.
Risiken und Abhängigkeiten früh sichtbar machen.
Ich strukturiere nicht nur technische Aufgaben, sondern auch die Punkte, an denen sie sich gegenseitig beeinflussen.
Entscheidungen technisch begründen.
IT-Leitung und Projektteam brauchen nachvollziehbare Optionen, Konsequenzen und eine tragfähige Empfehlung statt abstrakter Technologiebegriffe.
Verantwortung auch in Übergabephasen übernehmen.
Cutover und Stabilisierung sind kein Anhang zum Konzept. Sie bestimmen, ob ein Projekt sauber in den Betrieb übergeht.
Fachlicher Schwerpunkt
Komplexität dort führen, wo mehrere Microsoft-Welten zusammenkommen.
Mein Kern liegt bei Exchange und Exchange Online mit Hybrid-Abhängigkeiten, Microsoft-365-Tenant-to-Tenant-Migrationen sowie Identity-, Entra-ID- und Active-Directory-Kontexten in Carve-In- und Carve-Out-Projekten.
Intune, Purview, PowerShell, Graph, Teams und SharePoint gehören für mich in den richtigen Projektkontext: als unterstützende Tiefe, wenn sie für Endpoints, Daten, Automatisierung oder Collaboration tatsächlich relevant sind. Sie sind kein zweiter Leistungskatalog.
Zusammenarbeit
Zwei Perspektiven, eine technische Verantwortung.
Die Zusammenarbeit unterscheidet sich je nach Projektrolle, nicht im Anspruch an technische Tiefe und klare Kommunikation.
Mit IT-Leitungen
Ich mache technische Komplexität entscheidbar: Risiken einordnen, Zielbilder mit dem Projektverlauf verbinden und belastbare Empfehlungen für kritische Übergänge aussprechen.
Mit Systemhäusern
Ich ergänze Co-Delivery als technischer Fachlead in Migrations-, Integrations- oder Eskalationsphasen. Dabei bleibe ich bewusst Ergänzung zum bestehenden Kundenverhältnis, nicht dessen Ersatz.
Ausgewählte Entwicklung
Meine heutige Rolle verbindet technische Basis, Architektur, Migration und fachliche Führung.
Technische Basis, Infrastrukturverantwortung, Microsoft Consulting, Enterprise-Migrationen und fachliche Führung prägen die Arbeitsweise, die ich heute als Principal IT Consultant in Projekte einbringe.
Historische Rollen wie Senior Consultant, Product Owner, Fachlead Messaging & Collaboration und Solutions Architect gehören zu diesem Weg. Die vollständigen Stationen bleiben bewusst im beruflichen Werdegang und werden hier nicht zu einer zweiten CV-Timeline verdichtet.
Nächster Schritt
Projekt kurz besprechen.
Ein erstes Gespräch klärt meist schnell, welche technische Ausgangslage, Projektphase und Rolle für den Einstieg relevant sind.