Azure DevOps Services to Server Migration

Moving from Azure DevOps Services back to a local Azure DevOps Server, for data sovereignty or compliance. There is no Microsoft path in this direction. Here is what it takes and what it costs in fidelity.

Leaving the cloud is a legitimate migration.

Most people on this page have already had the raised-eyebrow conversation. The industry default runs the other way, and a team planning to move from Azure DevOps Services back to a server of their own gets asked to justify itself in a way no cloud move ever does.

The justifications are real. EU organisations reducing their dependency on US technology, and the jurisdiction questions that come with it. Defence and government estates whose compliance rules never allowed cloud in the first place, now absorbing an acquired company that lives there. If that is your situation, you do not need the decision defended. You need it delivered.

One word matters on this page. Azure DevOps Server is the on-premises product, the successor to TFS. Azure DevOps Services is Microsoft's cloud. Check which one you are on before picking a path.

Two facts to hold onto before anyone plans anything

This move will not save you money. Running Azure DevOps Services is cheaper and easier than running your own server, and always will be. If cost is the driver, the honest answer is: stay. Sovereignty and compliance are the reasons this move makes sense, and they are sufficient reasons on their own.

There is no Microsoft path in this direction. Microsoft’s Data Import Service goes one way: from Server into Services. Nothing official comes back. The move out is tool-based, work item by work item, and that means it is not byte-perfect. Replay-based migration preserves your work items, history, links, and test artefacts, but not every timestamp and identity survives identically. What “not identical” means for your specific estate gets named in the plan, before you commit, because for a compliance-driven migration the difference between “history preserved” and “history preserved, with these specific caveats” is exactly the thing your auditors will ask about.

We migrate estates in both directions. We sell the outcome, not the destination, and this page is what that looks like in practice.

What you will have when it is done

  • Your estate on infrastructure in your jurisdiction, under your control.
  • Work items, history, links, and test evidence preserved, with the exceptions documented rather than discovered.
  • A validation report your compliance team can put in front of a regulator.
  • Delivery running throughout. Leaving the cloud does not mean stopping work.

Where to start

Start with a migration assessment . For an exit it does the one thing nobody else will do honestly: it tells you precisely what a tool-based move out preserves for your estate and what it does not, from a pilot against your real data, before you stand up a single server.

If an exit is already underway and stalling, or what has moved so far does not reconcile, that is a migration rescue .

This is not for you if you are still deciding whether to leave. An assessment can inform that decision, but it will not make the sovereignty case for you. And if only a handful of simple projects need to come back, the open-source tools with your own team can do it.

Compliance says out. Now what?

Tell me what's in Services today, what jurisdiction it needs to land in, and what your compliance team must be able to evidence. I'll tell you what the move preserves and what it will take.

Get in touch

Not sure what your migration actually needs?

Most migrations fail in the planning, not the execution. Tell me where you are today, where you need to be, and what you've already tried. I'll tell you honestly what it will take. If a simpler path fits, I'll point you at it. And if we do work together and the engagement fails to meet the agreed standard, we refund your fee.