Azure DevOps Server to Azure DevOps Services Migration moves your on-premises Azure DevOps Server (or Team Foundation Server) collection into Microsoft's cloud-hosted Azure DevOps Services with full fidelity — work items, Git and TFVC repositories with complete history, test plans, and pipeline definitions — using Microsoft's official Data Migration Tool. IT Partner runs the readiness validation, prepares the Microsoft Entra ID identity mapping, executes a dry-run import into a staging organization, performs the production import in an agreed cutover window, and reconnects what the tool does not carry: build agents, service connection credentials, and extensions. The estimated price is $3,950 per project, confirmed as a fixed written quote after the readiness assessment and before any work begins; typical duration is about 3 weeks.
On-premises Azure DevOps Server estates rarely fail loudly — they age out quietly, together with the Windows Server and SQL Server versions underneath them. Microsoft's investment is visibly in the cloud service: new capabilities land in Azure DevOps Services first, and keeping a server current means recurring upgrade projects just to stay supported. The way off this treadmill is Microsoft's own high-fidelity import path — the Azure DevOps Data Migration Tool — which moves an entire collection database into a new Azure DevOps Services organization with history intact. The tool is real and proven, but it is genuinely fiddly, which is why this is a service and not a download link. It only supports the two most recent Azure DevOps Server releases at any time, so older TFS and Azure DevOps Server versions must first be upgraded to a supported level — and support for the very newest server release typically comes online weeks after it ships, which affects scheduling. Every identity in the collection must be mapped to a Microsoft Entra ID account, and a sloppy mapping file quietly strands users and history attributions. The import itself goes through validation, preparation, and a dry run into a staging organization before anyone touches production, and larger collections take a different technical import path than small ones. After the import, the pieces the tool deliberately does not carry must be rebuilt by hand: self-hosted build agents re-registered, service connection secrets and personal access tokens re-created, marketplace extensions re-installed. IT Partner runs this entire sequence — readiness through cutover through post-import validation — and hands your team a working organization, signed in, building, and releasing. Scope boundaries are explicit: a single supported-version upgrade hop is included where required; multi-hop upgrades of very old TFS servers are scoped in the written quote; wholesale pipeline modernization (for example converting classic pipelines to YAML at scale) is its own engagement; and if your destination is GitHub rather than Azure DevOps Services, that is a different project we also scope.
We inventory the server and collection, check the version against the Data Migration Tool's currently supported releases, run the tool's validation against the production collection, and review identity state in Microsoft Entra ID. The output is a written plan — including the import method for your collection size and any upgrade work needed first — and the fixed quote is confirmed on this basis.
Validation findings are remediated, the required upgrade hop is executed if your server is below the supported matrix, and the identity mapping file linking on-premises identities to Microsoft Entra ID accounts is built and reviewed with you. If your users are not yet in Entra ID, that is a prerequisite project we will name honestly rather than improvise around.
We import the collection into a staging Azure DevOps Services organization and walk your team through a structured verification: work item queries, repository history spot-checks, test plans, pipeline definitions, and sign-in with mapped identities. Nothing proceeds to production until you sign this off — the dry run is where surprises are allowed to happen.
In the agreed window, the source collection is taken offline, the final import runs, and the new organization comes up. Downtime length depends on collection size and import method — it is estimated from the dry run, not guessed. Users return to work in Azure DevOps Services with their identity and history intact.
Agent pools are re-registered, service connections re-created with fresh secrets, extensions re-installed, and a representative build and release verified green. We run the post-import checklist with your team, hand over documentation including decommissioning guidance for the old server, and close out.
It is a fixed-scope project in which IT Partner moves your on-premises Azure DevOps Server or TFS collection into Microsoft's cloud-hosted Azure DevOps Services using Microsoft's official Data Migration Tool — readiness validation, Entra ID identity mapping, a dry-run import, the production cutover, and reconnection of agents, service connections, and extensions. Estimated at $3,950 per project and about 3 weeks, with a fixed written quote confirmed after readiness.
No — this is the reason to use Microsoft's Data Migration Tool rather than copy-paste tooling. It imports the entire collection database with full fidelity: work items with their history and attachments, Git and TFVC repositories with complete commit and changeset history, test plans, and pipeline definitions. What does not carry over automatically is a short, known list — agent registrations, service connection secrets, extensions — and reconnecting those is part of this service.
Yes, but with a step first: the Data Migration Tool only accepts the two most recent Azure DevOps Server releases, so older servers must be upgraded to a supported version before import. One upgrade hop is included in this service where required; a server several versions behind needs a multi-hop upgrade, which the readiness assessment identifies and the written quote prices explicitly — before work begins, not as a surprise afterward.
Your team works normally through readiness, preparation, and the dry run — the source server stays live. Downtime happens only at the final cutover, when the collection is detached for the production import. Its length depends on collection size and the import method, and because we run a full dry run first, the estimate we give you for the cutover window is measured, not guessed.
Every identity in the collection is mapped to a Microsoft Entra ID account so that sign-in, permissions, and history attribution survive the move. We prepare the mapping file, review it with you (including how to handle departed employees and service accounts), and validate it before import. If your users are not in Entra ID yet — still purely on-premises Active Directory — that is a prerequisite we will name honestly, and our On-premises Active Directory to Microsoft Entra ID Transition service covers it.
Pipeline definitions import with the collection. What needs rebuilding is the connective tissue: self-hosted agents must be re-registered against the new organization, service connections re-created with fresh credentials (secrets deliberately do not migrate), and marketplace extensions re-installed. We do that reconnection and verify a representative build and release run green before closeout. Converting classic pipelines to YAML or redesigning your delivery process is separate, deliberately — see the CI/CD Pipeline Implementation service.
That is a different project with different tooling, and we scope it too. Some teams are better served by GitHub (especially those standardizing on GitHub Actions and GitHub Advanced Security); others get the fastest, highest-fidelity move via the Data Migration Tool into Azure DevOps Services and evolve from there. Tell us where you want to end up and we will quote the right migration rather than the one on this page.
The Data Migration Tool imports one collection into one new Azure DevOps Services organization. Multiple collections become multiple organizations, each its own import — quoted accordingly. Consolidating several collections into a single organization is possible but is surgical, third-party-tooling territory and is scoped as a separate engagement with its trade-offs stated plainly.
Azure DevOps Services is billed by Microsoft per user: the first five Basic users in an organization are free on Microsoft's published pricing, users with Visual Studio subscriptions are typically covered, and additional Basic users are paid monthly. We verify what your team will need during readiness — but confirm current rates against Microsoft's published pricing, since they are Microsoft's numbers, not ours, and can change.
That is what it is for, and it usually finds something — size issues, identity gaps, unsupported customizations, version problems. Remediation of validation findings is part of the service, and anything that materially changes scope (like a multi-hop upgrade) goes into the written quote before work begins. The rule throughout: no production import until validation is clean and the dry run is verified by your team.
Keep it offline but intact through an agreed verification period as a safety net, then decommission it — we hand over written guidance for that. If the retirement of that server is part of a bigger question (the Windows and SQL Server underneath it are usually aging too), our Azure migration services cover moving or retiring the rest of the stack.
$3,950 is the typical price for a single-collection migration with a supported or one-hop-upgradable server. The readiness assessment in week one converts it into a fixed quote in writing — covering any upgrade work and your specific collection — which you approve before migration work begins. Per IT Partner's standard terms, you pay after you approve delivery.
Yes, until the cutover window. Readiness, the upgrade hop if needed, identity mapping, and the dry run all happen alongside normal work on the live server. The only freeze is the final import window, which is scheduled with you — typically outside working hours — and its length is estimated from the dry run.