NVivo 15 Windows-Mac-Zusammenarbeit: Projektabgabe 2026

Auf beiden Geräten lässt sich das NVivo-Projekt öffnen, doch bei der Zusammenführung fehlen plötzlich Analysefunktionen oder Medienverknüpfungen.

Schnellste Lösung: Legen Sie eine führende Plattform und eine einheitliche Hauptversion fest, testen Sie vor der Codierung eine vollständige Übergabe und verwenden Sie manuelle Konvertierungen nicht als laufende Synchronisation.

Diese Anleitung richtet sich an Mitglieder hochschulübergreifender Forschungsgruppen, die NVivo-Projekte zwischen Windows und Mac austauschen. Sie ist ebenso für Studierende geeignet, die auf dem Mac codieren, während Betreuung oder Datenverwaltung das Projekt unter Windows auswertet, sowie für Hochschulmitarbeitende, die Softwarebereitstellung, Archivierung und Datenschutz prüfen.

Hinweis: Die Aussagen zu Formatunterschieden, Konvertierung und Plattformgrenzen beziehen sich auf den bis zum 29.08.2026 geprüften Informationsstand. Maßgeblich sind die offiziellen NVivo-Dokumente; bei einem neuen Hauptrelease oder geänderten Versionshinweisen müssen Sie die Abnahme erneut durchführen.

SECTION 01Warum ein geöffnetes Projekt noch keine erfolgreiche Übergabe beweist

Eine Datei, die sich auf beiden Betriebssystemen öffnen lässt, ist noch kein Nachweis dafür, dass Ihr Forschungsprojekt vollständig übernommen wurde. Bei NVivo 15 verwenden die Windows- und die Mac-Anwendung unterschiedliche Projektformate. Die offizielle Dokumentation beschreibt deshalb eine Konvertierung zwischen den Formaten, nicht automatisch einen dauerhaft geeigneten bidirektionalen Arbeitsablauf. Die dokumentierten Dateitypen und Projektdateien sollten Sie vor dem Austausch anhand der offiziellen Übersicht zu NVivo-Dateitypen abgleichen.

Für die qualitative Forschung entstehen dabei mehrere konkrete Risiken:

• Funktionale Unterschiede: Abfragen, Berichte, Beziehungen oder Analyseansichten können auf der Zielplattform anders verfügbar sein, verborgen erscheinen oder dort nicht bearbeitbar sein. „Nicht sichtbar“ bedeutet nicht ohne Prüfung „gelöscht“.
• Externe Dateien: Audio, Video, Bilder und verknüpfte Dokumente können außerhalb des Projektcontainers liegen. Nach einer Konvertierung kann der Pfad nicht mehr stimmen, obwohl Codes und Memos weiterhin vorhanden sind.
• Versionsdrift: Wenn ein Teammitglied eine andere Hauptversion verwendet, lässt sich ein scheinbar erfolgreich konvertiertes Projekt nicht zuverlässig als gemeinsame Arbeitsgrundlage bewerten.
• Parallele Kopien: Mehrere Mitglieder können aus derselben Ausgangsdatei eigene Stände erzeugen. Spätere manuelle Zusammenführung ist dann keine neutrale Synchronisation; Änderungen, Codierbereiche und Kommentare müssen einzeln kontrolliert werden.
• Berechtigungen und Datenschutz: Ein Projekt mit Interviewdaten, Einwilligungen oder personenbezogenen Transkripten darf nicht einfach auf private Geräte oder unkontrollierte Synchronisationsordner kopiert werden. Zugriffsrechte, Aufbewahrung und Löschung müssen zur Vorgabe Ihrer Hochschule und zur DSGVO passen.
• Abhängigkeit von Einzelgeräten: Wenn nur eine Person die führende Datei oder die benötigten Abfragen ausführen kann, wird die Abgabe bei Urlaub, Geräteausfall oder Lizenzproblemen unnötig fragil.

Die offizielle Anleitung zur plattformübergreifenden Projektkonvertierung ist daher der Ausgangspunkt für die technische Prüfung. Sie ersetzt aber nicht den Nachweis, dass Ihr konkretes Projekt mit seinen Anhängen, Abfragen und Exporten tatsächlich verwendbar bleibt: NVivo-Anleitung zur Konvertierung zwischen Plattformen.

SECTION 02Erste Entscheidung: Wo liegt das Hauptprojekt?

