DEV Community: Claudio Cesar

What really breaks large-scale cloud migrations — Solution!

Claudio Cesar — Thu, 05 Feb 2026 22:25:10 +0000

Large-scale cloud migrations are often described as straightforward technical upgrades. In practice, however, they represent complex engineering exercises in which architectural decisions, risk management, and human judgment carry significantly more weight than the choice of tools or platforms.

This article presents a realistic engineering perspective on how a complex migration was analyzed, planned, and executed under strict operational constraints. Rather than focusing on specific technologies, the objective is to highlight the challenges encountered, the strategic decisions adopted, and how engineering discipline enabled a sustainable and successful outcome.

The Hidden Complexity Behind “Simple” Migrations

From an external perspective, migration projects often appear direct: systems are moved, infrastructure is modernized, and efficiency is improved. Internally, the reality is considerably more complex.

The environment under analysis consisted of a highly interconnected ecosystem developed over many years. Documentation was fragmented, multiple dependencies were implicit rather than explicitly defined, and several systems had evolved beyond their original architectural assumptions.

This scenario significantly increased operational risk. Incorrect decisions could result in service outages, data inconsistency, or systemic instability. Consequently, the challenge was not merely technical, but fundamentally strategic, requiring a constant balance between innovation and operational continuity.

Engineering Decisions Under Real-World Constraints

One of the central aspects of the project was the recognition that a direct and mechanical migration approach would not be appropriate. Simply reproducing the existing environment in a new context would have perpetuated the same structural limitations and operational risks.

In response, an engineering-driven approach was adopted, guided by the following principles:

Each system was analyzed individually, considering criticality, dependencies, and real usage patterns
Legacy assumptions were reviewed and challenged in light of new operational requirements
Architectural redesigns were applied whenever necessary
In multiple scenarios, clean installations and restructured architectures proved essential to ensure long-term stability and sustainability
These decisions demanded a high level of technical accountability, as they directly affected operational safety, service reliability, and the environment’s ability to evolve over time.

Technical Leadership and Decision Coordination

The complexity of the migration required more than technical execution. It also demanded structured coordination of decisions and alignment across multiple technical domains.

Migration strategy definition, architectural change approval, and risk prioritization were conducted through a centralized technical governance model. This approach ensured coherence across all project phases, reduced rework, and guaranteed that decisions remained aligned with the broader strategic objectives.

Designing for Reliability and Recovery

Risk mitigation was treated as a foundational element from the earliest planning stages. Rollback and recovery strategies were considered first-class requirements rather than reactive mechanisms.

Each significant change underwent progressive validation, controlled testing, and pre-defined fallback planning. This approach ensured that critical services remained available throughout the migration process and that the environment retained rapid recovery capabilities in the event of unexpected conditions.

In this context, engineering rigor was prioritized over execution speed.

Execution and Achieved Outcomes

The migration was completed successfully, delivering concrete and measurable results:

Continuity of critical services without unplanned downtime
Significant reduction in operational and licensing costs
Substantial improvements in scalability, automation, and resilience
Consolidation of a modern architectural foundation prepared for future growth

These outcomes were achieved through deliberate technical decisions, careful reassessment of existing architectures, and consistent application of sound engineering practices.

External Recognition and Institutional Impact

Beyond internal results, the migration became a reference case within an external technical audit process. The migration documentation was formally used to validate the adopted engineering approach, architectural decisions, and achieved results.

As a result, the project received public recognition as a successful example of a complex migration executed under real-world constraints. This independent and external validation reinforced both the technical relevance and the institutional impact of the work.

Final Considerations'

This experience reinforces a lesson widely acknowledged in complex systems engineering: successful migrations are not defined by tools, vendors, or market trends. They are defined by technical judgment, accountability, and disciplined decision-making under pressure.

Engineering excellence emerges when complexity is addressed transparently, risks are managed systematically, and solutions are designed with long-term sustainability in mind. The reflections shared here may serve as a reference for professionals facing similarly complex migration challenges.

O que realmente quebra em migrações de nuvem em larga escala — Solução !

Claudio Cesar — Thu, 05 Feb 2026 22:00:36 +0000

Migrações de nuvem em larga escala são frequentemente descritas como simples atualizações técnicas. Na prática, porém, elas representam exercícios complexos de engenharia, nos quais decisões arquiteturais, gestão de riscos e julgamento humano têm impacto significativamente maior do que a escolha de ferramentas ou plataformas específicas.

