Your organisation changed shape. Now the estate has to.
A merger hands you two or three Azure DevOps organisations, overlapping process templates, and one mandate: make them one, without stopping any of the teams that make the deal worth doing. A sale hands you the opposite problem. Part of the estate must leave, cleanly, by a date written into an agreement you did not draft.
Either way, the deadline on this work is not an IT deadline. It was set by lawyers and signed by boards. Slipping it is visible in places where “the tooling was complicated” is not an acceptable sentence.
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.
Why this is not a normal migration
A lift-and-shift moves everything, once. A deal rarely wants that.
A consolidation needs some projects merged into an organisation that is already alive, in an order that follows the integration plan, while both organisations keep shipping. A carve-out needs specific projects, their history, and their traceability to leave, and everything else to provably stay. Both are selective, ordered moves. Neither is what bulk tooling was built for.
Microsoft’s data import moves whole collections, byte for byte, from Server to Services. It is the right answer when one company’s estate simply becomes the new home, and if that is your situation, use it. It cannot merge into an existing organisation and it cannot split one. For that you need work-item-level moves: replay-based, not byte-perfect, with the differences named up front and validated afterwards.
We have been doing exactly that for a long time. The first version of the open-source Azure DevOps Migration Tools was built inside a Fortune 500 consolidation in 2013, and they have been hardened across hundreds of estate reshapes since. Two of the largest are written up as case studies: consolidating systems and standardising engineering practice across more than 800 teams at SLB , and unifying build and release across 90 teams in 13 countries .
What you will have when it is done
- One organisation your teams actually work in, or two that are genuinely separate. Not a compromise with leftover wiring.
- History, links, and test evidence preserved for everything that moved.
- A validation report showing exactly what moved and what it maps to. For a carve-out, that same evidence shows what did not move. Both sides’ auditors get an answer instead of an assurance.
- A deal timeline that held, with delivery running throughout.
Where to start
Start with a migration assessment . For deal work it does three specific things: it measures both estates before anyone promises a date, it rehearses the risky moves in a pilot instead of during integration week, and it produces a sequence and a fixed quote you can put in front of the deal team.
If a consolidation or separation is already underway and has stalled, or nobody trusts what has moved so far, that is a different conversation: a migration rescue .
This is not for you if the deal makes one estate the obvious home and it can move whole. Microsoft’s import is cheaper and byte-perfect: use it. And if the estates are small and simple, the open-source tools with your own team are a legitimate path.
On a deal timeline?
Tell me the shape of it: how many organisations, which direction things move, and what date is in the agreement. I'll tell you honestly what it will take and in what order.
Get in touch