Bestimmen Sie diese Frage bei der Projektgründung, nicht erst in der Woche vor der Dissertationseinreichung. In den meisten gemischten Teams ist Windows die sinnvollere führende Plattform, wenn dort die für Ihr Vorhaben benötigten Abfragen, Berichte, Beziehungsanalysen oder Kollaborationsschritte vollständig verfügbar sind. Der Mac kann dann für klar abgegrenzte und getestete Codieraufgaben eingesetzt werden.

Das ist keine allgemeine Aussage, dass Windows für jedes Forschungsvorhaben besser wäre. Entscheidend ist die konkrete Aufgabenverteilung:

• Windows als Hauptplattform, wenn Betreuung, Datenmanagement oder die zentrale Auswertung dort erfolgt und Ihre geplanten Funktionen auf Windows validiert wurden.
• Mac als Hauptplattform, wenn das gesamte Team dieselbe Mac-Version nutzt, die benötigten Arbeitsschritte dort nachweislich verfügbar sind und keine regelmäßige Rückkonvertierung notwendig ist.
• Mac als geprüfte Nebenplattform, wenn einzelne Mitglieder macOS benötigen, aber die Masterdatei und die finale Auswertung auf Windows bleiben.
• Keine laufende Mischbearbeitung, wenn die Abnahme zeigt, dass externe Medien, komplexe Dokumente oder zentrale Abfragen auf der Zielplattform nicht zuverlässig funktionieren.

Legen Sie außerdem eine verantwortliche Person für den Masterstand fest. Diese Person entscheidet, wann eine Kopie ausgegeben wird, welche Änderungen angenommen werden und wo die geprüfte Version abgelegt wird. Jede Konvertierung erfolgt ausschließlich aus einer Kopie; das unveränderte Original bleibt schreibgeschützt.

Für die Projektakte genügt eine kurze Umgebungstabelle:

Die Dateiendungen .nvp und .nvpx dürfen dabei nicht als bloße Umbenennung behandelt werden. Eine andere Endung macht aus einem Windows-Projekt keine Mac-Datei. Für Export- und Austauschentscheidungen sollten Sie zusätzlich die offiziellen NVivo-Hinweise zum Export von Dateien heranziehen.

SECTION 03Erste Phase: Baseline vor dem Import herstellen

Bevor Sie ein Projekt auf die zweite Plattform übertragen, erstellen Sie eine belastbare Ausgangslage. Dazu gehört nicht nur die Projektdatei, sondern auch das Umfeld, auf das sie verweist.

Gehen Sie in dieser Reihenfolge vor:

1. Versionsliste erfassen: Fordern Sie von jedem Mitglied Betriebssystem, NVivo-Hauptversion und verwendete Zusatzkomponenten an. Gleichen Sie die Hauptversion ab, bevor jemand codiert.
2. Schreibgeschützte Sicherung erzeugen: Kopieren Sie die ursprüngliche Projektdatei in einen nur lesbaren Archivbereich. Arbeiten Sie für jede Konvertierung mit einer eindeutig benannten Arbeitskopie.
3. Dateiinventar erstellen: Listen Sie Transkripte, Audio- und Videodateien, Bilder, Tabellen, eingebettete Objekte, Hyperlinks und sonstige externe Ressourcen auf.
4. Pfade dokumentieren: Notieren Sie, ob eine Ressource eingebettet oder nur verknüpft ist, und welcher Pfad auf der Zielplattform erwartet wird.
5. Prüfsumme und Übergabeprotokoll speichern: Halten Sie Dateiname, Erstellungszeitpunkt, verantwortliche Person und Prüfsumme nach dem in Ihrer Hochschule freigegebenen Verfahren fest.
6. Datenschutzstatus markieren: Verwenden Sie für den Test möglichst ein anonymisiertes oder synthetisches Sample. Wenn echte Forschungsdaten notwendig sind, prüfen Sie Speicherort und Zugriff vor dem Upload.

Bei der Bestandsaufnahme sollten Sie besonders auf lange oder lokale Pfade, Netzlaufwerke und Wechseldatenträger achten. Eine Datei kann auf dem Rechner der betreuenden Person funktionieren, weil dort ein bestimmtes Laufwerk eingebunden ist, während sie auf dem Mac ohne diese Umgebung nicht gefunden wird. Auch Hyperlinks zu internen Hochschulressourcen sind nach dem Gerätewechsel nicht automatisch erreichbar.