Este artigo apresenta uma perspectiva realista sobre como uma migração complexa foi analisada, planejada e executada sob restrições operacionais rigorosas. O foco não está em tecnologias isoladas, mas nos desafios enfrentados, nas decisões estratégicas adotadas e em como a disciplina de engenharia permitiu alcançar um resultado sustentável e bem-sucedido.

A complexidade oculta por trás de migrações “simples”

Do ponto de vista externo, projetos de migração costumam parecer diretos: mover sistemas, modernizar a infraestrutura e ganhar eficiência operacional. Internamente, a realidade tende a ser muito mais complexa.

O ambiente analisado era composto por um ecossistema altamente interconectado, construído ao longo de muitos anos. A documentação encontrava-se fragmentada, diversas dependências eram implícitas e vários sistemas haviam evoluído além das premissas originais de arquitetura.

Esse cenário aumentava significativamente o risco operacional. Decisões incorretas poderiam resultar em indisponibilidade de serviços críticos, inconsistência de dados ou instabilidade sistêmica. Assim, o desafio apresentado não era apenas técnico, mas essencialmente estratégico, exigindo equilíbrio constante entre inovação e continuidade operacional.

Decisões de engenharia sob restrições reais

Um dos pontos centrais do projeto foi o reconhecimento de que uma migração direta e mecânica não seria adequada. A simples reprodução do ambiente existente em um novo contexto implicaria a perpetuação das mesmas limitações estruturais e riscos operacionais.

Diante disso, foi adotada uma abordagem orientada por engenharia, baseada nos seguintes princípios:

Cada sistema foi analisado de forma individual, considerando criticidade, dependências e padrões reais de uso

Premissas legadas foram revisadas e questionadas à luz de novos requisitos operacionais

Redesenhos arquiteturais foram aplicados sempre que necessário

Em diversos cenários, instalações limpas e arquiteturas reestruturadas mostraram-se essenciais para garantir estabilidade e sustentabilidade de longo prazo

Essas decisões exigiram elevado grau de responsabilidade técnica, uma vez que impactavam diretamente a segurança operacional, a confiabilidade dos serviços e a capacidade de evolução futura do ambiente.

Liderança técnica e coordenação de decisões

A complexidade do projeto exigiu não apenas execução técnica, mas também coordenação estruturada de decisões e alinhamento entre diferentes especialidades técnicas.

A definição da estratégia de migração, a aprovação de mudanças arquiteturais e a priorização de riscos foram conduzidas de forma centralizada, garantindo coerência técnica ao longo de todas as etapas. Esse modelo de governança técnica foi fundamental para manter consistência, reduzir retrabalho e assegurar que as decisões estivessem alinhadas aos objetivos estratégicos do projeto.

Projetando para confiabilidade e recuperação

A mitigação de riscos foi tratada como um elemento fundamental desde as fases iniciais do planejamento. Estratégias de rollback e recuperação foram consideradas requisitos essenciais, e não mecanismos reativos.

Cada mudança relevante passou por validações progressivas, testes controlados e definição prévia de planos de retorno. Essa abordagem assegurou que serviços críticos permanecessem disponíveis durante todo o processo e que o ambiente tivesse capacidade de recuperação rápida diante de eventos inesperados.

Nesse contexto, o rigor de engenharia foi priorizado em detrimento da velocidade de execução.

Execução e resultados alcançados

A migração foi concluída com êxito, gerando benefícios concretos e mensuráveis:

Continuidade dos serviços críticos sem indisponibilidades não planejadas

Redução significativa de custos operacionais e de licenciamento

Melhoria expressiva em escalabilidade, automação e resiliência

Consolidação de uma base arquitetural moderna e preparada para crescimento futuro

Esses resultados foram alcançados a partir de decisões técnicas conscientes, revisão criteriosa de arquiteturas existentes e aplicação consistente de boas práticas de engenharia.

Reconhecimento externo e impacto institucional

Além dos resultados internos, o projeto tornou-se referência em um processo de auditoria técnica externa. A documentação da migração foi utilizada formalmente para validação do modelo adotado, das decisões arquiteturais e dos resultados alcançados.

