Azure DevOps Data Import

The first option we test, every time

Microsoft’s Data Migration Tool imports a whole Azure DevOps Server collection into a new Azure DevOps Services organisation. Byte for byte: every work item, every revision, every timestamp, every link, exactly as it was. It is free, it is supported by Microsoft, and it is the only migration path that preserves everything with full fidelity.

That is why it is the first option we test on every cloud move, including paid engagements. Fidelity wins. When the import fits your estate, it is what we recommend and what we use, and this page is us saying so in public.

One naming clarification, because the collision catches everyone: Microsoft’s Data Migration Tool is not the open-source Azure DevOps Migration Tools we maintain. Microsoft’s tool imports whole collections with full fidelity, one way. Ours moves work items selectively, in any direction, replay-based and not byte-perfect. Different instruments for different moves.

What it requires, and what surprises people

Each of these is in Microsoft’s documentation ; together they decide whether the import can fit your move at all:

• Your server must be on one of the two most recent releases. An older server cannot leave directly: a TFS 2015 or 2017 box has an upgrade chain to climb before the import will accept it. That turns “we’ll just import it” into a multi-step project with its own timeline.
• One collection becomes one new organisation. The import cannot merge into an existing organisation, cannot move projects between organisations, and cannot go server to server.
• Everything moves, with no modifications. No filtering, no reshaping, no leaving the dead projects behind. Cleanup happens before the import or after it, never during.
• English-only collections. A collection in another language, or converted from one, cannot use the import.
• Customised projects land on the Hosted XML process model. One process per customised project, which is post-migration work to rationalise if you want the modern inherited model.
• Supported Azure regions only, for the organisation and any temporary migration infrastructure.

When it is the wrong instrument

Every one of these is a real situation with its own honest answer:

• You need to move some projects, in order, and leave the rest behind: that is a selective migration .
• You need to merge into an organisation that already exists, or split one after a sale: merger and divestiture moves .
• You are going the other way, from Services back to your own server: there is no Microsoft path in that direction .
• The destination is GitHub , where the import does not go.

Running one well is still a project

The tool is free. The migration around it is real work, and most of that work happens before the import ever runs: bringing the collection into an importable shape. The upgrade chain to a supported version, the validation errors the premigration analysis raises, the cleanup you want done before everything moves as-is, identity and licence mapping. Then the choice of import route itself, which depends on your collection: smaller collections go one way, large ones need temporary SQL infrastructure in the right Azure region. Then dry runs against a copy, the cutover window, and the process-model work afterwards. A capable team can do all of it from Microsoft’s documentation , and if that is you, you need nothing from us.

If you want the dry runs, the sequencing, and the evidence handled by people who deliver import-based migrations regularly, that is exactly what a migration assessment scopes: it tells you whether the import fits, what the upgrade chain looks like for your versions, and what the whole move will cost. If an import is already underway and validation errors or a failed cutover have stalled it, that is a migration rescue .

This is not for you if your server is current, your collection is clean, and the whole estate moves as one: follow Microsoft’s documentation and go. That is the import working as designed, and it is the best possible version of a migration.