Die Versionsprüfung ist keine Formalität. NVivo 15.3 wird in den offiziellen Versionshinweisen des Herstellers mit den dort ausdrücklich genannten Änderungen beschrieben. Funktionen oder eine stärkere Plattformangleichung, die nicht in offiziellen Veröffentlichungen bestätigt sind, dürfen Sie nicht als gegeben einplanen.

SECTION 04Zweite Phase: Kontrollierte NVivo-Projektkonvertierung

Für eine erste NVivo-Projektkonvertierung wählen Sie kein unvollständiges Demo-Projekt, sondern eine anonymisierte Kopie, die die kritischen Elemente Ihres echten Vorhabens abbildet. Sie sollte mindestens einige Codes, Memos, eine Abfrage, ein Medium, ein Dokument mit anspruchsvoller Formatierung und einen externen Link enthalten. So testen Sie nicht nur, ob die Datei startet, sondern ob die spätere Arbeit möglich bleibt.

Führen Sie die Übergabe wie einen kontrollierten Change durch:

1. Benennen Sie die Baseline eindeutig, etwa nach Projekt, Plattform und Teststand.
2. Öffnen Sie die Kopie auf der Ausgangsplattform und speichern Sie den sichtbaren Projektstatus.
3. Exportieren oder dokumentieren Sie die erwarteten Ergebnisse der ausgewählten Abfragen.
4. Konvertieren Sie ausschließlich die Kopie nach der offiziellen Vorgehensweise.
5. Öffnen Sie die konvertierte Datei auf der Zielplattform und protokollieren Sie sichtbare, eingeschränkte und fehlende Elemente.
6. Prüfen Sie die Medien nicht nur durch das Vorhandensein des Eintrags, sondern durch das Öffnen und die Navigation zur relevanten Stelle.
7. Vergleichen Sie Codes, Codierbereiche, Memos, Abfrageergebnisse und Exportdateien mit der Baseline.

Wenn eine Funktion in der Mac-Oberfläche fehlt, halten Sie drei Zustände auseinander: Sie kann nur anders angeordnet sein, auf der Plattform nicht verfügbar sein oder durch einen tatsächlichen Konvertierungsfehler beeinträchtigt sein. Erst die Gegenprüfung mit dem offiziellen Funktionsumfang und Ihrem Testprotokoll erlaubt eine belastbare Einstufung.

Woran erkennen Sie, dass Windows und Mac nicht für den täglichen Wechsel geeignet sind?

Die Warnsignale sind nicht nur Fehlermeldungen. Stoppen Sie die Freigabe für die formale Codierung, wenn eines dieser Ergebnisse eintritt:

• ein für die Forschungsfrage notwendiger Abfragetyp lässt sich nicht ausführen;
• ein externes Audio- oder Videomedium öffnet sich nicht oder springt nicht zur dokumentierten Position;
• ein Dokument mit Tabellen oder Bildern wird sichtbar verändert;
• ein Codierbereich stimmt nicht mit der Baseline überein;
• die Zielplattform kann den geplanten Export nicht reproduzieren;
• niemand kann eindeutig feststellen, welche Datei der gültige Masterstand ist.

In diesem Fall begrenzen Sie die Rolle der zweiten Plattform. Lassen Sie dort nur Aufgaben zu, die ausdrücklich geprüft wurden, beispielsweise das Codieren definierter Dokumente. Die zentrale Analyse und der finale Export bleiben auf der Hauptplattform. Ein kleinerer, kontrollierbarer Arbeitsumfang ist sicherer als die Annahme, jede sichtbare Funktion sei gleichwertig.

SECTION 05Dritte Phase: Testcodierung mit Belegen statt Vertrauen

Nach der technischen Öffnung folgt die fachliche Prüfung. Bitten Sie ein Mitglied auf Windows und ein Mitglied auf Mac, denselben kleinen, anonymisierten Dokumentensatz nach derselben Codieranweisung zu bearbeiten. Sie vergleichen anschließend nicht nur die Anzahl der Codes, sondern die fachlich relevanten Details:

• Sind dieselben Codes und Hierarchien vorhanden?
• Decken die Codierbereiche dieselben Textstellen oder Mediensegmente ab?
• Bleiben Kommentare und Memos nachvollziehbar?
• Liefert die ausgewählte Abfrage dieselbe interpretierbare Struktur?
• Sind Audio, Video, Tabellen und Bilder tatsächlich nutzbar?
• Lassen sich die Ergebnisse in dem für die Dissertation benötigten Format exportieren?

