Von Jira zu monday Dev migrieren – der Schritt-für-Schritt-Leitfaden 2026

Warum Migrationen scheitern – und wie ihr das verhindert

Die meisten Tool-Migrationen scheitern nicht an der Technik. Sie scheitern an drei Dingen:

1. Lift-and-Shift-Mentalität: „Wir bauen Jira 1:1 in monday nach." Falsch. Ihr nehmt die alten Probleme einfach mit.
2. Zu langer Parallel-Betrieb: „Wir lassen Jira noch 6 Monate laufen, falls was schiefgeht." Falsch. Niemand pflegt zwei Systeme gleichzeitig – Daten driften auseinander.
3. Kein Pilot-Team: „Wir migrieren alle gleichzeitig zum Quartalswechsel." Falsch. Pilot-Team zuerst, lernen, dann skalieren.

Dieser Leitfaden basiert auf 20+ realen Jira-→-monday-Dev-Migrationen, die wir bei Pacta gemacht haben. Funktioniert für Teams von 20 bis 500 Engineers.

Realistischer Zeitplan

Team-Größe	Vorbereitung	Pilot	Roll-out	Hypercare	Gesamt
20–50 Engineers	1 Woche	1 Woche	1 Woche	1 Woche	~4 Wochen
50–150 Engineers	2 Wochen	2 Wochen	2 Wochen	2 Wochen	~8 Wochen
150–500 Engineers	3 Wochen	3 Wochen	4 Wochen	4 Wochen	~14 Wochen

⚠️ Wer sagt „wir migrieren in einem Wochenende" hat noch nie eine echte Migration gemacht. Plant ehrlich.

---

Phase 1 – Vorbereitung & Discovery

Schritt 1: Jira-Inventur

Bevor ihr irgendetwas migriert, müsst ihr wissen, was ihr habt. Exportiert aus Jira:

• Liste aller Projekte (mit Owner, Issue-Count, letzte Aktivität)
• Liste aller Custom Fields (mit Nutzung pro Projekt)
• Liste aller Workflows (mit Status-Übergängen)
• Liste aller Automations (Atlassian Automation, ScriptRunner etc.)
• Liste aller Plugins und ihrer Daten (Tempo, Structure, BigPicture etc.)

Schritt 2: Aggressiv reduzieren

Das ist der wichtigste Schritt. 80 % der Custom Fields werden nie genutzt. 60 % der Workflows sind Karteileichen.

Faustregeln:

• Custom Field nicht in den letzten 90 Tagen genutzt → weg
• Workflow weniger als 50× durchlaufen pro Jahr → konsolidieren
• Projekte mit < 5 Issues in 6 Monaten → archivieren statt migrieren

Ergebnis: oft 70 % weniger Komplexität vor der Migration.

Schritt 3: Ziel-Architektur in monday Dev definieren

monday Dev denkt anders als Jira:

Jira	monday Dev
Project	Workspace + Boards
Epic	Item in Roadmap-Board
Story / Task	Item in Sprint-Board
Sub-task	Sub-Item
Custom Fields	Spalten (Columns)
Workflow Status	Status-Spalte (Labels)
Sprint	Sprint-Gruppe oder eigenes Sprint-Feature
Component	Tag oder eigene Spalte

Empfehlung: Pro Squad ein Workspace, darin Sprint-Board + Bug-Board + Roadmap-Board. Nicht versuchen, alles in einem Board abzubilden.

Schritt 4: Stakeholder-Mapping

Wer muss vor der Migration einbezogen werden?

• Engineering Leads aller Squads
• Product Manager
• QA / Testing
• Security & Compliance (wegen Audit Logs)
• Finance (Lizenzkosten, Verträge)
• Tooling/DevOps (Integrationen mit GitHub, Slack, CI/CD)

---

Phase 2 – Pilot mit einem Team

Warum Pilot zuerst?

Das Pilot-Team validiert eure Architektur mit echten Daten und echten Menschen. Was im Whiteboard funktioniert, scheitert oft im Daily.

Pilot-Team-Auswahl

Wählt ein Team, das:

