An organisation decides to move from Team Foundation Server to Azure DevOps, or from Azure DevOps to GitHub. A programme is formed, repositories are counted, a migration utility is selected and a cutover date is proposed.
The plan looks sensible. It may even move the code successfully.
Yet months later, developers still wait days for environments. Release approvals remain dependent on spreadsheets and meetings. Secrets are embedded in variable groups no one wants to touch. Security arrives at the end of the process. Teams reproduce the same pipeline in slightly different ways, and leadership still cannot see how work moves from an idea into production.
The platform changed. The software delivery system did not.
That is the central mistake in many DevOps migrations: treating the tool as the system.
The repository is only one part of delivery
A software delivery system is the combination of people, workflow, technology, controls and feedback required to turn an idea into a safe, supportable production change.
It includes at least:
- product planning and work management;
- source control and branching;
- pull requests and code review;
- build, test and release automation;
- artefact and package management;
- secrets, identities and service connections;
- infrastructure provisioning;
- application and supply-chain security;
- environment promotion and approvals;
- observability, incident feedback and operational ownership;
- standards, exceptions and engineering enablement.
Moving repositories without addressing these connected capabilities is like relocating a factory's filing cabinet while leaving its production line unchanged.
The repository matters, but it does not determine whether software can be delivered frequently, securely or predictably.
First identify which migration you are actually doing
“TFS migration” is often used as shorthand for several fundamentally different journeys:
| Journey | What changes | The deeper challenge | |---|---|---| | TFS or Azure DevOps Server to Azure DevOps Services | Hosting and service operating model | Compatibility, identity, extensions, collection structure, data fidelity and cloud readiness | | TFVC to Git | Version-control model | Branching, repository structure, history choices and new team behaviours | | TFS or Azure DevOps to GitHub | Developer platform and often the delivery model | Repository conversion, pipelines, security, work management, governance and adoption | | Azure DevOps Services consolidation | Organisation or project structure | Data-copy limitations, process templates, permissions, dependencies and what history must remain archived | | Azure DevOps plus GitHub | Responsibility split between platforms | Preventing duplicated controls and making system ownership explicit |
These are not interchangeable projects. Each has a different supported path, fidelity profile, risk model and organisational impact.
For example, Microsoft's Azure DevOps Data Migration Tool is designed for a high-fidelity move from supported Azure DevOps Server versions to Azure DevOps Services. That does not mean every Azure DevOps organisation-to-organisation consolidation has the same supported, full-fidelity route. Likewise, converting TFVC to Git is not merely a format conversion: centralised and distributed version control encourage different ways of working.
The correct starting question is therefore not, “Which migration tool will we use?”
It is:
What software delivery capability are we trying to improve, and which parts of the existing system should survive?
Define outcomes before selecting the destination
A migration becomes useful when it is anchored to measurable outcomes. Common examples include:
- reducing lead time from approved change to production;
- making releases repeatable and less dependent on individuals;
- strengthening software supply-chain security;
- standardising engineering controls without slowing teams down;
- reducing tool fragmentation and duplicated licensing;
- enabling inner-source collaboration;
- improving developer onboarding and experience;
- creating traceability from business intent to deployed change;
- supporting cloud-native application and infrastructure delivery;
- reducing unsupported infrastructure and operational overhead.
These outcomes force better trade-offs.
If the main goal is to remove ageing server infrastructure while preserving current practices, a high-fidelity route to Azure DevOps Services may be appropriate.
If the goal is to create a GitHub-centred developer platform with integrated code security and reusable automation, the programme must address far more than repositories.
If teams rely heavily on Azure Boards while source and security capabilities are moving to GitHub, a deliberate hybrid operating model may be safer than an artificial “everything moves on day one” rule.
There is no prize for achieving platform purity while damaging delivery continuity.
Assess the system, not only the inventory
Traditional migration discovery often starts with counts:
- number of collections, projects and repositories;
- repository sizes and history;
- number of work items;
- number of pipelines;
- number of users;
- number of extensions and integrations.
These numbers are necessary, but insufficient. Two pipelines with the same task count can have completely different risk. One may use standard tasks and workload identity; another may depend on a custom extension, an old build agent, a manually maintained certificate and access to a network share.
A useful assessment looks at four layers.
1. Assets
What exists?
Repositories, branches, work items, test assets, pipelines, artefacts, wikis, dashboards, agents, runners, service connections, extensions, hooks, identities and policies.
2. Dependencies
What does each asset depend on?
Networks, credentials, package feeds, external systems, shared templates, legacy runtimes, deployment targets, custom scripts and organisational processes.
3. Behaviour
How is work actually delivered?
Where do teams bypass the official process? Which approvals are meaningful? Which controls exist only on paper? Who fixes failed releases? How long does onboarding take? Which manual step is accepted only because one person knows how to perform it?
4. Outcomes
What must improve, and how will improvement be measured?
Without this layer, a programme can deliver a technically correct migration that creates no meaningful business value.
Use the migration to simplify
Migration is one of the few moments when an organisation has enough attention and permission to challenge accumulated complexity.
Do not automatically move:
- abandoned repositories;
- stale branches and obsolete binaries;
- unused extensions;
- duplicate pipelines;
- personal queries presented as enterprise process;
- credentials that should already have been rotated;
- controls that no longer mitigate a real risk;
- old project structures that reflect a historic reorganisation rather than today's products.
Retaining everything can feel safe, but it transfers old constraints into the new platform. The better question is not, “Can this be migrated?” It is, “What business, engineering, legal or audit need requires it in the active platform?”
Some history belongs in the new system. Some belongs in a searchable, read-only archive. Some data needs an evidential export. Some should be retired under an agreed retention policy.
That decision must involve engineering, product, security, audit, legal and records-management stakeholders where appropriate. It should not be left to a migration script.
Treat platform engineering as the product that outlives the migration
The strongest migration programmes do not end with an empty source platform. They leave behind a usable internal developer platform.
That platform might provide:
- approved repository templates;
- reusable CI/CD workflows;
- supported runner or agent patterns;
- automated environment provisioning;
- secrets and identity patterns;
- security scanning defaults;
- policy-as-code;
- observability standards;
- golden paths for common application types;
- exception and support processes;
- documentation written for developers, not only administrators.
The platform team should behave like a product team. Developers are its users. Adoption, usability, reliability and support matter as much as architectural correctness.
A control that exists but is regularly bypassed is not an effective control. A reusable pipeline that is too difficult to adopt will create local copies. A standard that takes weeks to approve will become a bottleneck.
The target state must make the secure path the easiest path.
Security should move from gate to flow
Migration creates an opportunity to redesign security as part of everyday delivery rather than a final checkpoint.
A modern control flow can include:
- protected branches or rulesets;
- mandatory peer review;
- dependency and secret scanning;
- static analysis;
- infrastructure-as-code validation;
- signed or traceable artefacts;
- short-lived cloud credentials through workload identity;
- environment protection and separation of duties;
- evidence captured automatically during the pipeline;
- post-deployment monitoring and feedback.
This is not achieved by switching on every possible scanner. Controls need ownership, triage paths and service-level expectations. Findings that no one can interpret or remediate simply become noise.
Security architecture must answer:
- Which control prevents, detects or evidences which risk?
- At which stage does it run?
- What blocks delivery?
- Who owns an exception?
- How is the exception time-bound and reviewed?
- How is evidence retained?
The migration is successful when controls become more reliable and less dependent on manual policing.
Do not underestimate the human migration
TFVC-to-Git illustrates the point clearly. Teams are not only learning new commands. They are moving from a centralised version-control model to a distributed model with different approaches to local history, branches, merging and collaboration.
Similarly, moving from classic releases to YAML workflows changes who can see, review and modify the release definition. Introducing reusable workflows changes the relationship between application teams and the platform team. Moving to new security capabilities changes how developers receive and resolve findings.
Adoption needs:
- role-based training using the organisation's real patterns;
- a pilot with representative complexity;
- migration champions embedded in teams;
- office hours and responsive support;
- clear golden paths and escape hatches;
- time for teams to clean and test their assets;
- hypercare based on observed failure modes;
- measures of adoption and developer experience.
Communication cannot be reduced to a cutover email.
Run the transformation in waves
A big-bang migration maximises coordination risk. A never-ending voluntary migration creates permanent duplication. A wave model provides a more useful middle path.
A practical sequence is:
- establish outcomes, governance and architecture principles;
- inventory assets and map dependencies;
- design and test the target platform foundation;
- select representative pilot teams;
- migrate, validate and stabilise the pilots;
- improve tooling, templates and runbooks from pilot evidence;
- migrate in repeatable waves;
- decommission deliberately after retention and audit gates are satisfied;
- continue platform-product improvement after the programme closes.
Wave planning should consider complexity, business criticality, team readiness and shared dependencies—not only repository count.
Measure the system after the move
“Repositories migrated” is a programme metric, not an outcome metric.
Useful measures include:
- lead time for changes;
- deployment frequency;
- change failure rate;
- time to restore service;
- pipeline success and duration;
- percentage of repositories using supported workflows;
- age of unresolved critical findings;
- time to onboard a new service or developer;
- number and age of exceptions;
- developer satisfaction with the platform;
- reduction in manual deployment and evidence-collection steps.
Baseline these before the migration. Otherwise, the organisation cannot show whether the new platform improved delivery.
The real definition of done
A DevOps migration is not complete when the last repository is copied.
It is complete when:
- teams can deliver through the target operating model;
- the required history and evidence remain accessible;
- pipelines and integrations work predictably;
- controls are effective and supportable;
- the new platform has clear ownership;
- people know how to use and support it;
- the source platform can be retired without creating operational or audit risk;
- delivery performance is improving against the agreed outcomes.
The platform is visible. The software delivery system is what creates value.
Move the platform when necessary—but modernise the system while you have the opportunity.
How CloudNala can help
CloudNala approaches DevOps migration as an architecture, operating-model and adoption problem—not a bulk-copy exercise. The work begins with the delivery outcomes, maps the system around the repositories, and uses evidence from pilot migrations to create a safer, repeatable path at enterprise scale.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan Your DevOps Migration or write to us at consult@cloudnala.co.za