Definieren Sie vorab ein Bestehensmaß. Ein Test ist nicht bestanden, wenn die Datei lediglich geöffnet wird. Er ist bestanden, wenn die vereinbarten Aufgaben durchgeführt, die kritischen Ressourcen erreicht und die Ergebnisse gegen die Baseline geprüft wurden.

Für den späteren Austausch gilt: Eine manuelle Konvertierung ist eine kontrollierte Übergabe, kein Versionskontrollsystem. Sie sollten daher nicht gleichzeitig aus mehreren konvertierten Kopien weiterarbeiten. Jede Rückgabe muss eine Versionsnummer, eine kurze Änderungsliste, die verantwortliche Person und den Zielstand enthalten.

SECTION 06Wie lassen sich Konvertierung, Anhänge und Phasenübergaben kontrollieren?

Erstellen Sie für jede Übergabe ein kurzes Protokoll mit vier Feldern:

1. Eingang: Welche Datei, welche Plattform, welche NVivo-Version und welcher Sicherungsstand wurden angenommen?
2. Prüfung: Welche Codes, Memos, Abfragen, Medien, Links und Exporte wurden kontrolliert?
3. Entscheidung: Was ist bestanden, eingeschränkt oder nicht freigegeben?
4. Ausgang: Welche Datei wird weitergegeben, wer darf sie öffnen und welcher nächste Arbeitsschritt ist erlaubt?

Wenn Anhänge nach der NVivo-Projektkonvertierung nicht erreichbar sind, stellen Sie nicht einfach die Pfade manuell auf mehreren Geräten um. Vergleichen Sie zunächst Inventar, Speicherort und Verknüpfungstyp mit der Baseline. Danach stellen Sie die Ressourcen nach einer von der Hochschule freigegebenen Ablagestruktur neu bereit, führen die Medienprüfung erneut durch und dokumentieren, welche Elemente repariert wurden.

Für eine laufende Zusammenarbeit sollten Sie außerdem die offiziellen Möglichkeiten der Projektzusammenarbeit und die Anforderungen an Konten, Server und Berechtigungen prüfen. Die offizielle Dokumentation zur Projekterstellung und Zusammenarbeit ist dafür relevanter als Erfahrungsberichte aus Foren. Ob ein Dienst zu den Vorgaben Ihrer Hochschule passt, müssen Sie separat mit Datenschutzbeauftragten und Lizenzverwaltung klären.

SECTION 07Vierte Phase: Freigabe vor Dissertation und Archivierung

Vor der eigentlichen Abgabe wechseln Sie nicht mehr spontan die Plattform. Die verantwortliche Person führt auf dem Hauptsystem eine Endabnahme durch:

• Die im Text der Arbeit zitierten Abfragen werden erneut ausgeführt.
• Tabellen, Diagramme und Berichte werden aus dem freigegebenen Masterstand erzeugt.
• Codes, Memos, Originalmaterialien und Anhänge werden gegen das Inventar geprüft.
• Die Exportdateien werden geöffnet und mit der Dokumentation verknüpft.
• Eine zweite berechtigte Person kontrolliert, ob die Wiederherstellung ohne das persönliche Gerät des Projektleiters möglich ist.
• Die finale Projektdatei, die geprüfte Austauschkopie, Exporte, Versionsnotiz und Wiederherstellungsschritte werden getrennt, aber nachvollziehbar gespeichert.

Wenn Ihre Gruppe Collaboration-Funktionen oder einen Server verwenden möchte, prüfen Sie vor der Freigabe zusätzlich Lizenzmodell, Benutzerkonten, Speicherregion, Rollen und Löschprozesse. Eine technisch funktionierende Zusammenarbeit kann organisatorisch trotzdem unzulässig sein, wenn die Hochschule keine Freigabe für personenbezogene Forschungsdaten auf diesem Speicherweg erteilt hat.

SECTION 08Die Übergabe-Checkliste für Ihren Projektzeitplan

Diese Liste können Sie direkt in das Protokoll der Arbeitsgruppe übernehmen:

