Migración de repositorio GitLab self‑hosted a GitHub Enterprise preservando issues, merge requests y pipelines — plan a medida
Por Kevin Marcondes · Publicado el · 7 min de lectura
¿Necesitas migrar repositorios de GitLab self‑hosted a GitHub Enterprise preservando issues, merge requests y pipelines? Trabajamos con historial íntegro, mapeo de usuarios y conversión de MRs en PRs. Recreamos pipelines en GitHub Actions y validamos antes del corte. Planificamos la ventana, ejecutamos un piloto y reducimos riesgos sin prometer milagros.
Cuándo tiene sentido migrar y qué está en juego
La decisión suele motivarse por estandarización, reducción de costos operativos, seguridad o unificación de herramientas. El verdadero desafío es no perder el contexto: conversaciones, etiquetas, enlaces y automatizaciones de CI.
Al migrar, se espera repositorios íntegros, issues preservadas, PRs correspondientes y pipelines operativos al día siguiente. El objetivo es minimizar retrabajo e interrupciones.
Qué preservamos y cómo tratamos excepciones
Priorizamos la trazabilidad de extremo a extremo. Algunos elementos migran 1:1; otros exigen conversiones cuidadosas. Cuando no existe equivalencia directa, registramos referencias y añadimos evidencia para auditoría.
Para pipelines, traducimos etapas y variables de GitLab CI a GitHub Actions. Revisamos secrets, entornos y protecciones. Consulta también prácticas sobre despliegue con Actions en la guía pipeline de despliegue automático.
- Historial completo del Git (commits, tags y branches)
- Issues, labels, milestones y assignees cuando aplicable
- Merge Requests convertidas en Pull Requests con títulos, descripciones y comentarios
- Menciones y enlaces cruzados preservados cuando es posible
- Adjuntos descargados y reanexados o referenciados
- Pipelines reimplementados en GitHub Actions (workflows, jobs, matrices y artefactos)
- Variables y secrets mapeados por entorno y por repositorio
- Reglas de protección de branch y entornos ajustadas
Enfoque de migración: etapas y checkpoints
Aplicamos un flujo incremental y reversible. Nada de big bang sin red de seguridad. Cada etapa genera artefactos auditables y reejecutables.
Integramos seguridad desde el inicio. Consulta también el checklist de seguridad CI/CD para endurecer runners y gestión de secrets tras la migración.
- Descubrimiento e inventario: proyectos, grupos, integraciones y pipelines críticos
- Mapeo de usuarios, grupos y permisos (incluye SSO/SAML)
- POC técnica: validar APIs, límites y mapeos clave
- Piloto con proyectos representativos y validaciones de diff
- Plan de corte: freeze, comunicación, ventana y rollback
- Ejecución con logs y checkpoints reejecutables
- Validación post‑migración y corrección de apuntados
- Handover: documentación, capacitación y soporte de transición
Mapeos técnicos frecuentes (GitLab → GitHub)
No todo es idéntico entre plataformas. Anticipamos diferencias y documentamos decisiones. A continuación, un panorama de los mapeos más comunes.
| Elemento | GitLab | GitHub Enterprise | Observaciones |
|---|---|---|---|
| Repositorio | Project repo | Repository | Commits y tags preservados; remotes actualizados |
| Issues | Issues | Issues | Labels, milestones y assignees mapeados cuando son compatibles |
| Merge Request | Merge Request (MR) | Pull Request (PR) | Comentarios y diffs migrados; estados y approvals pueden requerir notas |
| Labels | Labels por projeto/grupo | Labels por repo/org | Normalizamos nombres y colores cuando es útil |
| Milestones | Milestones | Milestones/Projects | Projects pueden complementar milestones en GH |
| Pipelines CI | .gitlab-ci.yml | .github/workflows/*.yml | Equivalencia por jobs y stages; triggers adaptados |
| Runners | GitLab Runners | GitHub Runners | Planes para autoscaling: ver autoescalar runners |
| Variables/Secrets | CI/CD Variables | Actions Secrets/Variables | Ámbito: repo, org y entorno; rotación recomendada |
| Artifacts | Job artifacts | Actions artifacts | Plazos y retención revisados |
| Environments | Environments + approvals | Environments + branch rules | Protecciones y revisores obligatorios ajustados |
Riesgos comunes y cómo los mitigamos
Los riesgos típicos incluyen límites de API, referencias entre proyectos, adjuntos pesados y diferencias en triggers. Los anticipamos y diseñamos rutas de escape.
Para workloads que usan Docker, revisamos caching para mantener tiempos de build controlados. Consulta prácticas de BuildKit y caché remoto.
- Rate limits y timeouts: planificamos ventanas y backoff exponencial
- Referencias rotas: mapeo y post‑procesado de enlaces
- Adjuntos voluminosos: verificación previa y reupload segmentado
- Secrets expuestos: rotación y escaneo del historial
- Jobs manuales o programados: mapeados a workflow_dispatch y schedules
- Integraciones externas y webhooks: reconfigurados y probados
Qué recibes al final
Entregamos la migración con trazabilidad y materiales para la continuidad operativa. Esto reduce la dependencia de personas concretas y acelera la operación diaria.
- Plan de migración e informes de ejecución
- Scripts y playbooks reejecutables para repetir o deshacer pasos
- Matriz de mapeo de usuarios, labels y milestones
- Workflows de GitHub Actions revisados y documentados
- Checklist de validación por proyecto y evidencias
- Orientaciones para runners y escalabilidad
Señales de que necesitas este servicio
Si al menos uno de los puntos siguientes aplica a tu equipo, conviene hablar.
- Equipos detenidos por pipelines rotos tras clonar manualmente
- Pérdida de contexto en issues y comentarios al mover proyectos
- Dependencia de un único mantenedor de CI/CD
- Necesidad de cumplimiento y trazabilidad en el cambio
- Presión de tiempo para consolidar plataformas
- Runners y colas de CI saturadas sin plan de autoscaling
Cómo empezar: checklist de preparación
Una buena preparación reduce riesgos y periodos de indisponibilidad. Reúne la información esencial y prioriza un piloto representativo. En la ventana de corte, comunica stakeholders y criterios de éxito.
- Inventario de proyectos, grupos y dependencias entre repositorios
- Lista de integraciones externas: webhooks, registries y SSO/SAML
- Pipelines críticos, artefactos necesarios y SLAs internos
- Matriz de permisos: propietarios, mantenedores y revisores por proyecto
- Ventanas posibles de freeze y stakeholders involucrados
- Requisitos regulatorios o de auditoría que impacten la migración
Preguntas frecuentes
¿Es posible migrar todo 1:1 entre GitLab y GitHub Enterprise?
Muchos elementos migran de forma directa, como el historial Git, issues, labels y gran parte de los comentarios. Algunos estados, reglas de aprobación y recursos específicos no tienen equivalencia perfecta. En esos casos documentamos impactos y dejamos referencias claras para auditoría y validación.
¿Qué pasa con los pipelines de GitLab CI al migrar?
Convertimos .gitlab-ci.yml en workflows de GitHub Actions. Mapeamos triggers, jobs y matrices. Secrets y variables se revisan por ámbito. Jobs manuales y programados se transforman en workflow_dispatch y schedules. Revalidamos artefactos, caching y entornos antes del corte.
¿Se preservan los comentarios, adjuntos y menciones de las issues?
Comentarios y descripciones se migran cuando son accesibles vía API. Los adjuntos se descargan y reanexan o se referencian según tamaño y permisos. Las menciones de usuarios se traducen cuando existe mapeo entre identidades. Elementos sin equivalencia reciben notas de trazabilidad.
¿Habrá downtime durante la migración?
Planificamos un piloto y una ventana de corte para minimizar el impacto. Normalmente aplicamos un breve freeze de escritura en GitLab durante el espejo final. La duración depende del volumen de datos, adjuntos e integraciones. Documentamos rollback y criterios de éxito.
¿Cómo se tratan usuarios y permisos?
Construimos una matriz de mapeo entre usuarios y grupos, considerando SSO o SAML cuando existan. Ajustamos equipos, perfiles de acceso y protecciones de branch en GitHub Enterprise. Validamos accesos en proyectos piloto antes del corte.
¿Listo para migrar con seguridad y previsibilidad?
Cuéntanos tus repositorios, integraciones y pipelines críticos. Te enviaremos un plan de migración con próximos pasos y la opción de piloto.
Quiero discutir mi migraciónVer también
- Servicio de diagnóstico y corrección de resolución DNS entre contenedores Docker y el host (bridge, overlay, systemd‑resolved)
- Monitorización proactiva de conexiones y pools de PostgreSQL con alertas para evitar 'too many connections' en picos de facturación
- Servicio de integración de eventos y analytics para apps móviles híbridas (Capacitor / React Native) con Amplitude y seguimiento por usuario
- Preparación de servidores Linux para PCI‑DSS (hardening, logging, segmentación de red)