• 5–10 Engineers hat (groß genug für aussagekräftige Tests, klein genug für schnelle Iteration)
• Aufgeschlossen für Tools ist (kein „aber das haben wir schon immer so gemacht")
• Nicht im kritischsten Release-Sprint steckt
• Repräsentative Workflows hat (Sprint + Bug + Roadmap)

Was im Pilot getestet wird

• ✅ Datenmigration: Alle Issues kommen sauber an
• ✅ Sprint-Workflow: Planning, Stand-up, Review funktionieren
• ✅ Integrationen: GitHub PR-Linking, Slack-Notifications, CI/CD-Status
• ✅ Reporting: Burndown, Velocity, Cycle Time
• ✅ Permissions: Wer sieht was?
• ✅ Mobile App: Funktioniert für unterwegs?

Pilot-Erfolgs-Kriterien

Definiert vor dem Pilot klare Kriterien. Beispiel:

• Sprint Velocity stabil oder besser nach 2 Sprints
• Keine kritischen Bugs in der Migration
• 80 % Team-Zustimmung im Retro
• Alle Integrationen funktionieren

---

Phase 3 – Datenmigration (technisch)

Option A: Native Tools (für < 5.000 Issues)

monday hat einen Jira-Importer im Marketplace, der Basis-Daten überträgt:

• Issues mit Title, Description, Status, Priority
• Assignees (sofern E-Mail-Match)
• Labels und Components
• Comments (limitiert)

Limitierungen: Custom Fields, Sub-Tasks, Attachments, Workflow-History gehen oft verloren.

Option B: API-basiert mit Make/n8n (für 5.000–50.000 Issues)

Für mehr Kontrolle baut ihr einen Migration-Flow:

1. Jira REST API → JSON-Export aller Issues
2. Transformation in Make/n8n: Field-Mapping, Status-Konversion, Sub-Task-Resolution
3. monday GraphQL API → Bulk-Import via create_item-Mutations
4. Validation: Diff-Check zwischen Quelle und Ziel

Tipp: Migriert in Batches à 500 Items, mit Retry-Logik. Beide APIs haben Rate-Limits.

Option C: Custom-Migration (für 50.000+ Issues oder hohe Komplexität)

Für große Migrationen lohnt sich ein dedizierter Migration-Service – wir machen das regelmäßig mit Python-Skripten gegen beide APIs, inklusive Attachment-Transfer und Comment-Threading.

Was IMMER manuell migriert werden sollte

• Dashboards – die Konzepte unterscheiden sich zu stark, automatische Migration produziert Müll
• Komplexe Automations – baut sie in monday neu, oft viel einfacher
• Permission-Schemes – sicherheitskritisch, lieber händisch validieren

---

Phase 4 – Cutover & Rollout

Harter Cutover statt Parallelbetrieb

Setzt einen Stichtag (idealerweise Freitagabend nach Sprint-Ende). Ab Montag arbeitet das ganze Team in monday Dev. Jira ist read-only für 30 Tage als Referenz, dann wird es archiviert.

Warum keine Parallelität? Weil Menschen den Weg des geringsten Widerstands gehen. Wenn beide Tools laufen, pflegt niemand monday Dev richtig – und ihr habt nach 3 Monaten zwei kaputte Systeme.

Rollout-Reihenfolge

1. Pilot-Team (Woche 1–2)
2. Early Adopters (Woche 3–4): 2–3 weitere offene Teams
3. Mainstream (Woche 5–8): Rest der Engineering-Org
4. Stragglers (Woche 9+): Teams mit komplexen Setups oder Compliance-Anforderungen

Training-Pflicht

Niemand startet auf monday Dev ohne mindestens 2 Stunden Training:

• 1h Live-Demo mit dem Squad
• 1h Selbststudium (monday-Academy oder eure interne Doku)
• Office Hours in den ersten 2 Wochen

---

Phase 5 – Hypercare

Die ersten 2–4 Wochen nach Cutover sind kritisch. Plant Hypercare:

• Dedicated Slack-Channel (#monday-dev-help) mit schneller Antwortzeit
• Tägliche Office Hours (15 Min) mit dem Migration-Lead
• Wöchentliche Retro: Was läuft? Was nervt? Was muss nachgebessert werden?
• KPI-Tracking: Adoption, Sprint Velocity, Time-to-Resolution

Wenn nach 4 Wochen alle KPIs grün sind: Migration erfolgreich. Hypercare beenden, Normalbetrieb starten.

---

Die Migration-Checkliste

Vorbereitung (Woche 1–2)

• Jira-Inventur abgeschlossen (Projekte, Custom Fields, Workflows, Automations)
• Aggressive Reduktion durchgeführt (Ziel: -70 % Komplexität)
• Ziel-Architektur in monday Dev dokumentiert
• Stakeholder-Mapping abgeschlossen
• Pilot-Team ausgewählt und gebrieft
• Migration-Lead bestimmt
• Backup von Jira erstellt

Pilot (Woche 3–4)

• Workspace für Pilot-Team aufgesetzt
• Sprint-, Bug- und Roadmap-Board konfiguriert
• Daten des Pilot-Teams migriert
• GitHub-/Slack-/CI-Integrationen aktiv
• Pilot-Team trainiert
• 2 Sprints in monday Dev gelaufen
• Retro durchgeführt, Erfolgs-Kriterien validiert

Datenmigration (Woche 5)

• Migrations-Methode gewählt (Importer / Make / Custom)
• Field-Mapping dokumentiert
• Test-Migration auf Staging durchgeführt
• Diff-Check Quelle/Ziel
• Attachment-Transfer validiert
• Permissions in monday Dev gesetzt

Cutover (Woche 6)

• Stichtag kommuniziert (mind. 2 Wochen Vorlauf)
• Finale Migration am Cutover-Wochenende
• Jira auf read-only gesetzt
• Alle Teams trainiert
• Slack-Hypercare-Channel live

Hypercare (Woche 7–10)

• Tägliche Office Hours
• Wöchentliche Retros
• KPI-Tracking
• Adoption > 90 % nach 4 Wochen
• Jira nach 30 Tagen archiviert

---

Best Practices aus 20+ Migrationen

✅ Do

• Reduziert vor der Migration, nicht danach. Sonst tragt ihr Altlasten mit.
• Pilot-Team ernst nehmen. Lieber 2 Wochen länger im Pilot als 6 Monate Chaos im Rollout.
• Hartes Cutover-Datum. Kommuniziert es früh, kommuniziert es oft.
• Training ist Pflicht, nicht Empfehlung.
• Hypercare-Budget einplanen. Das ist keine „Gold-Plating", das ist Pflicht.

❌ Don't

• Kein Lift-and-Shift. Nutzt die Chance, Workflows zu vereinfachen.
• Kein endloser Parallelbetrieb. Maximal 30 Tage read-only.
• Keine Migration im Q4 oder vor großen Releases.
• Keine Migration ohne Executive Sponsor. Ohne Rückendeckung kippt das Projekt beim ersten Widerstand.
• Nicht versuchen, alle Atlassian-Plugins 1:1 zu ersetzen. Vieles braucht ihr in monday Dev gar nicht mehr.

---

Wann ihr Hilfe braucht

Wenn eines davon zutrifft, holt euch externe Unterstützung (uns oder andere monday-Partner):

• 100+ Engineers
• Komplexe Compliance-Anforderungen (ISO 27001, SOC 2, FDA)
• Tiefe Atlassian-Plugin-Abhängigkeit (Tempo, Structure, ScriptRunner)
• Multi-Region-Setup mit Datenresidenz-Anforderungen
• Migration parallel zu anderen großen Tool-Wechseln

🚀 Pacta migriert regelmäßig Engineering-Orgs von Jira auf monday Dev – inklusive technischer Migration, Workflow-Redesign und Team-Onboarding. Erstgespräch in 30 Min: Jetzt buchen.

---

Weiterlesen

• monday Dev: Das am meisten unterschätzte Dev-Tool 2026
• monday Dev vs. Jira – ehrlicher Vergleich
• monday Dev vs. Linear – wer gewinnt 2026?
• monday MCP Tools & Integrationen