Umziehen von awork, ohne vorher zu raten.

Im Probelauf: nichts, er schreibt keine Zeile. Im echten Lauf gilt: Jeder Datensatz merkt sich, aus welchem awork-Objekt er stammt. Bricht der Lauf mittendrin ab, startest du ihn neu, und er aktualisiert das bereits Angelegte, statt es zu doppeln. Der schlimmste Fall ist damit kein Datensalat, sondern Zeitverlust. Und weil du vor dem echten Lauf den Bericht in der Hand hast, sind die typischen Überraschungen vorher schon bekannt.

Ehrlich: Es kommt auf die Datenmenge an, und der Import ist bewusst nicht auf Tempo gebaut. Er blättert vollständig durch alle Seiten und macht zwischen den Seiten Pausen, damit das Anfragen-Limit von awork nicht anschlägt. Bei mehreren zehntausend Zeiteinträgen sind das eher Stunden als Minuten. Weil der Lauf im Hintergrund läuft und wiederholbar ist, ist das in der Praxis kein Problem: Dein Team arbeitet in der Zwischenzeit normal weiter.

Ja, mit einer wichtigen Einschränkung, die zu deinem Vorteil ist. Datum, Dauer, Notiz, Abrechenbarkeit und der Bezug zur Aufgabe kommen mit. Was in awork als abgerechnet markiert ist, kommt als gesperrter Eintrag an und läuft damit nicht ein zweites Mal in eine Rechnung. Die Stunden- und Kostensätze aus awork übernehmen wir bewusst nicht: In Octibiz ergeben sie sich aus Vertrag, Projekt und Mitarbeiter, und ein mitgeschleppter Fremdsatz würde still falsch rechnen.

Nein, und das ist Absicht. Der Import gleicht die awork-Nutzer über die E-Mail-Adresse mit deinen bestehenden Mitarbeitern ab. Ein Personenkonto mit Rechten soll nicht als Nebenwirkung einer Migration entstehen. Wer kein Gegenstück hat, steht mit Grund im Bericht, und du legst die Person vorher an oder lässt sie bewusst weg. Praktischer Ablauf: erst die Mitarbeiter in Octibiz anlegen, dann den Probelauf noch einmal fahren. Die Liste sollte dann leer sein.

Ja, genau dafür ist es gebaut. Du kannst einzelne Bereiche gezielt laufen lassen, etwa erst Nutzer, Kunden und Projekte, später Aufgaben, Zeiten und Dateien. Die fachliche Reihenfolge erzwingt der Import selbst, weil Aufgaben ohne Projekte und Zeiten ohne Aufgaben wertlos wären. Jeder Bereich lässt sich später erneut laufen lassen, ohne dass Dubletten entstehen.

Manches wird bewusst übersetzt statt eins zu eins kopiert. Aus einer awork-Checkliste wird die Definition of Done der Aufgabe. Aus Aufgaben-Kommentaren werden Beiträge in derselben Zeitleiste, in der später auch Mails und Ticket-Antworten stehen, es gibt also keinen zweiten Kommentar-Speicher für Altdaten. Die awork-Beschreibung eines Projekts landet in den Projektnotizen, weil sie dort gelesen wird. Wo eine Übersetzung nicht sauber möglich ist, wird der Fall übersprungen und im Bericht aufgeführt statt still verbogen.

Das entscheidest du vor dem Import, und zwar zwingend: Sobald mehr als eine Marke existiert, verlangt schon der Probelauf die Ziel-Marke. Der Grund ist unangenehm konkret: Ohne Angabe landen Projekte, Aufgaben, Listen und Zeiten markenlos, und markenloser Bestand ist für jede Marke sichtbar. Eine Migration würde die Trennung damit aufheben, ohne dass es jemand bemerkt. Die gewählte Marke steht im Kopf des Berichts, Aufgaben und Listen erben sie vom Projekt, Zeiten von ihrem Vorgang.

Nein. Es ist ein Umzugswagen. Ist der Umzug durch, wird es deinstalliert, und die importierten Daten bleiben vollständig erhalten. Was bleibt, ist die Herkunftskennung am Datensatz, damit später noch nachvollziehbar ist, woher etwas stammt. Wenn du dauerhaft Daten mit einem Fremdsystem austauschen willst, ist das eine andere Aufgabe, und dafür gibt es den Integrations-Hub.