Como consequência, o projeto foi reconhecido publicamente como um caso de sucesso, sendo utilizado como exemplo de migração bem-sucedida em contextos de alta complexidade. Esse reconhecimento externo e independente reforçou a relevância técnica e o impacto institucional do trabalho realizado.

Considerações finais

Essa experiência reforça uma lição amplamente reconhecida na engenharia de sistemas complexos: migrações bem-sucedidas não dependem apenas de ferramentas, fornecedores ou tendências de mercado. Elas exigem julgamento técnico, responsabilidade e tomada de decisão disciplinada sob pressão.

A excelência em engenharia emerge quando a complexidade é enfrentada com transparência, os riscos são tratados de forma estruturada e as soluções são concebidas com foco em sustentabilidade de longo prazo. As reflexões apresentadas aqui podem servir de referência para profissionais que enfrentam desafios semelhantes em projetos de migração de grande escala.

From Chaos to Perfect Flow: My Experience Automating a Massive Real GitLab Migration (4,000 Repos)

Claudio Cesar — Wed, 17 Dec 2025 20:02:00 +0000

Migrating thousands of repositories can feel like one of those nightmares that wake engineers up in the middle of the night. But for me, it became one of the most transformative experiences of my journey with DevOps and automation.
This article is an honest and practical report of how I automated the migration of approximately 4,000 GitLab Community Edition projects to GitLab Enterprise Edition — without disrupting teams, without losing history, and without breaking production pipelines.
It is a story about chaos, discipline, automation, and, above all, how errors are an essential part of the process.

Why This Migration Needed to Happen

GitLab Community Edition works well in the beginning. But as teams grow, repositories multiply, and CI/CD volume explodes, clear limitations appear:

lack of governance
inconsistent configurations
heterogeneous runners
unstable pipelines
absence of essential enterprise features

Migrating to GitLab Enterprise Edition was more than a technical improvement.

It was a step toward organizational maturity.

The challenge?
There is no official migration process that preserves everything correctly.
With no alternative, I had to create a custom solution.

What Makes This Migration So Complex?

Moving 4,000 projects is not just moving folders.
It means preserving an entire ecosystem, including:

full commit history
protected branches
release tags
variables and secrets
scattered CI/CD includes
issues and comments
archived-state preservation
runners and permissions

GitLab’s native import/export tool breaks large parts of this along the way.
I needed automation capable of migrating everything — reliably.

The Toolkit That Built the Bridge

I developed a modular set of Bash scripts to maintain absolute control over each part of the migration.
It is publicly available here:

👉 https://github.com/clcesarval/migrar-gitlab

The architecture had two clear layers:

1. The Git Layer

Responsible for:

cloning all repositories
reconstructing branches
ensuring DAG integrity
preserving tags exactly as in CE
reconfiguring remotes
restoring archived state

2. The API Layer

Responsible for:
variables and secrets
issues and comments
group hierarchies
permissions
recreating projects in the destination

Each script did only one thing — but did it precisely.

Some key components:

clone-projects.sh
replace_gitlab-ci.sh
push_projects.sh
migrar-variaveis.sh
migrate-issues.sh
recursive scripts for subgroups
complete runner inventory

It was purposeful automation — not magic.

The Hidden Chaos That Appeared

The official documentation helped, but only partially. Many sections were inconsistent, incomplete, or simply failed when applied at large scale.

I also identified issues such as:

CI includes using absolute paths that would break after migration
duplicated or unsafely scoped variables
runners with unpredictable configurations
archived projects reappearing as active when using import/export
tags being incorrectly recreated

Using the official process could have caused severe operational impact across the organization.

Pilot Tests… and the Errors That Saved the Migration

To ensure everything would work, I ran several pilot tests in isolated environments.
And all of them — without exception — failed at first.

I faced:

include: /old-group/subgroup/template.yml

pipelines breaking due to outdated includes
missing variables that caused job failures
runners rejecting executions
YAML-invalid errors caused by invisible details
tags disappearing or being recreated incorrectly
group hierarchies being created out of order

And that was exactly why the migration succeeded.

I built a script that recursively analyzed every include inside the cloned directories and automatically replaced paths according to the new GitLab structure.

Every failure revealed the real behavior of GitLab.
Errors taught more than any documentation ever could.
With each test I:

added new validations
created filters
strengthened logs
fixed edge cases
implemented idempotent checks

When the tests finally ran clean, the automation proved truly reliable.

The Real Migration Day