• [ ] Führende Plattform und verantwortliche Person sind schriftlich festgelegt.
• [ ] Alle Mitglieder haben ihre NVivo-Hauptversion und ihr Betriebssystem dokumentiert.
• [ ] .nvp- und .nvpx-Dateien sind unterschieden und nicht nur umbenannt worden.
• [ ] Ein schreibgeschütztes Original liegt außerhalb des Konvertierungsarbeitsbereichs.
• [ ] Externe Medien, Bilder, Tabellen, Hyperlinks und Pfade sind inventarisiert.
• [ ] Der Test verwendet eine anonymisierte Kopie mit repräsentativen Projektbestandteilen.
• [ ] Eine Konvertierung von Windows zu Mac oder von Mac zu Windows wurde kontrolliert durchgeführt.
• [ ] Codes, Codierbereiche, Memos und Abfrageergebnisse wurden gegen die Baseline geprüft.
• [ ] Audio- und Videopositionen sowie Dokumentanhänge wurden tatsächlich geöffnet.
• [ ] Mac-Mitglieder haben nur freigegebene Codier- oder Prüfaufgaben erhalten.
• [ ] Jede Übergabe enthält Eingang, Prüfergebnis, Verantwortliche und nächsten Arbeitsschritt.
• [ ] Der finale Export wurde auf der Hauptplattform erneut erzeugt.
• [ ] Archiv, Austauschkopie, Versionsnotiz und Wiederherstellungsschritte sind vollständig.
• [ ] Zugriffsrechte, Speicherort und Löschung entsprechen den Hochschul- und DSGVO-Vorgaben.
• [ ] Bei fehlender eigener Mac-Hardware wurde die Empfangsseite vor der Archivierung separat getestet.

SECTION 09Wenn im Labor kein Mac verfügbar ist

Für eine einmalige Prüfung müssen Sie nicht sofort ein Gerät kaufen. Ein kontrollierter Remote-Mac kann als zeitlich begrenzte Empfangsumgebung dienen, sofern Sie eine eigene Berechtigung, einen geeigneten Speicherweg und ein anonymisiertes Testprojekt verwenden. Über VNC, SSH oder eine Webkonsole können Sie prüfen, ob die Datei auf macOS geöffnet wird, ob Anhänge erreichbar sind und ob die vorgesehenen Exporte entstehen. Sensible Originaldaten sollten Sie dabei nur nach ausdrücklicher Freigabe Ihrer Hochschule übertragen.

Ein Remote-Mac ersetzt nicht automatisch eine langfristige Forschungsinfrastruktur. Bei dauerhaft hoher Auslastung, benötigten physischen Laboranschlüssen oder institutionellen Vorgaben für lokale Speicherung kann ein eigener Hochschulrechner die bessere Lösung sein. Für eine einzelne Mac-Nutzerin, eine Annahmeprüfung vor der Abgabe oder einen kurzen Kompatibilitätstest vermeiden Sie damit jedoch eine Anschaffung, die über den eigentlichen Forschungsbedarf hinausgeht. Einen Überblick über den von MACNOX angebotenen Mac-Zugang und die verfügbaren Wege finden Sie auf der deutschen MACNOX-Seite.

Im Vergleich zu Ihrer bisherigen Lösung hat ein reiner Windows-Arbeitsplatz drei typische Nachteile: Mac-spezifische Übergaben bleiben ungetestet, die Gruppe entdeckt Pfad- oder Funktionsprobleme oft erst beim finalen Export, und eine einzelne Person wird zum Engpass für die Annahme auf macOS. Ein unkontrollierter privater Mac ist ebenfalls nicht ideal, weil Berechtigungen, Datenlöschung und Versionsstand schwerer nachweisbar sein können. Wenn Sie nur vorübergehend eine eigenständige Mac-Umgebung für die NVivo-Übergabe benötigen, ist das Mieten eines Remote-Mac von MACNOX deshalb häufig die besser abgrenzbare Option: Sie testen mit einem freigegebenen, anonymisierten Projekt, dokumentieren die Annahme und entscheiden erst danach, ob Ihre Gruppe langfristig eine eigene Mac-Infrastruktur braucht. Prüfen Sie vorab die MACNOX-Mietoptionen sowie die internen Datenschutz- und Lizenzvorgaben Ihrer Hochschule.

SECTION 10Weiterlesen

• Forschungssoftware beim Wechsel zwischen Intel und Apple Silicon sicher migrieren
• Eine Forschungssoftware auf dem Remote-Mac mit einer belastbaren Abnahme-Checkliste prüfen