When the full migration pipeline ran, the outcome matched exactly what is expected from a well-engineered solution:

no history lost
no broken tags
pipelines working properly
variables recreated with correct scopes
hierarchy preserved
code arriving exactly as expected
archived repositories staying archived
runners behaving consistently

It was like transforming a chaotic environment into a predictable, standardized, governed system.

The Impact on the Teams

Even without early formal DORA metrics, the post-migration behavior was clear.

After the migration:

Deploys became more frequent
Lead time dropped drastically
Pipelines became more stable
Change Failure Rate decreased
Standardized runners reduced unexpected failures
Recovery became faster thanks to intact history

The entire organization began delivering faster.

What This Experience Taught Me

This project taught me that:

official documentation never covers 100% of cases
standardization is the foundation of reliability
pipelines depend deeply on clean, well-scoped variables
runners define the invisible health of CI/CD
errors play an essential role in engineering
good automation builds confidence

And the biggest lesson:

When you reorganize the foundation, the entire development flow improves.

Conclusion

Migrating thousands of projects is not just a technical challenge.
It’s a test of discipline, engineering, and resilience.

With deterministic automation, real pilot tests, and learning through errors, it was possible to migrate around 4,000 repositories safely, preserving code integrity, pipelines, history, and governance.

A future evolution is also under consideration: rewriting the toolkit in Python, enabling more flexibility and fluidity without losing the robustness of the current Bash solution.

The solution is publicly available and may help others facing similar challenges:

⭐ If you liked the project, please leave a ⭐ star ⭐ on GitHub — it helps support and recognize the work.
👉 https://github.com/clcesarval/migrar-gitlab

If you are planning a large-scale migration, remember:

Errors are not enemies.
They are guides.
And good automation turns fear into confidence.

** References**

GitLab Documentation — https://docs.gitlab.com/ee/

GitLab Import/Export Guide — https://docs.gitlab.com/ee/user/project/settings/import_export.html

GitLab API Reference — https://docs.gitlab.com/ee/api/

Google Cloud — DORA Research & Four Key Metrics — https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

Accelerate: State of DevOps Report (DORA) — https://www.devops-research.com/research.html

Martin Fowler — Continuous Delivery & IaC — https://martinfowler.com/

Google SRE Book — https://sre.google/sre-book/

Pro Git — Git Internals — https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

Advanced Bash Scripting Guide — https://tldp.org/LDP/abs/html/

GitHub Engineering — https://github.blog/engineering/

Do Caos ao Fluxo Perfeito: Minha Experiência Automatizando uma Migração Real Gigantesca no GitLab (4.000 Repos)

Claudio Cesar — Wed, 17 Dec 2025 19:48:01 +0000

Por que essa migração precisava acontecer
O GitLab Community Edition funciona bem no começo. Mas, quando os times crescem, os repositórios se multiplicam e o volume de pipelines explode, surgem limites claros:
falta de governança
configurações inconsistentes
runners heterogêneos
pipelines instáveis
ausência de recursos corporativos essenciais

A migração para o GitLab Enterprise Edition era mais que uma melhoria técnica.
Era um passo em direção à maturidade organizacional.
O desafio?
Não existe uma migração oficial que preserve tudo corretamente.
Sem outra saída, foi criado uma solução própria.

O que torna essa migração tão complexa?
Mover 4 mil projetos não é mover pastas.
É preservar um ecossistema inteiro, com elementos como:
histórico completo de commits
branches protegidas
tags de releases
variáveis e segredos
pipelines com includes espalhados
issues e comentários
estados de arquivamento
runners e permissões

A ferramenta nativa de import/export do GitLab quebra grande parte disso no caminho.
Eu precisava construir uma automação capaz de migrar tudo, confiavelmente.

O toolkit que construiu a ponte
Foi desenvolvido um conjunto modular de scripts em Bash para garantir controle absoluto sobre cada parte da migração. Ele está publicado aqui:
👉 https://github.com/clcesarval/migrar-gitlab
A arquitetura tinha duas camadas claras:

A camada Git
Responsável por:
clonar todos os repositórios
reconstruir branches
garantir a integridade do DAG
preservar tags exatamente como no CE
reconfigurar remotes
reaplicar estado de arquivamento
A camada API
Responsável por:
variáveis e segredos
issues e comentários
hierarquias de grupos
permissões
recriação de projetos no destino

Cada script fazia apenas uma coisa, mas fazia com precisão.
Entre eles:
clone-projects.sh
replace_gitlab-ci.sh
push_projects.sh
migrar-variaveis.sh
migrate-issues.sh
scripts recursivos para subgrupos
inventário completo de runners

Era automação com propósito, não mágica.

O caos escondido que apareceu
A documentação oficial ajudava, mas apenas parcialmente. Muitas partes eram inconsistentes, incompletas ou simplesmente não funcionavam como descrito quando aplicadas em grande escala.
Além disso, detectei problemas como:
includes de pipeline com caminhos absolutos que quebrariam após a migração
variáveis duplicadas, sem escopo ou mal organizadas
runners antigos com configurações imprevisíveis
projetos arquivados reaparecendo como ativos na importação oficial
tags sendo recriadas de forma incorreta

A adoção do processo padrão teria potencialmente causado um impacto operacional severo em toda a organização.

Os testes piloto… e os erros que salvaram a migração
Para garantir que tudo funcionaria, rodei vários testes piloto, em ambientes isolados.
E todos eles, sem exceção, apresentaram erros no começo.
Tive:

include: /old-group/subgroup/template.yml

pipelines quebrando por includes antigos
variáveis ausentes que derrubavam jobs
runners recusando execuções
YAML inválido por detalhes invisíveis
tags que desapareciam ou eram recriadas incorretamente
hierarquias surgindo fora de ordem

E essa foi exatamente a razão do sucesso final.

Para mitigar os problemas de pipelines quebrando por includes antigos por exemplo, criei um script que analisava cada include recursivamente dentro das pastas clonadas localmente e assim adicionava o novo path automaticamente conforme ele criava o novo path no novo Gitlab.
Cada falha revelou o comportamento real do GitLab.
Os erros ensinaram mais do que qualquer documentação poderia ensinar.
A cada teste:
adicionava novas validações
criava filtros
reforçava logs
corrigia casos especiais
adicionava verificações idempotentes

Quando os testes finalmente passaram limpos, a automação demonstrou ser realmente confiável.

O dia da migração real
Quando o pipeline de migração completo foi executado, o resultado correspondeu exatamente ao esperado em um cenário de engenharia bem-sucedido.
nenhum histórico perdido
nenhuma tag quebrada
pipelines funcionando
variáveis recriadas com os escopos certos
hierarquia preservada
código chegando ao destino corretamente
repos arquivados permanecendo arquivados
runners funcionando de forma uniforme

Foi como transformar um sistema caótico em um ambiente previsível, padronizado e governado.

O impacto disso nos times
Mesmo sem medições formais de DORA no início, o comportamento pós-migração foi nítido.

Dora impact and metrics.Depois da migração:
Deploys ficaram mais frequentes
Lead time caiu drasticamente
Pipelines se tornaram mais estáveis
O Change Failure Rate caiu
Runners padronizados reduziram erros estranhos
Recuperações ficaram mais rápidas graças ao histórico íntegro

Toda a organização passou a se mover com mais velocidade.

O que essa experiência me ensinou
Esse projeto me mostrou que:
a documentação oficial nunca cobre 100% dos casos
padronização é a base da confiabilidade
pipelines dependem profundamente de variáveis
runners definem a saúde invisível do CI/CD
erros têm um papel essencial na engenharia
automação bem feita cria confiança

E a maior lição de todas:
quando você reorganiza a fundação, todo o fluxo de desenvolvimento melhora.

Conclusão
Migrar milhares de projetos não é apenas um desafio técnico.
É uma prova de disciplina, engenharia e resiliência.
Com automação determinística, testes piloto reais e aprendizagem através dos erros, foi possível migrar cerca de 4.000 repositórios com segurança, mantendo a integridade de código, pipelines, histórico e governança.
É importante destacar a possibilidade de evolução futura do projeto. Uma reescrita em Python é considerada uma etapa natural, permitindo maior flexibilidade e fluidez no código, sem desconsiderar a eficiência e robustez das soluções atualmente implementadas em Bash.
A solução está disponível publicamente e pode servir de base para outras pessoas que enfrentam desafios semelhantes:
⭐ Se você puder e gostou do projeto, deixe uma ⭐ estrela ⭐ no GitHub - isso ajuda muito a fortalecer e valorizar o trabalho.
👉 https://github.com/clcesarval/migrar-gitlab
Se você está planejando uma grande migração, lembre-se:
Erros não são inimigos.
Eles são guias.
E automação bem feita transforma medo em confiança.

📚 Referências

GitLab Documentation. https://docs.gitlab.com/ee/
GitLab Import/Export Guide. https://docs.gitlab.com/ee/user/project/settings/import_export.html
GitLab API Reference. https://docs.gitlab.com/ee/api/
Google Cloud - DORA Research & Four Key Metrics. https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
Accelerate: State of DevOps Report (DORA). https://www.devops-research.com/research.html
Martin Fowler - Continuous Delivery & Infrastructure as Code. https://martinfowler.com/
Google SRE Book - Eliminating Toil & Reliability Engineering. https://sre.google/sre-book/
Pro Git Book - Git Internals. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
Advanced Bash Scripting Guide. https://tldp.org/LDP/abs/html/
GitHub Engineering - Migration and Automation Insights. https://github.blog/engineering/

How I Automated a Full GitLab Migration Using Bash (Real Case Study + Scripts)

Claudio Cesar — Tue, 02 Dec 2025 01:59:33 +0000

🚀 Automating GitLab Migration with Bash (Real Case Study + Open-Source Scripts)

Migrating multiple repositories between GitLab instances can quickly become a complex and repetitive process — especially when dealing with groups, subgroups, CI/CD pipelines, variables, tags, and issues.

To solve this challenge efficiently, I developed a collection of Bash automation scripts used to migrate projects from a self-hosted GitLab Community Edition to GitLab Enterprise (gitlab.com).

This post summarizes the approach, structure, and benefits, and the full toolkit is now open-source for the community.

🧠 Why Automate the Migration?

When migrating large environments, manual work becomes:

❌ Time-consuming
❌ Error-prone
❌ Hard to track or repeat

Automation ensures the process is:

✔️ Repeatable
✔️ Auditable
✔️ Safe
✔️ Scalable
✔️ Faster

🛠️ What’s Included in the Toolkit?

Script	Purpose
`clone-projects.sh`	Clones all repositories from the source GitLab group
`replace_gitlab-ci.sh`	Updates `.gitlab-ci.yml` references for the new paths
`push-projects.sh`	Pushes branches and tags to the target GitLab instance
`migrar-variaveis.sh`	Migrates group-level environment variables via API
`migrar_issues.sh`	Migrates issues and comments preserving metadata
`delete-issues.sh`	Deletes issues when resetting staging/testing
`gitlab-clone-recursive.sh`	Clones nested groups and subgroups recursively
`gitlab-push-recursive.sh`	Pushes repositories and recreates missing subgroups automatically

Each script contains:

Validation logic
Logging
Backup behavior
Idempotent execution (safe to rerun)

⚙️ How It Works (High-Level Workflow)

Clone repositories from the source GitLab
Apply CI/CD path replacements if needed
Push repositories (branches + tags) to the destination
Migrate variables, issues, and metadata
Validate and finalize the migration

This flow supports incremental migration, useful for large environments.

📂 Full Source Code

GitHub repository:

👉 https://github.com/clcesarval/migrar-gitlab

🏁 Final Result

Using this automation, we achieved:

✅ Complete migration of all repositories
✅ Preservation of history, branches, and tags
✅ Reuse of CI/CD pipelines with minimal manual work
✅ Controlled and repeatable process

💡 Final note

This project was created after going through a real-world GitLab migration and realizing how difficult it was to find clear, complete, and automated guidance — especially one that covers repositories, CI/CD files, variables, branches, tags, and issues in a structured and safe way.

Since there was no fully documented or ready-to-use solution available, I decided to share what I learned and turn the entire process into reusable automation.

The first version of this project was built in Bash since my background is strongly focused on Linux automation and Shell scripting. It allowed me to move fast and keep the migration reliable. However, the long-term goal is to refactor and evolve this into Python — making the solution more flexible, maintainable, and modular for future improvements.

If you are interested in contributing, improving features, or helping with the Python rewrite, feel free to jump in — collaboration is welcome.

If this project saved you time, inspired a better approach, or helped even a little — then publishing it was worth it.

Together, we make the DevOps community stronger. 🚀

If you're planning or performing a GitLab migration, feel free to fork, adapt, and contribute improvements.

💬 Feedback and collaboration are welcome!